A reminder that on the platforms eBPF is most commonly used, verifier bugs don't matter much, because unprivileged code isn't allowed to load eBPF programs to begin with. Bugs like this are thus root -> ring0 vulnerabilities. That's not nothing, but for serverside work it's usually worth the tradeoff, especially because eBPF's track record for kernel LPEs is actually pretty strong compared to the kernel as a whole.<p>In the setting eBPF is used today, most of the value of the verifier is that it's hard to <i>accidentally</i> crash your kernel with a bad eBPF program. That is comically untrue about an ordinary LKM.
The one time I tried to use eBPF it wasn't expressive enough for what I needed.<p>Does the limited flexibility it provides really justify the added kernel space complexity? I can understand it for packet filtering but some of the other stuff it's used for like sandboxing just isn't convincing.
> “Uno no es ninguno” (One is none)<p>I believe that translates to "One is not none"<p><a href="https://bughunters.google.com/blog/6303226026131456/a-deep-dive-into-cve-2023-2163-how-we-found-and-fixed-an-ebpf-linux-kernel-vulnerability#-uno-no-es-ninguno-one-is-none-" rel="nofollow">https://bughunters.google.com/blog/6303226026131456/a-deep-d...</a>
In my country we have a saying. "Porcupine in the pants". Sounds like for all the good it can do, it isn't written safely and carefully.