[mirashii]

> which is very important for the kind of thing eBPF is(1)

The question is, going into 2026, what kind of thing is eBPF? It seems like all hope of it being a security boundary has been thwarted by micro-architectural vulnerabilities to the extent that you can no longer load eBPF programs as non-root. So, is it a security boundary? That's an honest question that I've not been able to find an answer to in the kernel documentation or recent mailing list posts.

If it's not a security boundary, what is it? There's a few other nice properties enforced by the validator, like protos for a subset of kernel functions, which provides some load-time validation that you've built against a compatible kernel. That's something that's lost here, so we don't get the same compile once, run everywhere properties eBPF has. One might argue this is a big loss, but in the branch that eBPF is not a security subsystem, it's worth asking whether these are strictly necessary checks that need to be enforced, or whether they're niceties that bring a higher hope of stability and reduce the burden of code review that are perfectly fine to bypass given those caveats.

[deivid]

IMO eBPF is best viewed as a mechanism that allows you to load "arbitrary" code in specific kernel paths, while guaranteeing that the kernel won't hang or crash.

That's it. Though I said "arbitrary" because the program has to pass the verifier, which limits valid programs to ones where it can make the stability guarantees.

[twoodfin]

A stable kernel API?

[convolvatron]

its not a very well designed or stable api. its certainly not comprehensive.