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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2025-10-17 at 11:03 -0700, Alexei Starovoitov wrote:
> On Thu, Oct 16, 2025 at 6:36 PM Paul Moore <paul@paul-moore.com>
> wrote:
> > 
> > On Thu, Oct 16, 2025 at 6:01 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > On Thu, Oct 16, 2025 at 1:51 PM Paul Moore <paul@paul-moore.com>
> > > wrote:
> > > > On Sun, Oct 12, 2025 at 10:12 PM Paul Moore
> > > > <paul@paul-moore.com> wrote:
> > > > > On Sat, Oct 11, 2025 at 1:09 PM James Bottomley
> > > > > <James.Bottomley@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@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.

Regards,

James