[PATCH bpf-next v2 0/3] BPF signature hash chains
Alexei Starovoitov
alexei.starovoitov at gmail.com
Thu Oct 16 22:00:49 UTC 2025
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.
> >
> > 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.
More information about the Linux-security-module-archive
mailing list