Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BPF: A New Type of Software

brendangregg.com

Post reply on HN
Print view View original

11–20 of 192 posts

Re: BPF: A New Type of Software

#12

Post by etaioinshrdlu »

It reminds me a wee bit of stuff that has happened in browsers. NaCl was a way to run untrusted native code by scanning it for unsafe operations.

BPF seems to have a similar aim in a sense: run less-trustworthy code in an unrestricted environment, but don't use CPU hardware based access control (and therefore context switching) to limit it, rather, make the code more sandboxed in software to prevent the need for context switches.

Re: BPF: A New Type of Software

#13

Post by maxdamantus »

Iv wrote: post #6

So from my understanding, that's a kind of "secure" (I'd like to know more about the security model tbh) module that runs with kernel privilege with no scheduling (so it runs until completion). These are supposed to be short and I am assuming, can't call libs and can't allocate memory (outside a predefined stack I would guess?) Aren't they very similar to interrupts? What is the difference there? The kernel API?

I think it's more to do with avoiding overheads typically associated with system calls (presumably involving some interrupt and disabling/enabling/changing paging behaviour).

Here's an example of a syscall-heavy command on my system:

  $ time dd if=/dev/zero bs=1 count=10M of=/dev/null
  10485760+0 records in
  10485760+0 records out
  10485760 bytes (10 MB, 10 MiB) copied, 7.09089 s, 1.5 MB/s
 
  real    0m7.092s
  user    0m2.123s
  sys     0m4.968s
3 million system calls per second seems quite slow on a 3.2 GHz CPU when all it should really be doing is dereferencing a couple of pointers until it finds some functions that simply write a zero byte to a buffer (the "/dev/zero" descriptor handler) and ignore bytes from a buffer (the "/dev/null" descriptor handler).

If you have a safe bytecode format for representing operations that are performed in a loop, the kernel can just perform those operations without having to switch back and forth to userspace.

Re: BPF: A New Type of Software

#16

Post by jokoon »

I have a hard time understanding what you would use it for. I could understand a use-case, but I fail to understand why it would be that much useful.

I have a sense it allows much better performance for horizontal scaling, but I'm not sure...

Re: BPF: A New Type of Software

#17

Post by varelaz »

baybal2 wrote: post #15

Question from me, why reinvent the bicycle and not just write proper kernel modules in C?

Well, if you have seen the video, probably you wouldn't ask this. Kernel modules can do everything that can BPF do, but BPF could be easier to write, more isolated and less error prone.

Re: BPF: A New Type of Software

#18

Post by ComSubVie »

Haven't used it till now (except maybe via nft?).

What I'm not sure is: who is preventing BPF to be used as rootkits? Since they are run inside the kernel and cannot be inspected (?) can they be used to hide malicious activity?

Re: BPF: A New Type of Software

#19

Post by rusk »

jokoon wrote: post #16

I have a hard time understanding what you would use it for. I could understand a use-case, but I fail to understand why it would be that much useful. I have a sense it allows much better performance for horizontal scaling, but I'm not sure...

Real-time, low latency, network-based applications.

At the pace of network events, CPU is still very fast by perhaps at least order of magnitude. However, latency introduced by system calls is significant.

This allows you to run certain classes of application in kernel space with these overheads largely mitigated.

Principally it's monitoring and "observability" applications, but apparently it's much more flexible now than it has been historically ...

Re: BPF: A New Type of Software

#20

Post by z3t4 »

rusk wrote: post #19
jokoon wrote: post #16

I have a hard time understanding what you would use it for. I could understand a use-case, but I fail to understand why it would be that much useful. I have a sense it allows much better performance for horizontal scaling, but I'm not sure...

Real-time, low latency, network-based applications. At the pace of network events, CPU is still very fast by perhaps at least order of magnitude. However, latency introduced by system calls is significant. This allows you to run certain classes of application in kernel space with these overheads largely mitigated. Principally it's monitoring and "observability" applications, but apparently it's much more flexible now…

Wouldn't virtualization kill the perf benefit, or is this supposed to run "on the metal"?
Post reply on HN