eBPF – The Future of Networking and Security
1–10 of 38 posts
Re: eBPF – The Future of Networking and Security
#2I'm not an expert in BPF by any means. My gut tells me that the hype of eBPF is an example of Hyrum's law. That is, eBPF will be leveraged beyond its design intent, as an in-kernel JIT engine. This is more a comment on human nature than the technology itself.
Re: eBPF – The Future of Networking and Security
#3Fuck to HN for shadow banning
Re: eBPF – The Future of Networking and Security
#4I'm not an expert in BPF by any means. My gut tells me that the hype of eBPF is an example of Hyrum's law. That is, eBPF will be leveraged beyond its design intent, as an in-kernel JIT engine. This is more a comment on human nature than the technology itself.
Even looking at the original BPF which focused on filtering packets as they are forwarded to userspace (think tcpdump)[1] and looking at the extensions that eBPF provides on top to hook into various subsystems[2,3], it's clear that this is going far beyond the use cases originally envisioned. I'd love to see an eBPF paper to follow up / contrast with the '93 USENIX BPF paper.
[1]: https://www.tcpdump.org/papers/bpf-usenix93.pdf
[2]: https://ebpf.io/what-is-ebpf#hook-overview
[3]: http://www.brendangregg.com/BPF/bpf_performance_tools_book.p...
Re: eBPF – The Future of Networking and Security
#5I'm not an expert in BPF by any means. My gut tells me that the hype of eBPF is an example of Hyrum's law. That is, eBPF will be leveraged beyond its design intent, as an in-kernel JIT engine. This is more a comment on human nature than the technology itself.
Easy to predict something that's already happening. :)
https://github.com/xdp-project/xdp-tutorial
It's a good thing, I think! Compared to loading new unmanaged C code into the kernel, BPF is a really nice way to add functionality to Linux.
Re: eBPF – The Future of Networking and Security
#6I'm not an expert in BPF by any means. My gut tells me that the hype of eBPF is an example of Hyrum's law. That is, eBPF will be leveraged beyond its design intent, as an in-kernel JIT engine. This is more a comment on human nature than the technology itself.
Even looking at the original BPF which focused on filtering packets as they are forwarded to userspace (think tcpdump)[1] and looking at the extensions that eBPF provides on top to hook into various subsystems[2,3], it's clear that this is going far beyond the use cases originally envisioned. I'd love to see an eBPF paper to follow up / contrast with the '93 USENIX BPF paper. [1]: https://www.tcpdump.org/papers/bpf-u…
FWIW: I just wrote a long-ish post on the history from BPF (and before BPF) to eBPF and XDP:
https://fly.io/blog/bpf-xdp-packet-filters-and-udp/
An interesting fact is that packet filtering as a problem domain has been dominated by in-kernel virtual machines going back into the 1980s; it's an idea that comes all the way from Xerox.
Re: eBPF – The Future of Networking and Security
#7Disclaimer: I wrote the post.
Happy to answer any questions.
Re: eBPF – The Future of Networking and Security
#8The future ought to be capabilities. All this policy scripting stuff is just drudgery make-work that gets us nowhere.
Re: eBPF – The Future of Networking and Security
#9I'm not an expert in BPF by any means. My gut tells me that the hype of eBPF is an example of Hyrum's law. That is, eBPF will be leveraged beyond its design intent, as an in-kernel JIT engine. This is more a comment on human nature than the technology itself.
Even looking at the original BPF which focused on filtering packets as they are forwarded to userspace (think tcpdump)[1] and looking at the extensions that eBPF provides on top to hook into various subsystems[2,3], it's clear that this is going far beyond the use cases originally envisioned. I'd love to see an eBPF paper to follow up / contrast with the '93 USENIX BPF paper. [1]: https://www.tcpdump.org/papers/bpf-u…
The shift from BPF to eBPF was less of an evolutionary step as the name might indicate. The overlap with the name BPF is primarily due to the requirement for eBPF to be a superset of BPF in order to avoid having to maintain two virtual machines long-term. This was one of the conditions for eBPF to be merged and in that context, the name eBPF made sense.
Re: eBPF – The Future of Networking and Security
#10Earlier quoted context omitted.
Even looking at the original BPF which focused on filtering packets as they are forwarded to userspace (think tcpdump)[1] and looking at the extensions that eBPF provides on top to hook into various subsystems[2,3], it's clear that this is going far beyond the use cases originally envisioned. I'd love to see an eBPF paper to follow up / contrast with the '93 USENIX BPF paper. [1]: https://www.tcpdump.org/papers/bpf-u…
The shift from BPF to eBPF was less of an evolutionary step as the name might indicate. The overlap with the name BPF is primarily due to the requirement for eBPF to be a superset of BPF in order to avoid having to maintain two virtual machines long-term. This was one of the conditions for eBPF to be merged and in that context, the name eBPF made sense.
Disagree (see sibling post). Classic BPF could have been translated into any virtual machine design they came up with (because classic BPF is incredibly simple). When McCanne came up with the same design in 1998, his team called it "BPF+", for the same reason eBPF is called eBPF --- because it is pretty much an evolution of the earlier idea.