On Wed, Aug 13, 2025 at 5:37 PM KP Singh <kpsingh@xxxxxxxxxx> wrote: > On Wed, Aug 13, 2025 at 11:02 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > It's nice to see a v3 revision, but it would be good to see some > > comments on Blaise's reply to your v2 revision. From what I can see > > it should enable the different use cases and requirements that have > > been posted. > > I will defer to Alexei and others here (mostly due to time crunch). It > would however be useful to explain the use-cases in which signed maps > are useful (beyond being a different approach than the current > delegated verification). The use cases and requirements have been described quite a bit in previous threads already, with both you and Alexei participating in those discussions. If you really can't find the threads on lore let me know and I'll be happy to send you links to all of the various threads from the past several months. However, if I had to point to a single email that I felt best summarized my requirements, I think it might be this: <<< QUOTE >>> The loader (+ implicit loader verification of maps w/original program) signature verification scheme has been requested by Alexei/KP, and that's fine, the code is trivial and if the user/admin is satisfied with that as a solution, great. However, the loader + map signature verification scheme has some advantages and helps satisfy some requirements that are not satisfied by only verifying the loader and relying on the loader to verify the original program stored in the maps. One obvious advantage is that the lskel loader is much simpler in this case as it doesn't need to worry about verification of the program maps as that has already been done in bpf_check_signature(). I'm sure there are probably some other obvious reasons, but beyond the one mentioned above, the other advantages that I'm interested in are a little less obvious, or at least I haven't seen them brought up yet. As I mentioned in an earlier thread, it's important to have the LSM hook that handles authorization of a BPF program load *after* the BPF program's signature has been verified. This is not simply because the LSM implementation might want to enforce and access control on a BPF program load due to the signature state (signature verified vs no signature), but also because the LSM might want to measure system state and/or provide a record of the operation. If we only verify the lskel loader, at the point in time that the security_bpf_prog_load() hook is called, we haven't properly verified both the loader and the original BPF program stored in the map, that doesn't happen until much later when the lskel loader executes. Yes, I understand that may sound very pedantic and fussy, but there are users who care very much about those details, and if they see an event in the logs that indicates that the BPF program signature has been verified as "good", they need that log event to be fully, 100% true, and not have an asterix of "only the lskel loader has been verified, the original BPF program will potentially be verified later without any additional events being logged to indicate the verification". <<< /QUOTE >>> The above was taken from this on-list email: https://lore.kernel.org/linux-security-module/CAHC9VhQT=ymqssa9ymXtvssHTdVH_64T8Mpb0Mh8oxRD0Guo_Q@xxxxxxxxxxxxxx/ Of course I imagine Blaise might have a few things to add here, but I'll let him comment on that if he has anything additional to add. -- paul-moore.com
