[PATCH bpf-next v4 4/9] libbpf: Drop in-loader metadata check for load-time verification

[bot+bpf-ci at kernel.org]

> commit eb80a2d94081929e7d91f275cdeda214433dead7
> Author: Daniel Borkmann <daniel at iogearbox.net>
> Date:   Mon Jul 6 15:56:39 2026 +0200
>
>     libbpf: Drop in-loader metadata check for load-time verification
>
>     The signed gen_loader used to police its own metadata map from within
>     BPF: emit_signature_match() read the kernel-cached map->sha[] back
>     through hardcoded struct bpf_map offsets and compared it against a hash
>     that compute_sha_update_offsets() baked into the signed instructions,
>     after a BPF_OBJ_GET_INFO_BY_FD round-trip to populate map->sha[].
>
>     The kernel now verifies the metadata at BPF_PROG_LOAD time by folding
>     the frozen contents of the loader's exclusive fd_array maps into the
>     signature, so the loader no longer checks anything itself. Generated
>     loaders thus carry no verification logic of their own anymore: Nothing
>     in the signing chain depends on emitted loader bytecode doing the right
>     thing.
>
>     On the loading side, skel_internal.h now sets fd_array_cnt for a signed
>     load so the kernel scans fd_array for the exclusive metadata map -
>     still frozen, as the kernel requires - and the BPF_OBJ_GET_INFO_BY_FD
>     round-trip to populate map->sha[] is gone. The struct bpf_map layout
>     BUILD_BUG_ON()s on the kernel side are removed as well: they only
>     pinned the ABI for the in-BPF read of map->sha[] that is no longer
>     needed. Same for the map->excl member. Note: gen_hash is retained; it
>     still marks a loader as signed so an untrusted host cannot re-dimension
>     maps or override initial values now covered by the signature.
>
>     Signed-off-by: Daniel Borkmann <daniel at iogearbox.net>

In reviewing the patch series discussion on lore, Paul Moore raised a
security concern in v3 about the companion patch that moves the
security_bpf_prog_load() LSM hook into bpf_check() in verifier.c. He
noted that the moved hook placement allows processes to allocate kernel
memory (including bpf_verifier_env via kvzalloc_obj) before SELinux can
deny the BPF program load operation, creating a potential local DoS
attack vector where even denied operations trigger sizable allocations.

Paul explicitly Nacked the change with:

    Nacked-by: Paul Moore (don't move bpf_prog_load LSM hook)
    <paul at paul-moore.com>

Reference:
https://lore.kernel.org/bpf/CAHC9VhQD4RHsGiTMVCCTN+eB71-Ueopke8XghExpNJ2PSNa_jQ@mail.gmail.com/

Paul did not comment on v4, leaving it unclear whether his concern was
addressed or if he accepted the change. Has this security regression
concern been resolved, or does the hook movement remain in the series?


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