LWN: Comments on "Modernizing BPF for the next 10 years"

WASM?

Cyberax — Mon, 10 Jun 2024 17:11:13 +0000

I doubt that this tracking adds any real value. For practical reasons, it's likely that just adding range-checking accessors should be enough for practical reasons.

I'm also going to bet, that eBPF will grow pointer arithmetic that can re-interpret types in the future.

WASM?

roc — Mon, 10 Jun 2024 07:31:00 +0000

The eBPF verifier does type propagation and checking and prevents pointer arithmetic. https://docs.kernel.org/6.1/bpf/verifier.html#register-va...
It's not well documented and all very ad-hoc, but this is not the usual WASM array-of-bytes model.

I think the closest WASM equivalent of this is reference types, which are pretty new. I don't see instructions for doing field load/stores via references yet.

WASM all the way.

Cyberax — Sat, 08 Jun 2024 18:35:42 +0000

> * to replace the eBPF VM in the kernel by the WASM VM, and to replace all the eBPF call sites with WASM equivalents

First, it's not needed. eBPF can stay in its current roles and for legacy stuff like the actual packet filter. And eventually you can just run eBPF on top of WASM. This is perfectly doable right now, there's nothing special in eBPF.

> In the end, does it really matter which VM is used?

Kinda yes. eBPF is becoming a generic VM, but built on top of a hacky NIH-ed instruction set that is a very poor fit for general purpose programming. And we'll be forever saddled with it, and all of its eventual bugs and misfeatures.

WASM all the way.

edeloget — Sat, 08 Jun 2024 18:15:16 +0000

> If they wanted the BPF programs to have certain properties (like, not getting stuck in an infinite loop) it seems like the compiler* ought to be responsible for analyzing and enforcing that not the BPF instruction set.

I think I said this numerous times, but the kernel will still have to verify the program when it loads it. You do not want to allow arbitrary program to run in your kernel without proper checking first. Just like the web backend shall verify the user input, even if it's checked by the JS on the client side. It does not matter if you execute you web server in a super controlled environment, letting attacker-controlled values dance with your backend is not a good idea :)

On the more general WASM vs BPF discussion, I have the feeling that the two serve different purposes using similar technology and techniques. eBPF evolved from BPF (which, as I understand it, predates WASM by 'some time') and was devised by network-minded people who wanted to enhance the possibilities of the venerable filtering language. WASM was clearly not designed with this in mind. Up to very recently, eBPF was significantly inferior to WASM in terms of VM(1) possibilities, but on the other end ePBF was really a good fit for the kernel itself. The recent enhancement of eBFP makes WASM look like a good replacement, but pushing WASM in the kernel would mean:

* to replace the eBPF VM in the kernel by the WASM VM, and to replace all the eBPF call sites with WASM equivalents, which is going to be a daunting task ; while technicaly it seems to be feasible, noone has ever checked this, and their is a good possibility that some feature proposed by eBPF will not be implementable with an in-kernel WASM VM.

Doing this would likely require multiple kernel release cycles, and in the end you'll get the same features as now. The value of such a change is limited (and I'm pretty sure that may of you would find ti quite ridicule to see this development U-turn.

If you don't *replace* the VM but only add the WASM one, you'll have to maintain two similar VM in the kernel -- that does not look like a good idea to me (and the WASM VM would need years before it reach a state where it would be able to compete with the eBPF VM).

* to tell everyone to stop using eBPF ; that looks like it's going to be easier, but let me introduce you to one of my friends, Cobol.

In the end, does it really matter which VM is used? The kernel developpers are doing quite an incredible job with eBPF support, so WASM, at this point, would add nothing of value -- or, at least, too little to be really of interest. We also have compilers that spit out eBPF byte code, so we're not in need of "having to know yet another language".

(1) I use the term VM quite loosely here ; I just mean: "whatever is used to execute the eBPF or WASM code as well as its controlled environment".

WASM?

aszs — Sat, 08 Jun 2024 11:15:14 +0000

The BPF verifier validates pointers, (within its sandbox) WASM does not.
See, for example, https://dl.acm.org/doi/10.1145/3571208:
"memory-unsafe C code remains unsafe when compiled to Wasm—and attackers can exploit buffer overflows and use-after-frees in Wasm almost as easily as they can on native platforms."
(And I just noticed one of that paper's authors is also a contributor to the Wasm spec)

WASM?

Cyberax — Sat, 08 Jun 2024 02:25:40 +0000

WASM and BPF instructions and registers are equally typed. And access to memory is equally untyped: https://www.kernel.org/doc/html/latest/bpf/standardizatio...

At this point there's no conceptual between WASM and eBPF. The eBPF runtime tries to be more resilient to timing attacks (via constant blinding), but that's a property of runtime. It can be added to WASM runtimes.

WASM?

roc — Fri, 07 Jun 2024 23:52:25 +0000

BPF still has a different idea about memory, right? In WASM memory is basically a sandboxed array of bytes. AFAIK BPF is a bit more like a typed memory-safe language where you can't do pointer arithmetic but you can safely access objects scattered across the address space of the kernel.

WASM all the way.

python — Fri, 07 Jun 2024 22:12:55 +0000

I agree. They would save themselves a lot of work. But perhaps "WASM wasn't invented here" so it is no good? (I could imagine certain kernel folks wanting nothing to do with "web people")

I find the path that BPF is taking to be a bit baffling. I feel like they are making a systematic effort to reinvent the wheel (admittedly their wheel is very well suited for certain specific purposes). It feels BPF program are becoming something akin to kernel modules, but wrapped in a special/quirky permission protected half-bpf-userspace-half-kernel thingy.

WASM, or just running (JIT?) compiled native instructions in a secure or virtualized environment seems like it would be a lot easier. If they wanted the BPF programs to have certain properties (like, not getting stuck in an infinite loop) it seems like the compiler* ought to be responsible for analyzing and enforcing that not the BPF instruction set.

*a cross between something like the TLA+ theorem prover and a standard compiler. Rust does something like this for analyzing and enforcing proper memory access. But it easily could be done for other program properties.

WASM?

Cyberax — Fri, 07 Jun 2024 16:00:24 +0000

> Making BPF programs safely cancellable, with run-time timeouts to augment program verification, will probably become necessary. Starovoitov said that work was already in progress.

So... Why not WASM?

Like really. At this point, you've abandoned ALL the original reasons for BPF.