Toward signed BPF programs

Posted Apr 25, 2021 7:46 UTC (Sun) by chris_se (subscriber, #99706)
Parent article: Toward signed BPF programs

I'm struggling to understand the use case for this.

I view BPF programs as effectively use-space programs that rely on a different mechanism for privilege separation (in that case the BPF VM instead of the CPU's MMU) for performance reasons. You could design the kernel in such a manner that everything BPF does could also be done in userspace (and the vast majority of it actually could), albeit with a lot of performance penalties that make some things intractable.

From that perspective: what's the threat model that these signatures try to fend off? If you really want to make sure that only signed code is running, why couldn't that also be accomplished by requiring signatures on the user-space programs that set up the BPF programs? Then you'd have implicitly signed the BPF programs themselves. And if you don't want to require signatures on all user-space programs, but don't trust the BPF verifier, you should disable BPF entirely and just put your specialized functionality into a custom kernel module that can be signed.

But even if you wanted to sign BPF programs: the current solution appears to be overly complicated. Why not compile them into kernel modules (that already can be signed) that create and register the programs, and allow userspace to select a program from the list of registered signed BPF programs?

to post comments

Toward signed BPF programs

Posted Apr 30, 2021 21:05 UTC (Fri) by ecree (guest, #95790) [Link]

+1 to this.

You could, for instance, have a version of `bpftool` that checks signatures on the BPF-program elves, and in turn is signed itself, and then (if you want the kernel to enforce the signature requirement) the kernel checks the signature on `bpftool` before accepting its bpf() calls.

eBPF has gone down a road of over-abstraction, over-indirection and over-complexification in the last couple of years. I wish I'd pushed back more, but I've been too busy with other things to argue with each piece on the ML. The fact that putting the BPF loader into the kernel proved too difficult is not an argument for BPF_PROG_TYPE_SYSCALL; rather, it's an indictment of the BPF loader.