commit eb80a2d94081929e7d91f275cdeda214433dead7
Author: Daniel Borkmann [off-list ref]
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 [off-list ref]

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)
    [off-list ref]

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

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