Taming the BPF superpowers

Work toward the signing of BPF programs has been finding its way into recent mainline kernel releases; it is intended to improve security by limiting the BPF programs that can be successfully loaded into the kernel. As John Fastabend described in his "Watching the super powers" session at the 2021 Linux Plumbers Conference, this new feature has the potential to completely break his tools. But rather than just complain, he decided to investigate solutions; the result is an outline for an auditing mechanism that brings greater flexibility to the problem of controlling which programs can be run.
在最近的主线内核版本中，BPF 程序签名机制的开发工作已经陆续出现；其目的是通过限制能够成功加载到内核中的 BPF 程序来提升安全性。正如 John Fastabend 在 2021 年 Linux Plumbers Conference 上的 “Watching the super powers” 主题演讲中所说，这一新特性可能会彻底破坏他所使用的工具。但他并没有止于抱怨，而是决定探索解决方案；结果就是提出了一个审计机制的设想，为控制哪些程序可以运行的问题带来更大的灵活性。

The kernel has had the ability to enforce signatures on loadable modules for years, so it makes sense to consider creating the same mechanism for BPF programs. But, while kernel modules and BPF programs look similar — both are code loaded into the kernel from user space, after all — there are some significant differences between them. The safety of kernel modules is entirely dependent on the diligence of developers. They are built and distributed via the usual channels, are tied to specific kernel versions, and can last for years; they present a stable API to user space. BPF programs, instead, benefit from safety built into (and enforced by) the loader. They are often dynamically built and optimized, they are patched at run time to avoid being tied to kernel versions, and they have a different lifetime; often, they are created on the fly and quickly thrown away. Th