Hacker News Reader

Comment by throwaway2037 | Hacker News Reader

throwaway2037

The blog post says:

    > eBPF, which is immune to such crashes.

I tried to Google about this, but I cannot find anything definitive. It looks like you can still break things. Can an expert on eBPF please comment on this claim? This is the best that I could find: https://stackoverflow.com/questions/70403212/why-is-ebpf-sai...

View on HN

eBPF programs cannot crash the kernel, assuming there are no bugs in the eBPF verifier. There have been such bugs in the past but they seem to be getting more and more rare.

Or in other parts of the kernel. It's been the case in multiple occasions that buggy locking (or more generalised, missing 'resource' release) has caused problems for perfectly safe BPF programs. For example, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033398 and the fix https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

This is actually exactly the bug I was thinking of, so fair point! (I work at PS now and am aware you worked on debugging it a while back).

This isn't really true. eBPF programs in Linux have access to a large set of helper functions written in plain C. https://lwn.net/Articles/856005/

I don't see how this contradicts what I said. Indeed, there are helpers, but the verifier is supposed to check that the eBPF program isn't calling them with invalid arguments.

I would be very hesitant to say "cannot" in a million-line C code base.

Yes, bugs in Linux are possible, so there might be some eBPF code that crashes the kernel. Just like bugs in Chrome are possible, so there might be some JavaScript that crashes the browser. Still, JavaScript is much safer than native code, because fixing the bugs in one implementation is a tractable problem, whereas fixing the bugs in all user code is not.

Reply on news.ycombinator.com