4 ms·
You can maintain production safety by using a BPF->kernel module compiler. This additionally removes the need to have the bpf compiler in the kernel, reducing
by manyworlds 7y ago
You can maintain production safety by using a BPF->kernel module compiler.
This additionally removes the need to have the bpf compiler in the kernel, reducing both core size and vulnerability surface area.
No reason BPF must imply JIT
- monocasa 7y agoThe end goal with bpf is to allow arbitrary untrusted programs to load bpf programs. If you were just loading kernel modules you wouldn't be able to maintain kernel integrity and let arbitrary programs load code.
- youareawesome 7y agoLoading BPF requires root, so does loading kernel modules. I.e. if you have permissions to load BPF, you can already load arbitrary code.
- monocasa 7y agoAt the moment.
- sigjuice 7y agoI can't find the LKML thread, but there is some fundamental problem with unloading modules safely. BPF programs might not have such limitations.
- monocasa 7y agoOh, neat! Yeah, I didn't think of this but that totally makes sense. BPF programs declare their resources to the kernel (maps, etc.), but modules are reliant on the __exit function cleaning everything up properly. The correctness of __exit is unverified, difficult, and practically one of the least tested pathways which makes it traditionally fraught with bugs.
- manyworlds 7y agoA BPF->kernel module compiler would ensure all necessary cleanup happens in __exit automatically
- monocasa 7y agoA BPF to kernel module compiler wouldn't let the kernel verify the program in a real way. There's still work to be done, bit the end goal of BPF is pretty obviously to allow non root users to load programs. Doing the verification offline is a non starter. Appending the verification information and reverifying it at load time is more work than a BPF runtime as it is as you have to reproject ISA semantics in a more complex way.
- manyworlds 7y agoHmm I think bpf today is used in fully trusted environments. Kernel level verification is unnecessary except in untrusted containerized environments or when running untrusted applications, both use cases being relatively rare/specialized. I think the main benefit of bpf is that it prevents you from shooting yourself in the foot. Running totally untrusted code in the kernel just seems like a recipe for disaster and for that reason it makes sense bpf is still limited to root.
- monocasa 7y agoThat's where it is today, but the end goal is removing that restriction. It probably would have happened quicker if Spectre/Meltdown hadn't come out of nowhere. Like it used to be that KVM required CAP_SYS_ADMIN as well, but now that's been opened up to whoever has permissions to the device file. Start requiring "own the box anyway" privileges while the feature bakes, but open it up as it becomes more mature and attackers have a go at it. It's sort of like how originally you could only jump forward, then the opened it up to any DAG, then they allowed probably bounded loops. And there's been OSes that don't require root for their in kernel virtual machines, XOK and AEGIS being the prominent examples.
- rhinoceraptor 7y agoeBPF and kernel modules solve completely different tasks. If you need a kernel module to accomplish your task, then by definition you cannot accomplish it with eBPF.