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

[Daniel Borkmann]

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.

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.
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; and 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.

Anyway, I hope we can find a compromise here.. will keep you posted on v2
of the series.

Thanks,
Daniel