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. 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
