[aliceryhl]

I asked about this when they presented the project at the Linux Plumbers conference. They replied that it's not really intended to be a security boundary, and that you should not let anyone malicious load these programs.

Given this thread model, I think their project is entirely reasonable. Safe Rust will prevent accidental mistakes even if you could technically circumvent it if you really try.

[tptacek]

eBPF's limitations are as much about reliability as security. The bounded loop restriction, for instance, prevents eBPF programs from locking up your machine.

[loeg]

You could still imagine terminating these programs after some bounded time or cycle count. It isn't as good as static verification, but it's certainly more flexible.

[IshKebab]

As I understand it eBPF has also given up on that due to Spectre. As a result you need root to use it on most distros anyway, and the kernel devs aren't going to expand its use (some systems are stuck on cBPF).

So it's not like eBPF is secure and this isn't. They're both insecure in different ways.

[westurner]

So eBPF for a WAF isn't worth it?

re: eBPF and WAFs: https://news.ycombinator.com/item?id=45951011

From https://news.ycombinator.com/context?id=43564972 :

> Should a microkernel implement eBPF and WASM, or, for the same reasons that justify a microkernel should eBPF and most other things be confined or relegated or segregated in userspace; in terms of microkernel goals like separation of concerns and least privilege and then performance?

"Isolated Execution Environment for eBPF" (2025-04) https://news.ycombinator.com/item?id=43697214

"ePass: Verifier-Cooperative Runtime Enforcement for eBPF" (2025-12) https://ebpf.foundation/epass-verifier-cooperative-runtime-e... .. https://news.ycombinator.com/item?id=46412121