[PATCH bpf-next v2 0/3] BPF signature hash chains

[Paul Moore]

On Mon, Sep 29, 2025 at 5:35 PM Blaise Boscaccy
<bboscaccy at linux.microsoft.com> wrote:
>
> This patchset extends the currently proposed signature verification
> patchset
> https://lore.kernel.org/linux-security-module/20250813205526.2992911-1-kpsingh@kernel.org/
> with hash-chain functionality to verify the contents of arbitrary
> maps.
>
> The currently proposed loader + map signature verification
> scheme—requested by Alexei and KP—is simple to implement and
> acceptable if users/admins are satisfied with it. However, verifying
> both the loader and the maps offers additional benefits beyond just
> verifying the loader:
>
> 1. Simplified Loader Logic: The lskel loader becomes simpler since it
>    doesn’t need to verify program maps—this is already handled by
>    bpf_check_signature().
>
> 2. Security and Audit Integrity: A key advantage is that the LSM
>   (Linux Security Module) hook for authorizing BPF program loads can
>   operate after signature verification. This ensures:
>
>   * Access control decisions can be based on verified signature
>   * status.  Accurate system state measurement and logging.  Log
>   * events claiming a verified signature are fully truthful, avoiding
>   * misleading entries that only the loader was verified while the
>   * actual BPF program verification happens later without logging.
>
> This approach addresses concerns from users who require strict audit
> trails and verification guarantees, especially in security-sensitive
> environments.
>
> A working tree with this patchset is being maintained at
> https://github.com/blaiseboscaccy/linux/tree/bpf-hash-chains
>
> bpf CI tests passed as well
> https://github.com/kernel-patches/bpf/actions/runs/18110352925
>
> v2 -> v1:
>    - Fix regression found by syzkaller
>    - Add bash auto-complete support for new command line switch
>
> Blaise Boscaccy (3):
>   bpf: Add hash chain signature support for arbitrary maps
>   selftests/bpf: Enable map verification for some lskel tests
>   bpftool: Add support for signing program and map hash chains
>
>  include/uapi/linux/bpf.h                      |  6 ++
>  kernel/bpf/syscall.c                          | 73 ++++++++++++++++++-
>  .../bpf/bpftool/Documentation/bpftool-gen.rst |  7 +-
>  tools/bpf/bpftool/bash-completion/bpftool     |  2 +-
>  tools/bpf/bpftool/gen.c                       | 27 ++++++-
>  tools/bpf/bpftool/main.c                      |  9 ++-
>  tools/bpf/bpftool/main.h                      |  1 +
>  tools/bpf/bpftool/sign.c                      | 16 +++-
>  tools/include/uapi/linux/bpf.h                |  6 ++
>  tools/lib/bpf/libbpf.h                        |  3 +-
>  tools/lib/bpf/skel_internal.h                 |  6 +-
>  tools/testing/selftests/bpf/Makefile          | 18 ++++-
>  12 files changed, 159 insertions(+), 15 deletions(-)

During a discussion of one of Blaise's earlier BPF signature
verification proposals Alexei mentioned that it sounded like I was
looking for Linus' opinion on our debate[1].  At the time I replied
that I was more interested in trying to find out what the BPF devs
wanted for a BPF program signing solution, and working towards making
sure we had something that worked for everyone[2].  That was almost
five months ago, and while Alexei and KP have provided an example of
their ideal solution, it can now be found in Linus' tree, they have
ignored the larger issues brought up by the LSM community and have
refused to review or comment on Blaise's many attempts[3][4][5][6] to
reconcile the needs of the two communities.

With the lack of engagement from the BPF devs, I'm now at the point
where I'm asking Linus to comment on the current situation around
Blaise's patchset.  I recognize that Alexei and KP have a strong
affinity for the signature scheme implemented in KP's patchset, which
is fine, but if we are going to be serious about implementing BPF
signature verification that can be used by a number of different user
groups, we also need to support the signature scheme that Blaise is
proposing[6].

To make it clear at the start, Blaise's patchset does not change,
block, or otherwise prevent the BPF program signature scheme
implemented in KP's patchset.  Blaise intentionally designed his
patches such that the two signature schemes can coexist together in
the same kernel, allowing users to select which scheme to use on each
BPF program load, enabling the kernel to support policy to selectively
enforce rules around which signature scheme is permitted for each BPF
program load.

Blaise's patch implements an alternate BPF program signature scheme,
using the same basic concepts as KP's design (light skeletons, hash
chaining, etc.), but does so in such a way that the kernel verifies
all relevant parts of the BPF program load prior to calling the
security_bpf_prog_load() LSM hook.  KP's signature scheme only
verifies the light skeleton prior to calling the LSM hook and relies
on the BPF code in the light skeleton to verify the original BPF
program.

Relying on a light skeleton to verify the BPF program means that any
verification failures in the light skeleton will be "lost" as there is
no way to convey an error code back to the user who is attempting the
BPF program load.  Blaise's approach to verifying the full signature
in the kernel, and not relying on the light skeleton for verification,
means that verification failures can be returned to the user; there
are no silent signature verification failures like one can experience
with KP's verification scheme.

KP's signature verification scheme is a two-part scheme with the
security_bpf_prog_load() LSM hook being called after the light
skeleton signature has been verified, but before the light skeleton
verifies the BPF program.  Aside from breaking with typical
conventions around the placement of LSM hooks, this "halfway" approach
makes it difficult for LSMs to log anything about the signature status
of a BPF program being loaded, or use the signature status in any type
of access decision.  This is important for a number of user groups
that use LSM based security policies as a way to help reason about the
security properties of a system, as KP's scheme would require the
users to analyze the signature verification code in every BPF light
skeleton they authorize as well as the LSM policy in order to reason
about the security mechanisms involved in BPF program loading.

Blaise's signature scheme also has the nice property that BPF ELF
objects created using his scheme are backwards compatible with
existing released kernels that do not support any BPF signature
verification schemes, of course without any signature verification.
Loading a BPF ELF object using KP's signature scheme will likely fail
when loaded on existing released kernels.

[1] https://lore.kernel.org/linux-security-module/CAADnVQ+C2KNR1ryRtBGOZTNk961pF+30FnU9n3dt3QjaQu_N6Q@mail.gmail.com/
[2] https://lore.kernel.org/linux-security-module/CAHC9VhRjKV4AbSgqb4J_-xhkWAp_VAcKDfLJ4GwhBNPOr+cvpg@mail.gmail.com/
[3] https://lore.kernel.org/linux-security-module/87sei58vy3.fsf@microsoft.com/
[4] https://lore.kernel.org/linux-security-module/20250909162345.569889-2-bboscaccy@linux.microsoft.com/
[5] https://lore.kernel.org/linux-security-module/20250926203111.1305999-1-bboscaccy@linux.microsoft.com/
[6] https://lore.kernel.org/linux-security-module/20250929213520.1821223-1-bboscaccy@linux.microsoft.com/

-- 
paul-moore.com