[PATCH v3 08/12] bpf: Implement signature verification for BPF programs

[Paul Moore]

On Wed, Aug 13, 2025 at 5:37 PM KP Singh <kpsingh at kernel.org> wrote:
> On Wed, Aug 13, 2025 at 11:02 PM Paul Moore <paul at paul-moore.com> 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@mail.gmail.com/

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