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

[Paul Moore]

On Thu, Oct 16, 2025 at 6:01 PM Alexei Starovoitov
<alexei.starovoitov at gmail.com> wrote:
> On Thu, Oct 16, 2025 at 1:51 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Sun, Oct 12, 2025 at 10:12 PM Paul Moore <paul at paul-moore.com> wrote:
> > > On Sat, Oct 11, 2025 at 1:09 PM James Bottomley
> > > <James.Bottomley at hansenpartnership.com> wrote:
> > > > On Sat, 2025-10-11 at 09:31 -0700, Alexei Starovoitov wrote:
> > > > > On Sat, Oct 11, 2025 at 7:52 AM James Bottomley
> > > > > <James.Bottomley at hansenpartnership.com> wrote:
> > > > > >
> > > > > > It doesn't need to, once we check both the loader and the map, the
> > > > > > integrity is verified and the loader can be trusted to run and
> > > > > > relocate the map into the bpf program
> > > > >
> > > > > You should read KP's cover letter again and then research trusted
> > > > > hash chains. Here is a quote from the first googled link:
> > > > >
> > > > > "A trusted hash chain is a cryptographic process used to verify the
> > > > > integrity and authenticity of data by creating a sequence of hash
> > > > > values, where each hash is linked to the next".
> > > > >
> > > > > In addition KP's algorithm was vetted by various security teams.
> > > > > There is nothing novel here. It's a classic algorithm used
> > > > > to verify integrity and that's what was implemented.
> > > >
> > > > Both KP and Blaise's patch sets are implementations of trusted hash
> > > > chains.  The security argument isn't about whether the hash chain
> > > > algorithm works, it's about where, in relation to the LSM hook, the
> > > > hash chain verification completes.
>
> Not true. Blaise's patch is a trusted hash chain denial.

It would be helpful if you could clarify what you mean by "trusted
hash chain denial" and how that differs from a "trusted hash chain".

> > > Alexei, considering the discussion from the past few days, and the
> > > responses to all of your objections, I'm not seeing a clear reason why
> > > you are opposed to sending Blaise's patchset up to Linus.  What is
> > > preventing you from sending Blaise's patch up to Linus?
> >
> > With the merge window behind us, and the link tag discussion winding
> > down ;) , I thought it might be worthwhile to bubble this thread back
> > up to the top of everyone's inbox.
>
> Please stop this spam. The reasons for rejection were explained
> multiple times.

I believe we have provided satisfactory counter arguments in each of
those cases, and those counter arguments remain unanswered.  Without a
response it's impossible to move forward towards a solution that
everyone can find acceptable, unless that is the core issue?  Is your
position that any solution outside of what you sent to Linus during
this past merge window is unacceptable?

-- 
paul-moore.com