[PATCH bpf-next v7 0/5] Signed BPF programs

[Paul Moore]

On Sun, Sep 21, 2025 at 12:01 PM KP Singh <kpsingh at kernel.org> wrote:
>
> BPF Signing has gone over multiple discussions in various conferences with the
> kernel and BPF community ...

In addition to the signature scheme KP has proposed, if we want to
increase adoption of BPF to those who currently disable it due to
strict code provenance and integrity concerns, we need to merge
Blaise's optional signature scheme as described most recently in the
patch posting linked below:

https://lore.kernel.org/linux-security-module/20250909162345.569889-1-bboscaccy@linux.microsoft.com/

It is important to note that Blaise's patch allows both signature
schemes to coexist together in the same kernel, allowing users to
select which scheme to use on each program load, and enables the
kernel to support policy to selectively enforce rules around which
signature scheme is permitted for each load.

While we've discussed this in the past, Blaise's signature scheme is
important as it satisfies requirements that aren't otherwise met:

* Both the lskel and original BPF program are verified for provenance
and integrity prior to the security_bpf_prog_load() hook.  This allows
LSMs, including BPF LSMs, to make access control decisions on the
entirety of the verification, not just the verification of the lskel.
For those users who have very strict security requirements which
require analysis of the system's security policy as part of their
vetting, this limits the scope of the BPF signature verification
policy analysis to just the LSM's policy.  This approach is in keeping
with most every other security significant operation in the kernel,
and is also seen as a best practice, since it significantly simplifies
the analysis of the system's security properties.  KP's signature
scheme, while it does verify the original program, it offloads the
digest verification of the original BPF program to the lskel.  Aside
from breaking with most other kernel-based access control approaches,
this means that analysis of only the LSM's policy is no longer
sufficient, security officers must vet both the LSM's policy as well
as the digest verification code in every lskel used on the system.

* Verification of both the lskel and the original BPF program prior to
the security_bpf_prog_load() hook also makes it possible for
observability, measurement, and attestation focused LSMs to more
easily audit, measure, and attest the verified lskel and original BPF,
as all of the components have passed provenance and integrity
verification while the measurements/digests still remain stable as
none of the lskel based transforms have yet to take place.  Using KP's
signature scheme this isn't quite possible as the original BPF program
is verified during the execution of the lskel which potentially
mutates the original BPF program.

As an aside, Blaise's signature scheme also has the nice property that
BPF ELF objects using Blaise's signature scheme are backwards
compatible with existing kernels, allowing the signed BPF to be loaded
on older kernels, albeit without signature verification for obvious
reasons.  While this may not be important to some users, BPF ELF
objects using KP's signature scheme will likely fail when loaded on
older kernels.

Taken individually, KP's and Blaise's signature schemes may not
satisfy all of the use cases and requirements for BPF signing that
have been discussed over the years, but I believe that the two schemes
together can satisfy everyone's needs.

-- 
paul-moore.com