Is BPF just a worse version of WebAssembly?

Posted Apr 16, 2025 17:38 UTC (Wed) by daroc (editor, #160859)
In reply to: Is BPF just a worse version of WebAssembly? by DemiMarie
Parent article: Taking BPF programs beyond one-million instructions

The thing that makes BPF unique among similar languages/runtimes is its ability to verify that certain program properties hold, beyond just memory safety. A BPF program is checked to make sure that it never deadlocks, never takes a lock without releasing it, never sleeps with a lock, always handles reference counts in kernel objects correctly, doesn't run too long, doesn't use more than a bounded amount of memory, doesn't allocate in contexts where that isn't allowed, doesn't do type-confusion to kernel data, and probably more that I'm forgetting. Those are all important to ensuring that loaded BPF programs don't break a running kernel.

Whether that approach is worthwhile compared to WebAssembly is a value judgement; you could theoretically replace BPF with WebAssembly in the kernel, if you were willing to customize the runtime to do the necessary checks. I don't think anyone has done a good comparison of what the speed impact would be, although there would likely be some overhead, at least.

Is BPF just a worse version of WebAssembly?

Posted Apr 16, 2025 18:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> A BPF program is checked to make sure that it never deadlocks

But only for one lock at a time. It would have been trivially easy (and just as fast) to do in runtime.

> Whether that approach is worthwhile compared to WebAssembly is a value judgement; you could theoretically replace BPF with WebAssembly in the kernel, if you were willing to customize the runtime to do the necessary checks

You can't automatically reason about complicated code. So the BPF infrastructure is already growing all sorts of runtime checkers.

I predict that we'll get a classic "memory safe BPF without a verifier" within maybe 2 years, once it becomes clear that the verifier is a fifth wheel.

Is BPF just a worse version of WebAssembly?

Posted Apr 16, 2025 19:26 UTC (Wed) by npws (subscriber, #168248) [Link] (1 responses)

While the load-time verification certainly has some limitations and your prediction doesn't seem entirely unreasonable, I don't see how various conditions it checks could be checked at runtime without adding overhead to the entire kernel.

Is BPF just a worse version of WebAssembly?

Posted Apr 17, 2025 4:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Why would it matter for the rest of the kernel? BPF will just need to add runtime checks to its own arrays access, instead of relying on the verifier.

Is BPF just a worse version of WebAssembly?

Posted Apr 16, 2025 20:06 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

It sounds like BPF is converging towards Rust, and sooner or later we'll get a Rust backend that emits BPF, having checked the properties you mention using Rust's type system.

Is BPF just a worse version of WebAssembly?

Posted Apr 16, 2025 21:18 UTC (Wed) by daroc (editor, #160859) [Link]

You can compile simple Rust programs to BPF today, as long as you avoid anything the verifier doesn't know how to handle, I believe. But in practice there's a long way to go for the language to be a fully supported alternative.

In this case, though, I think there's an important difference between Rust's guarantees and BPF's guarantees: who does the checking. I'm currently working on writing up an LSFMM+BPF article about signing BPF programs, and it's a hard question because ideally you want verification to happen in the kernel, so that you don't need to trust in user space.