Comment by tuetuopay
1 day ago
Sure! I use the aya framework (https://aya-rs.dev) that provides the kernel-side bindings to write the probes in Rust, and the userspace tooling to load it in the kernel, interacts with maps, etc. Quite a joy to work with, and has all the niceties you'd expect from using Rust.
We write XDP apps for custom dataplanes where traditionally DPDK would be used (routers and such). Our upcoming network acls are written this way, so close to your netfilter usage.
What is the current legal status of eBPF? It used to be that loading any non-trivial eBPF into kernel involved GPL-only stuff, and both the eBPF program and the program that used it had to be GPL.
Well, yes, but this only matters if you distribute the compiled probes: you'll have to distribute the source for the probes. And, thankfully, this is not AGPL where network interaction counts, so:
- a cloud provider writing a dataplane using ebpf does not have to provide the source - a company selling on-prem software (e.g. esxi) that ships with ebpf probes would need to distribute their source
(note: IANAL)
Very cool and fun.
I do worry about running so much stuff in kernel space though. Imagine a widespread 0day that hits the kernel, or kernel panics causing kernel crashes that require reboots, the user space priv escalation, etc...
Are you doing fail-open or fail-closed? I've been on the fence on that.