everytime i hear about eBPF being the preferred (or, more frequently, only) interface for new Linux functionality, some part of me dies inside
Conversation
case in point: to launch a program using a different routing context (networking people call these VRFs) than the default routing context, you have to use eBPF to do it
6
13
Replying to
REUSEPORT is another example. They provided a way to distribute connections to a thread pool pinned to cores in a way that keeps it on the same core that the kernel was using. Now you can attach an eBPF program and they accidentally broke the standalone API but won't fix it.
1
2
4
I'm sure you remember grsecurity's gid-based socket access feature. Android implemented essentially the same thing in order to implement the core of the INTERNET permission, which we turn into a Network toggle. Upstream wouldn't take this so 20 lines of code was replaced with 5k.
1
1
Since there are no longer any downstream patches required and you can use mainline kernels with Android, they had to turn several things into far more complex eBPF implementations. A significant part of the data usage statistics for apps/interfaces also got turned into eBPF.
At least there's absolutely no unprivileged eBPF on Android and only a bpfloader process is allowed to use it in the static SELinux policy, and only netd is allowed to use bpfloader. netd is the CAP_NET_ADMIN manager of network stuff like iptables. Still way more complex now.
And now I'm wondering about churn in ebpf code. Are there lots of breaking changes and one needs to check for kernel versions?