Re: Why is this thing named after the BPF?
Because the BPF could run arbitrary code to analyze network packets?
"[T]he kernel statically analyzes the programs before loading them,[sic] in order to ensure that they cannot harm the running system."
(From man bpf, commas akimbo, mayhap bugs likewise.)
We can find the detailed description of the analysis (https://docs.kernel.org/bpf/verifier.html); the kernel won't, of itself, crash or visit 1 infinite loop when it runs the code. Unlike classic BPF it apparently spots code that has unreachable instructions (i.e. it doesn't allow code which has secret extra code that can't, actually, be executed.)
This is all fine; it's just messing with packets. What I don't get is why someone would allow it to mess with scheduling (like, I've brought down machines by giving the wrong process real time priority).
It is, of course, bad enough to be able to comment on a packet. Well, here's the answer:
https://docs.kernel.org/bpf/kfuncs.html
So if you want eBBF to be able to say, encrypt a disk drive, you have to persuade Linus to take a kernel patch as well; a kernel patch that exposes the Linux internal ransomware implementation to the eBPF engine.
Not that I am saying this is good because it is in the hands of the god. I've always been against Turing, except in real animals. Exposing even one API to eBPF seems to be a certain recipe for disaster:
"When an existing function in the kernel is fit for consumption by BPF programs,[sic] it can be directly registered with the BPF subsystem. However,[sic] care must still be taken to review the context in which it will be invoked by the BPF program and whether it is safe to do so."
(From my previous reference.)
Too much rope and too many commas.