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

[KP Singh]

On Mon, Oct 6, 2025 at 5:08 AM Paul Moore <paul at paul-moore.com> wrote:
>
> On Fri, Oct 3, 2025 at 12:25 PM KP Singh <kpsingh at kernel.org> wrote:
> > 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:
>
> ...
>
> > > > > 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.
>
> I'll be honest, given the months of discussion on this topic already,
> I do worry that claiming a lack of understanding at this point is
> simply a tactic to drag this discussion out or dismiss our arguments,
> but if this is an honest admission let me try and better understand
> the point where you are getting lost ...

No, there is no clear security policy that you have proposed that you
want to implement and this prevents you from implementing the policy.

>
> * You've commented on Blaise's patch, so I'm assuming you have a
> reasonable understanding of Blaise's patch, if not, please speak up.
>
> * Similarly, are you comfortable in your understanding of the
> differences between your BPF signature scheme and what Blaise has been
> proposing in this patchset?
>
> * Do you understand how Blaise's signature scheme verifies the
> signature of both the loader BPF program and the original BPF program
> before the security_bpf_prog_load() LSM hook?
>
> * Do you understand how your signature scheme only verifies the loader
> BPF program before the security_bpf_prog_load() LSM hook, meaning the
> original BPF program has had no integrity or provenance verification
> when security_bpf_prog_load() is called?

Yeah, this loader is signed to load only specific trusted payload. You
are wrong about it not having integrity. The integrity checking
happens in the loader that the very entity that signed the payload of
the loader which contains:

* The hash of the loaded programs and metadata.
* An integrity check that verifies this hash before loading the programs.

I feel we will keep going in circles on this and I will leave it up to
the maintainers to resolve this.



>
> > > > 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.
>
> Please understand that this is the wrong question, for all the reasons
> mentioned above.  A better question would be to ask what primitives
> are necessary to ensure that a LSM has the necessary visibility to
> record the state of the BPF signature verification and make an access
> control decision based on that state.  Blaise's scheme verifies the
> provenance and integrity of both the loader and original BPF program
> prior to the LSM call, your scheme only verifies the loader before the
> LSM call.
>
> --
> paul-moore.com