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

[Paul Moore]

On Wed, Aug 13, 2025 at 6:17 PM Paul Moore <paul at paul-moore.com> wrote:
> 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).

I wanted to bring this up again as it has been another week with no
comment from the BPF side of the house regarding Blaise's additions.
As a reminder, Blaise's patch can be found here:

https://lore.kernel.org/linux-security-module/87sei58vy3.fsf@microsoft.com

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

-- 
paul-moore.com