[PATCH bpf-next 0/5] Verify BPF signed loader at load time

[Paul Moore]

On Fri, Jun 12, 2026 at 5:33 AM Daniel Borkmann <daniel at iogearbox.net> wrote:
> On 6/12/26 12:56 AM, Paul Moore wrote:
> > On Wed, Jun 10, 2026 at 7:03 PM Daniel Borkmann <daniel at iogearbox.net> wrote:
> >>
> >> The BPF signing scheme signs a light skeleton's loader program and lets
> >> the loader vouch for everything else: bpftool bakes the SHA256 of the
> >> metadata map into the loader's instructions, signs the instructions, and
> >> the loader compares the (frozen, exclusive) map against that hash from
> >> within BPF once it runs. The construction is sound as a trusted hash
> >> chain, but the kernel itself never attests the metadata, and that split
> >> has been the recurring objection from the LSM / integrity side since the
> >> scheme was proposed.
> >>
> >> This proposal closes both gaps by having the kernel verify the metadata
> >> at BPF_PROG_LOAD time, before the LSM admission hook and before the
> >> verifier, /without/ growing the UAPI. A signed loader binds its metadata
> >> map(s) through the existing fd_array/fd_array_cnt, and exclusive maps
> >> are already bound to the loader's digest via excl_prog_hash. When a
> >> signature is present, the kernel collects the exclusive maps from the
> >> fd_array and appends their frozen contents to the instructions before
> >> PKCS#7 verification, so the signature covers ...
> >>
> >>      insns || metadata_0 || metadata_1 || [...]
> >>
> >> ... in fd_array order. The in-loader hash check is dropped from the
> >> gen_loader entirely: generated loaders carry no verification logic
> >> anymore, and signing or verifying a skeleton becomes an ordinary CMS
> >> operation over bytes that sit verbatim in the skeleton, reproducible
> >> offline. A signed program is either BPF_SIG_UNSIGNED or BPF_SIG_VERIFIED
> >> with nothing in between.
> >
> > I'll be honest and say I'm a bit surprised to see this patchset,
> > especially since KP and Alexei argued so strongly against this
> > signature scheme, preferring KP's scheme where the loader verified the
> > maps.  I'd be curious to hear the reason for the change of heart if
> > you can share it.  Regardless of the motivation for this change, I
> > obviously think this is a significant improvement over KP's signature
> > scheme which shipped in Linux v6.18.
> >
> > I also think it is worth mentioning the similarities to work Blaise
> > did before the most recent Hornet version:
> >
> > https://lore.kernel.org/linux-security-module/20250929213520.1821223-1-bboscaccy@linux.microsoft.com/
> >
> > While Blaise's patchset added to the UAPI, that was done simply to
> > retain compatibility with KP's signature scheme; your patchset does
> > without any UAPI additions, but loses compatibility with existing
> > signed lskels.  Beyond that, the basic signature scheme between
> > Blaise's patchset and what you are proposing appears the same ...
> > which is a good thing as far as I'm concerned.
>
> For the rework, I've mainly been looking at KP's most recent series as
> well as some of the past discussions. Mainly trying to see if we can get
> away with a simpler model and without having to pull in BTF support for
> the signed loader just for the extra kfunc. Over the last couple of weeks,
> I've also build user space tooling on my side to experiment with some
> real world application which the signed loader would have to deal with.

Out of curiosity, have you discussed these changes with Alexei and/or
KP?  You surely know the history here, and as I mentioned above,
you're basically proposing the same signature scheme that Blaise
proposed last September and we all know how Alexei and KP reacted.  I
believe that Blaise's signature scheme, which you've adopted, is the
better option so I'm happy to see you move forward with this patchset.
However, I don't want to see you spend a lot of time on this if Alexei
and KP are going to react with the same attacks as last September.

> For sending a v2, I'll have to move this slightly deeper into verifier
> side but before the main verifier work happens in order to solve the
> exclusive map race issue, and additionally we could also utilize the
> verifier log to tell the user that the signature validation failed.
>
> I think a couple of things would still stand out imo: i) we sign over the
> raw bytes, not the derived hash anymore, so the hashing is only used in the
> context to tie the map to the loader prog, but not anymore for the signature.

The important part is that the PKCS7 signature covers both the loader
and the maps and it is verified in the native kernel code without
relying on any actions in the loader.

> ii) its one single scheme and not a parallel branch, so the main loader is
> built upon the updated signing scheme rather than having this as an option
> on the side; iow this replaces the in-loader check and there's a single PKCS#7-
> over-bytes path, not an 'if (signature_maps_size)' fork

I think if you look back at Blaise's early efforts you will see that
we've always favored a single signature scheme.  Blaise's various
patchsets only shifted to parallel/compatible mechanisms when it
became clear that Alexei had no interest in anything other than KP's
signature scheme.  We didn't want to remove KP's signature scheme
because we believed that would be a non-starter for any patchset; this
is one of the reasons why I'm so surprised to see KP's signature
scheme completely removed in your patchset.

I'm happy to see someone in BPF land come around to supporting
Blaise's signature scheme, I only wish it happened a little sooner, we
likely could have saved everyone a lot of time and stress.

> iii) given we
> expose the verification result in the BPF prog, we also don't need a new LSM
> hook and can just piggy back on the existing security_bpf_prog() which also
> has the possibility to still reject late at this point.

If you look at Blaise's patchset from last September (the one I linked
in my previous email) you will notice he didn't add any additional
hooks either.

-- 
paul-moore.com