4 ms·

I can’t be the only person thinking “What the hell is BPF?”. I know that probably means I’m not the audience but it wouldn’t hurt them to just state that the ve

by atonse 9y ago

I can’t be the only person thinking “What the hell is BPF?”. I know that probably means I’m not the audience but it wouldn’t hurt them to just state that the very first line. Updated with article about BPF: https://lwn.net/Articles/747551/ https://lwn.net/Articles/747551/ Really good talk by the Cilium folks that explains these concepts: https://m.youtube.com/watch?v=ilKlmTDdFgk https://m.youtube.com/watch?v=ilKlmTDdFgk

jitl 9y ago
My first thought is that it’s “Berkeley Packer Filter”, see here for some context on what else it’s used for: http://blog.memsql.com/bpf-linux-performance/ http://blog.memsql.com/bpf-linux-performance/
- kyrra 9y ago
  I believe the proof of concept for the Spectre attack used the Linux eBPF JIT. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
- stuartaxelowen 9y ago
  Or Band Pass Filter :P
- eatonphil 9y ago
  I believe it started out as an extension of BPF. The real term they mean to use (and most people mean to use, I think) is eBPF. Calling it eBPF makes a whole lot more sense to me because it's evolved a lot since it was just doing packet filtering. Also, it's Linux-only so again differentiating eBPF from BPF (which is not Linux-only) makes sense to me. But I didn't write the post.
eecc 9y ago
FreeBSD’s firewall?
erikb 9y ago
Or it means people want you to think you are stupid for not knowing something that in reality doesn't exist or doesn't have the credit and success it wants you to believe to has.
- hueving 9y ago
  The networking community is pretty insular and tends to assume that the wider world is keeping up with the hundreds of new niche networking projects, protocols, abstractions, and foundations created and left to rot every day. BPF is hot today. Tomorrow it will be sooooo openflow.
  - twic 9y ago
    If eBPF manages to be an exception to that, it could be very interesting. If i understand this correctly, eBPF is a fairly general-purpose bytecode format that can be executed inside the kernel. It's safe, and there's a JIT, so it's pretty fast (is there really a JIT compiler running in kernel space?). It was originally used for packet filtering, but it's now used at various decision points in networking, and is somehow involved with tracing as well. But it could potentially go much further. Anywhere the kernel currently gets configured with data-like configuration could be replaced or augmented with an eBPF, right? For example, instead of setting an ACL on a directory, you could set an eBPF program which would run for each attempted access and decide whether to allow it, as well as logging or doing other stuff. eBPF programs could guard the interfaces between a container and its host, allowing more flexible isolation. An eBPF program could respond to every system call a process makes, allowing behaviour like OpenBSD's pledge, only much more sophisticated. With the right access control model (implemented in eBPF!), normal userland programs could install eBPF programs for resources they control (sockets, files, etc), potentially shifting a significant fraction of their processing into kernel mode, improving performance, reducing system call overhead, and allowing safe access to kernel facilities that are currently inaccessible. Imagine implementing a garbage collector in userspace, but being able to configure your slice of the virtual memory system in the kernel using an eBPF program. I don't know if this will happen. But a pervasively eBPF world would be very different, and very interesting. We'll have all sorts of fun. We'll get tools we never imagined. And we'll get pwned by black hats harder than ever before.

by atonse 9y ago

jitl 9y ago

My first thought is that it’s “Berkeley Packer Filter”, see here for some context on what else it’s used for: http://blog.memsql.com/bpf-linux-performance/ http://blog.memsql.com/bpf-linux-performance/

kyrra 9y ago
I believe the proof of concept for the Spectre attack used the Linux eBPF JIT. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
stuartaxelowen 9y ago
Or Band Pass Filter :P
eatonphil 9y ago
I believe it started out as an extension of BPF. The real term they mean to use (and most people mean to use, I think) is eBPF. Calling it eBPF makes a whole lot more sense to me because it's evolved a lot since it was just doing packet filtering. Also, it's Linux-only so again differentiating eBPF from BPF (which is not Linux-only) makes sense to me. But I didn't write the post.

eecc 9y ago

FreeBSD’s firewall?

erikb 9y ago

Or it means people want you to think you are stupid for not knowing something that in reality doesn't exist or doesn't have the credit and success it wants you to believe to has.

hueving 9y ago
The networking community is pretty insular and tends to assume that the wider world is keeping up with the hundreds of new niche networking projects, protocols, abstractions, and foundations created and left to rot every day. BPF is hot today. Tomorrow it will be sooooo openflow.
- twic 9y ago
  If eBPF manages to be an exception to that, it could be very interesting. If i understand this correctly, eBPF is a fairly general-purpose bytecode format that can be executed inside the kernel. It's safe, and there's a JIT, so it's pretty fast (is there really a JIT compiler running in kernel space?). It was originally used for packet filtering, but it's now used at various decision points in networking, and is somehow involved with tracing as well. But it could potentially go much further. Anywhere the kernel currently gets configured with data-like configuration could be replaced or augmented with an eBPF, right? For example, instead of setting an ACL on a directory, you could set an eBPF program which would run for each attempted access and decide whether to allow it, as well as logging or doing other stuff. eBPF programs could guard the interfaces between a container and its host, allowing more flexible isolation. An eBPF program could respond to every system call a process makes, allowing behaviour like OpenBSD's pledge, only much more sophisticated. With the right access control model (implemented in eBPF!), normal userland programs could install eBPF programs for resources they control (sockets, files, etc), potentially shifting a significant fraction of their processing into kernel mode, improving performance, reducing system call overhead, and allowing safe access to kernel facilities that are currently inaccessible. Imagine implementing a garbage collector in userspace, but being able to configure your slice of the virtual memory system in the kernel using an eBPF program. I don't know if this will happen. But a pervasively eBPF world would be very different, and very interesting. We'll have all sorts of fun. We'll get tools we never imagined. And we'll get pwned by black hats harder than ever before.