BPF as a safer kernel programming environment

Posted Sep 25, 2022 19:55 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
Parent article: BPF as a safer kernel programming environment

Can we just switch from BPF to WASM?

BPF as a safer kernel programming environment

Posted Sep 25, 2022 21:30 UTC (Sun) by Subsentient (guest, #142918) [Link] (3 responses)

Why bother with WASM? Just use Rust. It's now possible to write good kernel drivers in Rust, though support isn't mainline until 6.1. Still should be good enough in the meantime, especially if you're writing a proprietary module that doesn't need to be mainlined.

BPF as a safer kernel programming environment

Posted Sep 26, 2022 5:07 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

BPF is used mostly for dynamic instrumentation, which should be a perfect use-case for WASM.

BPF as a safer kernel programming environment

Posted Sep 26, 2022 14:33 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

Would not lack of 64bit WASM be a problem ?

BPF as a safer kernel programming environment

Posted Sep 26, 2022 15:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

There is a fairly straightforward proposal to add 64-bit indexes to WASM: https://github.com/WebAssembly/memory64

But it won't even be necessary, because WASM is used in a sandbox and works with the external world via well-defined accessors only. Just like eBPF for that matter.

BPF as a safer kernel programming environment

Posted Sep 26, 2022 17:18 UTC (Mon) by kid_meier (subscriber, #93987) [Link] (4 responses)

Can WASM be verified as safe in the same way that the BPF verifier currently is able to validate eBPF?

I am ignorant of details myself but had the impression that BPF is designed to be (easily?) verifiable and maybe WASM is less suitable in this context.

BPF as a safer kernel programming environment

Posted Sep 26, 2022 18:14 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

WASM is designed from ground up to be safe, as it's used in browsers (which is probably the most aggressive computing medium imaginable). eBPF verifier is far less robust.

BPF as a safer kernel programming environment

Posted Sep 28, 2022 11:13 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

BPF verifier does have the notable feature (or misfeature) of being able to prove that the program will successfully complete in a bounded execution time.

Wasm doesn't do that. A wasm program is allowed to loop forever, or to abort.

BPF as a safer kernel programming environment

Posted Sep 28, 2022 16:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> BPF verifier does have the notable feature (or misfeature) of being able to prove that the program will successfully complete in a bounded execution time.

WASM programs can be suspended after a given number of instructions ("fuel"), at least if you're using the "wasmtime" runtime. This is essentially the same functionality. Moreover the "fuel" limits can be configured during the runtime so you can easily have different settings for different types of instrumentation.

> Wasm doesn't do that. A wasm program is allowed to loop forever, or to abort.

The only thing you really need to add to WASM is the "default value" that would be returned on termination or fuel exhaustion.

BPF as a safer kernel programming environment

Posted Oct 6, 2022 21:53 UTC (Thu) by njs (subscriber, #40338) [Link]

I think the issue is that if your program is mutating kernel structures, then it may not be safe to kill it mid-stream -- you need some strategy for safely unwinding from an arbitrary point in execution. This seems like a pretty reasonable thing to me, but I guess so far eBPF has decided to make the tradeoff of investing in the verifier infrastructure instead of unwinding infrastructure.