On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy <bbosca...@linux.microsoft.com> wrote: > > KP Singh <kpsi...@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...@mail.gmail.com/ 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....@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...@mail.gmail.com/ 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 > > > > >
