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

[Alexei Starovoitov]

On Mon, Oct 20, 2025 at 4:13 PM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
>
> On Fri, 2025-10-17 at 11:03 -0700, Alexei Starovoitov wrote:
> > On Thu, Oct 16, 2025 at 6:36 PM Paul Moore <paul at paul-moore.com>
> > wrote:
> > >
> > > 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".
> >
> > Paul,
> > This is getting ridiculous. You're arguing about the code that you
> > don't understand. Stop this broken phone and let Blaise defend his
> > code.
>
> That might be my fault: I told Blaise only to respond to technical
> issues and arguing about what you want to name an algorithm isn't
> really a technical issue with the patch.
>
> The point, for me, is when doing integrity tests both patch sets
> produce identical results and correctly detect when integrity of a
> light skeleton is compromised (in mathematical terms that means they're
> functionally equivalent).  The only difference is that with Blaise's
> patch set verification completes before the LSM load hook is called and
> with KP's it completes after ... and the security problem with the
> latter case is that there's no LSM hook to collect the verification
> result.

the security problem with KP's approach? wtf.
I'm going to add "depends on !microsoft" to kconfig bpf_syscall
and be done with it.
Don't use it since it's so insecure.