On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy bboscaccy@linux.microsoft.com wrote:
KP Singh kpsingh@kernel.org writes:
[...]
Now if you really care about the use-case and want to work with the maintainers and implement signing for the community, here's how we think it should be done:
- The core signing logic and the tooling stays in BPF, something that the users are already using. No new tooling.
- The policy decision on the effect of signing can be built into various existing LSMs. I don't think we need a new LSM for it.
- A simple UAPI (emphasis on UAPI!) change to union bpf_attr in uapi/bpf.h in the BPF_PROG_LOAD command:
__aligned_u64 signature; __u32 signature_size;
I think having some actual details on the various parties' requirements here would be helpful. KP, I do look forward to seeing your design; however, having code signing proposals where the capabilities are dictated from above and any dissent is dismissed as "you're doing it wrong" isn't going to be helpful to anyone that needs to use this in practice.
Please don't misrepresent the facts, you got feedback from Alexei in various threads, but you chose to argue on the points that were convenient for you (i.e. usage of BPF internal APIs) and yet you claim to "work with the BPF community and maintainers" by arguing instead of collaborating and paying attention to the feedback given to you.
1. https://lore.kernel.org/bpf/CAADnVQKF+B_YYwOCFsPBbrTBGKe4b22WVJFb8C0PHGmRAjb...
Your solution to address the ELF loader specific issue was to just allow list systemd? You totally ignored the part about loaders in golang and Rust that do not use ELF. How is this "directive from above?"
2. Alexei suggested to you in https://lore.kernel.org/bpf/87plhhjwqy.fsf@microsoft.com/
"A signature for the map plus a signature for the prog that is tied to a map might be a better option. At map creation time the contents can be checked, the map is frozen, and then the verifier can proceed with prog's signature checking."
You never replied to this.
3. To signing the attachment points, you replied
That statement is quite questionable. Yes, IIRC you brought that up. And again, runtime policy enforcement has nothing to do with proving code provenance. They are completely independent concerns.
The place where the BPF program is attached is a key part of the provenance of the BPF program and its security (and other) effects can vary greatly based on that. (e.g. imagine a reject all LSM program that is attached to the wrong LSM hook). This is why it's not the same as module loading.
4. https://lore.kernel.org/bpf/CAADnVQKF+B_YYwOCFsPBbrTBGKe4b22WVJFb8C0PHGmRAjb...
Programs can still access maps, now if you combine the issue of ELF-less loaders and that maps are writeable from other programs as freezing only affects userspace (i.e. when a binary gets an FD to a map and tries to modify it with syscalls) your implementation fails.
The reply there about trusted user-space still needs to come with better guarantees from the kernel, and the kernel can indeed give better guarantees, which we will share. The reason for this is that your trusted binary is not immune to attacks, and once an attacker gains code execution as this trusted binary, there is no containing the compromise.
- KP
Also, I don't think anyone actually cares, at least I don't, who calls verify_pkcs7_signature or whatnot. Verifying signed binary blobs with a private key is a solved problem and isn't really interesting.
Our requirements for code signing are just an extension of secure boot and module signing logic:
- Prove all code running in ring zero has been signed
- Not trivially defeatable by root
- Ultimately, no trusted userspace components
- Secure from and not vulnerable to TOCTOU attacks
- Shouldn't be overly vulnerable to supply-chain attacks
- The signature checking logic and control paths should be human-readable
- Work easily and be backportable to stable kernels
- There should be a simple kconfig option to turn this on or off
- This solution needs to be in the mainline kernel
Hornet was implemented to meet those requirements, living in the LSM subsystem, written in C. As of today, one cannot accomplish those requirements via BPF-LSM, which is why C was chosen.
One can easily realize there is absolutely no way to have a single one-size-fits-all signing solution for everything listed in https://ebpf.io/applications/.
If you want to go the UAPI route, I would wholeheartedly recommend making it extensible and having this data be available to the policy LSMs.
enum bpf_signature_type { /* x509 signature check against program instructions only */ BPF_SIGNATURE_PROG_ONLY = 0, /* x509 combined signature check against program instructions and used maps */ BPF_SIGNATURE_PROG_USED_MAPS = 1, /* more of these to be determined via usage */ ... };
_aligned_u64 signature; __u32 signature_size; __u32 signature_type;
The other option for solving this in the general is in-kernel loaders. That's gotten pushback as well.
-blaise