[andrewflnr]

I haven't been following the eBPF situation for a while, but... how did it come to this? I thought the point of BPF (sans 'e' anyway) was that it was pretty much secure by construction, or at minimum was simple enough to fully verify in polynomial time. So these eBPF vulnerabilities sound like a completely invented, unnecessary class of problems.

[tptacek]

The track record of eBPF to date has been reasonably strong, and the threat model serious systems give to eBPF is narrow: you care a lot about the formal soundness of the verifier if you're loading untrusted code, and much less if you're never doing that. eBPF has been a pretty important victory for the Linux systems design model.

The real goal of eBPF verification is to avoid kernel crashes, and for that goal, eBPF has been unreasonably successful.

[skywhopper]

Because devs latched into their interpretation of eBPF’s promises and found ways to make them happen via the way any problem in computer science gets solved: indirection. This is human nature (just look at the stack of BIOS/EFI/OS execution rings that pre-empt each other to provide more features at lower hardware levels). Responsible operators should avoid these hacks where possible.