joestringer

5 anni fadiscuss

The packet-processing BPF programs are less tightly bound to Linux kernel APIs than you might think. Even in Linux, there has been motivation to make the APIs more generic to support different kernel hooks for packets, in particular XDP which doesn't operate on the standard internal packet buffer representation (skbuff).

joestringer

6 anni fadiscuss

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...

joestringer

6 anni fadiscuss

This seems to be around the wrong way.

For both traditional kernel modules and eBPF programs, you compile the code ahead of time. For kernel modules, if you have a bug, you load it into the kernel and the kernel hard crashes at runtime. For eBPF programs, the kernel will reject the program before you inject it.

In practice to deploy eBPF programs, you end up adding the kernel verification step into part of your CI/dev workflow so that by the time you ship your programs, you know that they will safely load and safely run in real environments.

comments