> In the future, computers will not crash due to bad software updates, even those updates that involve kernel code. In the future, these updates will push eBPF code.<p>eBPF is fantastic, and it can be used for many purposes and improve a lot of things, but this is IMO overselling it. Assuming that BPF itself it free of bugs, it’s still a rather large sprawl of kernel hooks, and those hooks invoke eBPF code, which can call right back into the kernel. Here’s a list:<p><a href="https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html" rel="nofollow">https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html</a><p>bpf_probe_read_kernel() is particularly heavily used, and it is <i>not</i> safe. It tries fairly hard not to OOPS or crash, but it is definitely not perfect.<p>The rest of that list contains plenty of this that will easily take down a system, even if it doesn’t actually oops or panic in the process.<p>And, of course, any tool that detects userspace “malicious behavior” and stops it can start calling everything malicious, and the computer becomes unusable.<p>Meanwhile, eBPF has no real security model on the userspace side. Actual attachment of an eBPF program goes through the bpf() syscall, not through sensibly permissioned operations on the underlying kernel objects being attached to, and there is nothing whatsoever that confines eBPF to, say, a container that uses it. (See bpf_probe_read_kernel() -- it's fundamentally able to read all kernel memory.)<p>So, IMO, most of the benefit of eBPF over ordinary kernel C code is that eBPF is kind of like writing code in a safe language with a limited unsafe API surface. It's a huge improvement for this sort of work, but it is not perfect by any means.<p>> The verifier is rigorous -- the Linux implementation has over 20,000 lines of code<p>The verifier is absurdly complex. I'd rather see something based on formal methods than 20kLOC of hand-written logic.