Discussion: What's next for BPF Signing
summary
Initial code lands upstream adding a detached signature field in the BPF attr and kernel keyring verification so stable-instruction programs verify at load time; programs with relocations use a loader program (trace of syscalls + metadata map) plus exclusive maps to bind map contents to that loader. Deployment options include enforcing via a BPF LSM hook or tying trust to a DM-verity digest/FS-verity/IMA workflow and supporting delegated certificates or CA-signed keys for dynamic generators like Cilium.
AI-written summary · about
chapters (16)
- 0:00Introduction to BPF Signing
- 1:24Signing stable BPF programs
- 2:06Challenges with signed loaders
- 3:53Light skeletons and limitations
- 5:38Policy enforcement on real systems
- 7:03DM verity and trusted partitions
- 9:33Package managers and extended attributes
- 11:43Delegated signing certificates
- 13:30Cloud-native signing workflow
- 15:00Principle of least privilege
- 16:27Unprivileged BPF and capabilities
- 17:53BPF tokens and namespaces
- 20:08Token delegation and security
- 22:34Integrity Policy Enforcement LSM
- 23:57Secure boot and TPM integration
- 25:21Conclusion and Q&A
related talks
24mBPF Signing and IMA integration
22mBPF_LSM + fsverity for Binary Authorization
27mBPF LSM - Updates and What next?
36mThe journey of BPF from restricted C language towards extended and safe C.
29meBPF on the Rise - Getting Started
28mBeyond Power and Magic: Forging Stable eBPF Tools for the Post-Demon King Era
24mVerifying and Signing EBPF Programs with Inspektor Gadget
36mSecuring the Superpowers: Who Loaded That EBPF Program?