LWN: Comments on "A possible path for cancelable BPF programs"

Sigh. NIH continues.

Cyberax — Wed, 26 Feb 2025 20:27:57 +0000

Classic BPF is ancient. The new eBPF with all the bells and whistles started taking shape around 2016. At some point, they should have done a bit of self-reflection and looked at the state of the art around them.

But yeah, all other technologies have just one fatal flaw.

Just freeing locks? Doesn't that corrupt data?

aviallon — Wed, 26 Feb 2025 10:44:32 +0000

I second this. Some resources just can't be released at any random time.
Or is it that BPF programs can't modify problematic resources directly anyway?

Just freeing locks? Doesn't that corrupt data?

taladar — Wed, 26 Feb 2025 09:00:16 +0000

Isn't the idea that locks can just be freed at any time overly naive? Maybe that works for read locks but for write locks that would cause a lot of issues.

Usually write locks are held to make some changes to a data structure that should not be seen by anyone else in isolation but as a completed whole. If we just kill the program in the middle of such a change that would just leave the data structure in an undefined state forever, a much worse problem than a BPF program taking longer to finish than anticipated.

Sigh. NIH continues.

tullmann — Wed, 26 Feb 2025 05:24:45 +0000

The original BPF paper is from 1992, so I don't think this is a case of NIH.

I do think the idea of isolating untrusted code so you can cleanly and efficiently terminate it is ... what user mode was originally designed for. So there is definitely a lot of prior art nearby in the kernel ....

restricted BPF runtimes?

pj — Tue, 25 Feb 2025 20:58:41 +0000

Would this affect all BPF runtimes? I could imagine how some calls to a BPF module might want to limit their execution overhead by, for instance, having a lower permitted maximum number of instructions, while other places that aren't on such a deadline might have much more relaxed requirements.

Sigh. NIH continues.

Cyberax — Tue, 25 Feb 2025 20:27:49 +0000

BPF is basically repeating the entire WASM saga, with the same end result.

At what point are they going to admit that they literally reimplemented a WASM runtime piecemeal?

Just take the obvious approach already

roc — Tue, 25 Feb 2025 19:16:27 +0000

Dynamically tracking which resources need to be released is only a performance issue. Lots of things affect performance, e.g. the JIT. Therefore it doesn't make sense to impose "no dynamic tracking" as a hard design requirement.

> BPF, on the other hand, essentially makes anything the verifier can't understand the programmer's problem.

This is a nightmare. Other comparable systems (CIL, JVM, WASM) carefully define what bytecode programs are valid and pretty much never change them (maybe relaxing a bit here and there), but valid bytecode is rich enough for compilers to compile any valid source program so users don't have to care.

I hope the BPF community eventually figures this out, but they're accumulating a horrendous amount of baggage in the meantime.