[PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time

bot+bpf-ci at kernel.org bot+bpf-ci at kernel.org
Wed Jun 24 15:17:31 UTC 2026


>     A signed gen_loader program carries the programs, maps and relocations it
>     installs in a metadata array map. The loader instructions are covered by
>     the PKCS#7 signature, but the metadata map is not: Today the loader
>     compares the map contents from within BPF against a hash baked into its
>     (signed) instructions, using the kernel-cached map hash. The kernel itself
>     never actually attests that the metadata the loader installs is the
>     metadata that was signed.
>
>     This split is the core of the long-standing objection to the BPF signing
>     scheme from the LSM / integrity side: the integrity check of a light
>     skeleton only completes once the loader program runs, that is, after the
>     security_bpf_prog_load() hook, so at admission time an LSM observes a
>     program whose payload has not yet been verified [0]. Auditing the chain
>     link is also not a purely cryptographic operation: whoever signs or reviews
>     an lskel has to disassemble the loader's preamble to convince themselves
>     that the embedded hash check is present and correct [1][2]. Two acceptable
>     fixes were identified in those threads: Complete the integrity check
>     before the admission hook fires, or add a second hook that collects the
>     verification result after the loader ran [3]. Let's implement the former,
>     without growing the UAPI.
>
>     A signed loader binds its metadata map(s) through the existing fd_array,
>     and an exclusive map is already bound to a program digest (excl_prog_hash).
>     So when a signature is present, collect the exclusive maps from fd_array
>     and append their frozen contents to the instructions before verification:
>     the signature now covers insns || metadata_0 || metadata_1 || [...] in the
>     fd_array order, and verification completes in bpf_check(), once the
>     fd_array maps are resolved into used_maps, before the LSM admission hook
>     and the rest of verification.
>
>     A program is either BPF_SIG_UNSIGNED or BPF_SIG_VERIFIED, with nothing in
>     between. While folding the fd_array maps, a non-exclusive map bound to
>     a signed program is rejected, so every map folded into the signature is
>     exclusive. A signed loader that fails to cover its metadata thus does not
>     load, and BPF_SIG_VERIFIED always means the instructions and every
>     exclusive map are authentic.
>
>     The maps must be frozen so the hashed bytes cannot change before the
>     loader runs; the map <-> program digest binding is enforced by the
>     verifier for every used map. Binding maps through fd_array_cnt makes the
>     verifier resolve and excl-check them (excl_prog_sha vs prog->digest)
>     before it would otherwise compute the digest, so compute prog->digest
>     up front in bpf_check(), over the unmodified instructions the
>     signature covers, for a load that folds metadata.
>
>     Unsigned programs are not affected. Note, signed loaders generated by
>     older libbpf/bpftool versions need to be regenerated; some of the recent
>     fixes we've had on the signed loader side require the latter already to
>     close gaps.
>
>     Signed-off-by: Daniel Borkmann <daniel at iogearbox.net>

This reworks the machinery added by 63a673e8a411 ("bpf: Expose signature
verdict via bpf_prog_aux"), which introduced the prog->aux->sig verdict and
ran verification before security_bpf_prog_load() so the hook would observe
only either UNSIGNED or VERIFIED.

Since this moves the verdict assignment and signature verification into
bpf_check() and folds the exclusive metadata maps into the signed payload
ahead of the admission hook, should it carry:

  Fixes: 63a673e8a411 ("bpf: Expose signature verdict via bpf_prog_aux")


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28106955037


More information about the Linux-security-module-archive mailing list