BPF Access Control and CO-RE in Android
summary
Claim: enabling CO-RE via libbpf on Android lets BPF programs compiled once run across kernel versions but currently vendors only have socket-filter access and want kprobes and tracepoints, which would extend the kernel ABI. Built so far: a single-threaded BPF loader in early init backed by custom headers; proposed change is native libbpf with per-app static linking, attach-point allowlist, and an access-control BPF hook that validates load/attach at syscall level. Unresolved: boot-time and memory impact, how to update the allowlist from userspace, and who owns compatibility when kernels or userlands change.
AI-written summary · about
chapters (11)
- 0:00Introduction to BPF in Android
- 1:31What is BPF and its components
- 3:38Android’s current BPF implementation
- 5:05Enabling CO-RE in Android
- 7:13Native libbpf solution proposal
- 8:15Vendor access and security concerns
- 10:03Comparison with SELinux approach
- 11:07BPF gatekeeper and policy enforcement
- 12:10User space vs kernel enforcement
- 13:18Kernel and user space compatibility
- 14:47Future plans and open questions
related talks
21mPortable BPF with CO:RE
32mMore CO-RE? Taming the effects of compiler optimizations on BPF tracing
34mWhat's new in the BPF world?
32meBPF: The Next Power Tool of SREs
28mBeyond Power and Magic: Forging Stable eBPF Tools for the Post-Demon King Era
53mGetting Started with BPF Security Observability
42mKernel Analysis Using eBPF
33meBPF: exploring use case of BPF kernel infrastructure