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

[Paul Moore]

On Thu, Oct 2, 2025 at 9:48 AM KP Singh <kpsingh at kernel.org> wrote:
> 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.

I'm sorry you feel that way, but that simply does not appear to be the
case.  Looking at the archives from this year I see that Blase has
proposed three different approaches[7][8][9] to verifying signed BPF
programs, with each new approach a result of the feedback received.

> The community, in fact, prioritized the signing work to unblock your use-case.

As mentioned previously, many times over, while your signature scheme
may satisfy your own
requirements, it does not provide a workable solution for use cases
that have more stringent security requirements.  Blaise's latest
approach, a small patch on top of your patchset, is an attempt to
bridge that divide.

> Blaise's implementation ...

I think Blaise's response addressed your other comments rather well so
I'll just skip over those points.

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

In a perfect world there would be a singular BPF signature scheme
which would satisfy all the different use cases, but the sad reality
is that your signature scheme which Alexei sent to Linus during this
merge window falls short of that goal.  Blaise's patch is an attempt
to provide a solution for the BPF use cases that are not sufficiently
addressed by your signature scheme.

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

The loader BPF program which verifies the original BPF program, stored
as a map as part of the light skeleton, is not executed as part of the
original bpf() syscall issued from userspace.  The loader BPF program,
and its verification code, is executed during a subsequent call.  It
is possible for the PKCS7 signature on the loader to pass, with the
kernel reporting a successful program load, the LSM authorizing the
load based on a good signature, and audit recording a successful
signature verification yet the loader could still fail the integrity
check on the original BPF program, leaving the system with a false
positive on the BPF program load and a "questionable" audit trail.

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

No one policy can satisfy the different security requirements of all
known users, simply look at all of the LSMs (including the BPF LSM)
which support different security policies as a real world example of
this.  Even the presence of the LSM framework as an abstract layer is
an admission that no one policy, or model, solves all problems.
Instead, the goal is to ensure we have mechanisms in place which are
flexible enough to support a number of different policies and models.

[7] https://lore.kernel.org/all/20250109214617.485144-1-bboscaccy@linux.microsoft.com/
[8] https://lore.kernel.org/linux-security-module/20250321164537.16719-1-bboscaccy@linux.microsoft.com/
[9] https://lore.kernel.org/linux-security-module/87sei58vy3.fsf@microsoft.com/

-- 
paul-moore.com