Hacker News Reader

Comment by xyzzy_plugh | Hacker News Reader

I've crashed multiple kernels with eBPF programs. I don't buy this argument at all.

I call bullshit! Ebpf programs cannot crash the kernel since they cannot be run if they contain bugs in the first place.

That assumes that the virtual machine has no bugs

Not so much (eBPF VM bugs are pretty rare, as you'd expect, since the VM is very simple) --- you're much more likely to run into bugs in the C-code helpers the kernel exports. If you're malicious, you can also hit verifier bugs that'll give your eBPF code raw pointers, but I don't think you're likely to stumble on them accidentally.

The kernel, however, can and does have bugs. I've seen several thousand hosts get taken down with a perfectly correct eBPF program due to a buggy kernel.

I said 'less' rather than 'at all' for a reason. I'm not really sure what to tell you if you disagree that it's a lot easier to accidentally crash your kernel with a from-scratch module than ebpf though. That's an experience pretty drastically at odds with mine.

Can you describe some of those bugs? What helpers were you using? I've been doing bonkers stuff with eBPF for the last year and, while I've definitely had bugs, none of them took my kernel down.

I no longer have access to the code, and the kernel has since been patched. Mostly doing some observability around new network connections.

We definitely hit this one at some point: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1763454

We also ran into a couple of similar but unrelated panic bugs on much newer kernels on non-Ubuntu distros.

Those would be considered kernel bugs though, and should be getting fixed when reported. While a crash in a kernel module is just a bug in the kernel module itself

Could you share the ebpf program and the external dependencies that can reproduce the crash?

It'll be valuable to learn this, so that we might be able to proactively address them. Ebpf is the core of our product.

Reply on news.ycombinator.com