LWN: Comments on "BPF as a safer kernel programming environment"

BPF as a safer kernel programming environment

sammythesnake — Wed, 12 Oct 2022 08:47:11 +0000

If the eBPF program is to do anything useful, it has to calculate something that isn't already calculated. In the general case, the only way to know what values it will be manipulating is to run it. C.f. the halting problem.

There's still value in assertions at the start of the program regarding its input state (e.g. a range parameter must be under a certain size, perhaps) which might be checked before execution, but that's a fairly small subset of the assertions that might be useful within the eBPF program.

The approach taken by the verifier has been to verify the subset and reject anything it doesn't know how to verify. I guess there could be a mode that understands some subset of assertions (perhaps defined declaratively in metadata alongside the eBPF program) and falls back to executing assertion statements for others but that requires some means to respond to a failed assertion during execution, which might be decidedly nontrivial in some cases...

BPF as a safer kernel programming environment

njs — Thu, 06 Oct 2022 21:53:54 +0000

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.

BPF as a safer kernel programming environment

hiraditya — Wed, 05 Oct 2022 05:48:00 +0000

Is there any document describing the type system of eBPF? I'm curious if we can provide the semantics of linear types using eBPF

BPF as a safer kernel programming environment

developer122 — Sun, 02 Oct 2022 06:12:29 +0000

can't you just check assertions during verification? if everything is known beforehand, just check if they're reachable given current values.

BPF as a safer kernel programming environment

Cyberax — Wed, 28 Sep 2022 16:36:18 +0000

> 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

foom — Wed, 28 Sep 2022 11:13:44 +0000

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

Cyberax — Mon, 26 Sep 2022 18:14:55 +0000

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

kid_meier — Mon, 26 Sep 2022 17:18:07 +0000

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

Cyberax — Mon, 26 Sep 2022 15:39:24 +0000

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

ballombe — Mon, 26 Sep 2022 14:33:55 +0000

Would not lack of 64bit WASM be a problem ?

BPF as a safer kernel programming environment

Cyberax — Mon, 26 Sep 2022 05:07:13 +0000

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

BPF as a safer kernel programming environment

Subsentient — Sun, 25 Sep 2022 21:30:48 +0000

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

amarao — Sun, 25 Sep 2022 20:34:57 +0000

Yes. Systemd is using it to implement firewall (AllowedIP stanza). It's sound ironic, but ebpf is used as bpf...

BPF as a safer kernel programming environment

Cyberax — Sun, 25 Sep 2022 19:55:14 +0000

Can we just switch from BPF to WASM?

BPF as a safer kernel programming environment

zdzichu — Sun, 25 Sep 2022 13:16:24 +0000

If something is used by hyperscalers, doesn't it automatically cover 90+% of Linux use (excluding Android)?

BPF as a safer kernel programming environment

Sesse — Sun, 25 Sep 2022 09:10:44 +0000

For all the hype of eBPF—is it actually widely used? I mean, I've used xfsslower and such from bfpcc-tools (which is neat, although it takes way too long to start up and is fairly primitive), but in my normal day-to-day work, I don't really feel like all these kernel hooks is something I _need_ or even can make good use of. I'm sure hyperscalers can do all sorts of weird and wonderful things with it, but it still feels like a long way to go before this is mainstream?

BPF as a safer kernel programming environment

corbet — Sat, 24 Sep 2022 15:19:26 +0000

Most symbols (including all kfuncs as I understand it) for BPF programs are GPL-only. Of course, the kernel has to trust a BPF program that declares itself to be GPL-licensed, but the situation is no different that for modules in that regard.

BPF as a safer kernel programming environment

gray_-_wolf — Sat, 24 Sep 2022 15:12:16 +0000

> I suspect the main limitation to a wave of proprietary eBPF programs is that it's still pretty far from parity with a full blown module.

If that is indeed the case, I must say I'm unhappy about it from the freedom point of view :/

I know that kernel does have some functions exposed only for GPL-licensed modules, at least that is my understanding. Is something similar also in the eBPF or there every program has everything available, regardless of licensing?

BPF as a safer kernel programming environment

Wol — Sat, 24 Sep 2022 08:05:18 +0000

> So, BPF and eBPF are still restricted to bounded loops — no infinite loops, and no recursion? In other words they are not Turing complete. (This is not a criticism, just want to clarify.)

I believe that is in the language specification - a program must complete in bounded time or fail. This precludes Turing completeness ... :-)

(Enforced by the checker - if it cannot solve the Halting Problem for that particular executable, it is not allowed to start.)

Cheers,
Wol

BPF as a safer kernel programming environment

epa — Sat, 24 Sep 2022 07:23:59 +0000

So, BPF and eBPF are still restricted to bounded loops — no infinite loops, and no recursion? In other words they are not Turing complete. (This is not a criticism, just want to clarify.)

In a way the use of BPF to replace kernel modules reminds me of Firefox extensions moving from the original C++ compiled blobs to JavaScript. And that suggests that in some cases BPF might be useful as an extension language in user space. I don’t think it will ever replace JavaScript for web browsers but maybe for in-house use? Like how Emacs has a core in C and the rest in Lisp. For soft real-time applications you might want to guarantee that the non-core code can never hang or get stuck in a loop.

BPF as a safer kernel programming environment

tux3 — Fri, 23 Sep 2022 22:17:55 +0000

I've seen one instance already. Crowdstrike has a thoroughly closed-source endpoint surveillance sensor program that until now relied on a kernel module to do most of the snooping and hooking. This involves them shipping about 800MB of kernel modules binaries in an .xz archive, one for every supported system under the sun. And of course it breaks if you update your system.
They're apparently giving up on maintaining their module and planning to replace it with eBPF, even if that currently means losing some functionality.

I suspect the main limitation to a wave of proprietary eBPF programs is that it's still pretty far from parity with a full blown module. For vendors that don't mind the loss (or that can do everything in eBPF), I suppose we'll have to see how much worse the eBPF binary blobs are to deal with than the binary modules.

My hope is that decompilers will eventually handle eBPF bytecode as well if not better than compiled C. At the end of the day this could even be a slightly lesser evil for end-users, if it turns out that the blobs are easier to reverse.

BPF as a safer kernel programming environment

gray_-_wolf — Fri, 23 Sep 2022 19:11:18 +0000

Given all the work on making eBPF more powerful (and portable between kernel versions), can we expect new wave of proprietary closed-source kernel modules, but this time implemented as eBPF programs?

BPF as a safer kernel programming environment

mdaverde — Fri, 23 Sep 2022 17:18:55 +0000

I'm excited for the future that's laid out by ast. It feels like a new primitive has been added to the kernel where the value that is to be unlocked on top of it is still unknown but leans powerful. One aspect I will be critical in is that if that is the stated "mission statement" then a lot of work has to be done outside of core kernel technical work to allow others to innovate. Hopefully the eBPF foundation can successfully foster a community around documentation, tooling, standardization in an accessible way.