On Tue, Jun 10, 2025 at 11:24 PM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2025-06-10 at 21:47 +0200, KP Singh wrote: > > It's been repeatedly mentioned that trusted loaders (whether kernel > > or BPF programs) are the only way because a large number of BPF > > use-cases dynamically generate BPF programs. > > You keep asserting this, but it isn't supported by patches already This is supported for sure. But it's not what the patches are providing a reference implementation for. The patches provide a stand alone reference implementation using in-kernel / BPF loaders but you can surely implement this (see below): > proposed. Specifically, there already exists a patch set: > > https://lore.kernel.org/all/20250528215037.2081066-1-bboscaccy@xxxxxxxxxxxxxxxxxxx/ The patch-set takes a very narrow view by adding additional UAPI and ties us into an implementation. Whereas the current approach keeps the UAPI clean while still meeting all the use-cases and keeps the implementation flexible should it need to change. (no tie into the hash chain approach, if we are able to move to stable BPF instruction buffers in the future). Blaise's patches also do not handle the trusted user-space loader space and the "signature_maps" are not relevant to dynamic generation or simple BPF programs like networking, see below. > > that supports both signed trusted loaders and exact hash chain > verification of loaders plus program maps. The core kernel code that I have mentioned in various replies as to how the current design ends up working for dynamic loaders. Here's it once again: * The dynamic userspace loader is trusted, it's either compiled in with libbpf statically or libbpf is also a trusted library. * The BPF program is generated and all the relcoations are performed at runtime, after which the BPF instruction buffer becomes stable and can be signed which obviates the need for the loader program for programs that have runtime relocations. And ofcourse, some BPF programs don't have runtime relocations at all (e.g some networking programs). * The program is then signed with a derived credential at runtime and this signature is passed in attr.signature and this signature is verified by the kernel. > does it is only about 10 lines and looks to me like it could easily be > added to your current patch set. This means BPF signing could support I still don't understand the actual reasons for you needing this to happen in the kernel. Here's a summary of the reasons that have been thrown around: Supply chain attacks ================ I got vague answers about supply chain attacks. If one cannot trust the build environment that builds the BPF programs, has signing keys, generates and signs the loader, or that builds libbpf / kernel, then I think one has other issues. PS: You can also contribute code into LLVM / clang to generate loader programs directly from a BPF object. The loader code is hard to understand ============================= So is the BPF JIT that lives in the kernel, I am sure there are engineers who understand BPF assembly and JITs? Please remember the user who uses BPF is different from the user who implements singing for the BPF users, the latter (e.g. a distro, hyperscalar etc) needs to be advanced and aware of BPF internals. "having visibility" in the LSM code ========================== To implement what specific security policy? There are security policies and controls that need to be defined that are required by BPF use-cases and one would expect the LSM experts to help here, none of them require in kernel verification, here they are: * LSM controls to reject programs that are not signed * LSM controls that establish trust on userspace binaries and libraries. * LSM policies that allow these components to either load programs signed at runtime using a derived credential. * LSM policies that allow certain signed BPF programs to be loaded without requiring elevated privileges i.e CAP_BPF. Auditing ====== You can surely propose a follow up to my patches that adds audit logging to the loader, that calls the audit code from using a BPF kfunc, so this can be extended for auditing. At this point, I am happy to discuss the actual security policy work that is needed. For the discussion around the UAPI and in-kernel verification, I rest it in the hands of the BPF maintainers. - KP > signer being in the position of deciding what they want and no loss of > generality for either use case. > > So whatever we build needs to work for everyone and not just your > > specific use-case or your affinity to an implementation. > > The linked patch supports both your trusted loader use case and the > exact hash chain verification one the security people want. Your > current patch only seems to support your use case, which seems a little > bit counter to the quote above. However, it also seems that > reconciling both patch sets to give everyone what they want is easily > within reach so I think that's what we should all work towards. > > Regards, > > James >
