On Sat, Jan 25, 2025 at 09:33:38AM -0800, Alexei Starovoitov wrote: > On Fri, Jan 24, 2025 at 7:06 PM Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote: > > > > The naive approach to signing eBPF programs faces a critical > > limitation: programs undergo mandatory modifications by libbpf before > > kernel loading, which invalidates conventional signatures. We present > > Two-Phase Signing, a solution that implements sequential verification > > aligned with the eBPF program lifecycle. > > > > Our approach establishes a baseline signature during initial > > compilation, followed by a secondary signature that encompasses both > > the modified program and initial signature. This creates a verifiable > > chain of trust while accommodating essential libbpf modifications such > > as relocations and map file descriptor updates. This approach enables > > precise failure diagnosis by distinguishing between compromised > > original programs and unauthorized post-compilation modifications. > > > > The Two-Phase Signing method balances security with practicality, > > allowing necessary binary modifications while maintaining integrity > > verification throughout the program's lifecycle. This approach > > provides granular audit capabilities and clear identification of > > potential security breaches in the signing chain. > > > > We invite discussion on the implications, trade-offs, and potential > > improvements of this approach for securing eBPF programs in production > > environments, particularly focusing on practical impact and > > integration challenges with existing eBPF frameworks. > > This is certainly an important topic, but there is already a solution: > light skeleton. > > Pls join the discussion: > https://lore.kernel.org/bpf/bqxgv2tqk3hp3q3lcdqsw27btmlwqfkhyg6kohsw7lwdgbeol7@nkbxnrhpn7qr/ > > No need to delay it to lsfmm. I appreciate you highlighting the significance of this matter. I didn't notice the above work until seeing your email. From my quick glance, it looks like another attempt to bring eBPF program loader into the kernel. In my own opinion, the biggest advantage of my proposal is that it requires *no* kernel changes at all, which in turn means: 1) We still maintain the clear separation between userspace and kernel space, as it is now. 2) More flexible: It is always easier to update libbpf without kernel updates 3) Smaller kernel attack surface since complex relocation logic stays in userspace 4) Better compatibility with existing toolchains and build systems 5) Easier debugging of loading issues since more visibility in userspace You can find more details in my github repo below. > > If you believe that your double-sign algorithm is superior, > please explain it in that email thread. I have put everything together in my github repo here: https://github.com/congwang/ebpf-2-phase-signing including the design, the advantages, a proof-of-concept which already works. Please take a look and let me know what you think. Thanks a lot!
