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

[KP Singh]

On Fri, Oct 3, 2025 at 4:36 AM Paul Moore <paul at paul-moore.com> wrote:
>
> 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.

I am failing to understand your security requirements.

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

Please share concrete policies you would like to implement, this is very vague.

- KP

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