OSS + ELC EU 2026

eBPF has become the backbone of modern Linux security tooling. Cilium, Tetragon, Falco, etc they all depend on eBPF's ability to hook kernel execution paths and enforce policy without a kernel patch or reboot. But there's a question the community has been slow to ask: who secures eBPF itself?
Working on bpfman, an eBPF program manager, exposed me to the trust assumptions baked into how programs get loaded, pinned, and granted kernel access. This talk covers what I found concrete attack surfaces that show up in real deployments, not theory.

We'll cover: the verifier's historical CVEs and what they reveal about its actual threat model, privilege escalation through CAP_BPF and unprivileged eBPF in distros that ship with it enabled, what program signing protects and what it quietly doesn't, and LSM hooks on BPF program loading that most teams aren't using yet.
The second half: BPF token scoping, how Ubuntu and Fedora are locking down the attack surface without breaking legitimate tooling,and a threat model checklist you can apply to your own eBPF deployment the same week.
If you're running eBPF-based security tooling in production, this is the talk I wished existed before I started.