Just drop the verifier [LWN.net]

Just drop the verifier

Posted Apr 15, 2025 6:18 UTC (Tue) by epa (subscriber, #39769)
Parent article: In search of a stable BPF verifier

Why does the BPF verifier have to live in the kernel at all? If you have root, and it’s not some locked-down Secure Boot system, then at any time you can build some C code and load it into the kernel as a module. There is no verification that the C code doesn’t have infinite loops or memory trampling. You run it at your own risk. So why can’t you load arbitrary BPF? Of course you’d probably want to verify it first, but that can be done in user space using the verifier of your choice.

Just drop the verifier

Posted Apr 15, 2025 7:33 UTC (Tue) by taladar (subscriber, #68407) [Link]

I think dropping the verifier is a bad idea since the idea that people will be disciplined enough to use it anyway has been thoroughly debunked but it could maybe move to user-space with callbacks from the kernel to invoke it similar to some other existing parts of the kernel.

Just drop the verifier

Posted Apr 15, 2025 8:45 UTC (Tue) by ballombe (subscriber, #9523) [Link]

The verifier needs to match the kernel evaluator.

Just drop the verifier

Posted Apr 15, 2025 17:05 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

Isn't that how SystemTap worked, building little tracing modules and loading them. I think for the kernel though you can't exclude some use case just because it's not relevant to you, it's relevant to someone so the central kernel has to work within those constraints, and there is less value to maintaining separate behavior when those constraints aren't active than just engineering with those constraints all the time. I'm not sure what the use case would be for loading unvalidated BPF that wouldn't be better served by just loading a custom module, the whole point of using BPF is to provide a safety shield, using BPF without that safety doesn't seem to make sense.

Just drop the verifier

Posted Apr 15, 2025 21:17 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

I’m not saying to drop the safety and load BPF without validating (although there are those taking that stronger position, arguing that runtime checks are enough). I am saying to run the validator in user space and then once you’re satisfied tell the kernel to load the code. Those separate steps could be packaged up in some tool. There is no need for ‘nannying’ from the kernel to verify the code itself. The computer is there to obey the user, not the other way round: if you have root access and you have decided some BPF is safe to load, it should let you.

Just drop the verifier

Posted Apr 16, 2025 2:22 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

I guess I don't know what the standard is for trusting the result of a process in user space, I think in most contexts the kernel does some sanity checking of anything crossing the boundary from user space, to protect its own address space.

This makes me think of the swap convo, maybe a special namespace could be standardized which contains only a limited image of necessary trusted utilities, maybe keeping the initial ramdisk around for this purpose, that the kernel can trust is only accessible to the legit admin and is somewhat inside the security boundary of the kernel although not in it's address space. A special admin container

Just drop the verifier

Posted Apr 16, 2025 16:53 UTC (Wed) by epa (subscriber, #39769) [Link]

I guess you're right -- if invalid BPF could result in memory trampling then the kernel needs to protect itself. Though, again, in principle you could build a kernel module in C and load that without any checks.

I was thinking more of the verification that checks BPF programs always terminate and other higher-level properties. It should be possible to say "trust me" on that.