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

James Bottomley James.Bottomley at HansenPartnership.com
Mon Oct 20 23:13:19 UTC 2025


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.

Regards,

James



More information about the Linux-security-module-archive mailing list