[PATCH bpf-next 00/13] Signed BPF + IPE Policies

[Paul Moore]

On Fri, May 22, 2026 at 4:46 PM KP Singh <kpsingh at kernel.org> wrote:
> On Fri, May 22, 2026 at 8:56 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Thu, May 21, 2026 at 10:32 PM KP Singh <kpsingh at kernel.org> wrote:
> > >
> > > This series continues the "Signed BPF programs" work and adds
> > > the missing pieces needed for an LSM to do policy enforcement
> > > and addresses the concerns raised by the developers of Hornet.
> > >
> > > One signing scheme, please.
> >
> > This is why we tried working with you and Alexei for quite some time,
> > providing requirements, patches, reviews, and code suggestions.
> > Unfortunately, our input was not reflected in the signing scheme that
> > was merged into Linus' tree, so we have had to get creative to meet
> > our our needs and those of others.
>
> Is your idea of creativity to circumvent working with the BPF
> maintainers and community?

My previous comment should answer that.

> > Once again, if one signs BPF programs using the Hornet signing tools
> > provided in Blaise's patches, the resulting signed BPF can be loaded
> > and verified using both the existing BPF signature verification code
> > and Hornet.  It is also easy to disable Hornet and/or IPE at kernel
> > boot using the "lsm=" command line parameter, and of course one can
> > always tailor the IPE policy to meet specific needs.  Although you
> > surely must be aware of that as your own patchset borrows heavily from
> > Blaise's original code, albeit without any attribution.
> >
> > > Hornet has been NACK'd repeatedly by the BPF maintainers [1][2]
> > > on layering and TOCTOU grounds.
> >
> > Blaise has recorded Alexei's NACK on the Hornet patchset and addressed
>
> Please record the NACK from Daniel and me.

Send me the commit IDs of the patch(es) you wish to NACK and I'll add
it.  Daniel will need to do the same; I generally don't accept
metadata tags from third parties, whether positive or negative.

> > > - security_bpf_prog_load_post_integrity LSM hook, fired by the
> > >   kfunc on a successful metadata check.
> >
> > Does a kfunc calling a LSM hook open the door to a potential recursion
> > issue involving a BPF LSM?
>
> What's the concern here? LSM hooks can fire from BPF kfuncs and
> helpers for a while now.

I was under the impression that BPF wanted to prevent things like
infinite recursion, from a safety/security perspective, perhaps not.

> > > - IPE properties (bpf_signature, bpf_keyring, bpf_kernel) and
> > >   two ops (BPF_PROG_LOAD, BPF_PROG_LOAD_POST_INTEGRITY).
> > >
> > > This series address concerns raised by the Hornet developers:
> > >
> > > * The metadata hash check should be in kernel C, not BPF
> > >   bytecode -- Blaise Boscaccy [3]:
> > >
> > >   The bpf_loader_verify_metadata kfunc moves the hash check from
> > >   inline BPF instructions into kernel C code.
> >
> > Please see my comments above.  While the kfunc is written in C, it is
> > still reliant on the loader calling that kfunc.
>
> Yes, that's the idea of transitive trust here. Ultimately you signed
> the loader with your key. The mechanism proposed here allows
> verification of any dynamic metadata, it does not need to be hermetic
> to the loader, provided the digest of the metadata is incorporated
> into the loader's signed payload.

We've talked about this many, many times already and the differences
in our security requirements are well established.  You've satisfied
your security goals with the signing scheme Alexei merged, we are
working to satisfy our security requirements with Hornet.  While
Hornet requires compliance with your signing scheme, there is no
requirement for you to use Hornet to utilize your signing scheme.

-- 
paul-moore.com