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

[KP Singh]

On Wed, Oct 1, 2025 at 11:37 PM Paul Moore <paul at paul-moore.com> wrote:
>

[...]

> 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

The lack of engagement is because Blaise has repeatedly sent patches
and ignored maintainer feedback and continued pushing a broken
approach. The community, in fact, prioritized the signing work to
unblock your use-case.

> 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].
>

Blaise's implementation fails on any modern BPF programs since
programs use more than one map, BTF information and kernel functions.

> 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

We cannot have multiple signature schemes, this is not the experience
we want for BPF users.

> 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

You are confusing a light skeleton from a loader program. Loader
programs are independent of light skeletons.

> 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

This is not correct, the error is propagated back if the loader program fails.

> 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

Again you mean, loader BPF program. Skeletons are just for
convenience. You don't have to use them. libbpf provides an
implementation to easily generate loader programs, but you don't have
to use that either.

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

This does not make any sense. The ELF format and the way loaders like
libbpf interpret it, has nothing to do with the kernel or UAPI.

I had given detailed feedback to Blaise in
https://lore.kernel.org/bpf/CACYkzJ6yNjFOTzC04uOuCmFn=+51_ie2tB9_x-u2xbcO=yobTw@mail.gmail.com/
mentions also why we don't want any additional UAPI.

You keep mentioning having visibility  in the LSM code and I again
ask, to implement what specific security policy and there is no clear
answer? On a system where you would like to only allow signed BPF
programs, you can purely deny any programs where the signature is not
provided and this can be implemented today.

Stable programs work as it is, programs that require runtime
relocation work with loader programs. We don't want to add more UAPI
as, in the future, it's quite possible that we can make the
instruction buffer stable.

- KP

>
> [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