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

[Paul Moore]

On Thu, Oct 23, 2025 at 11:39 AM KP Singh <kpsingh at kernel.org> wrote:
> On Wed, Oct 22, 2025 at 11:10 PM James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> > On Mon, 2025-10-20 at 18:25 -0700, Alexei Starovoitov wrote:
> > > On Mon, Oct 20, 2025 at 4:13 PM James Bottomley
> > > <James.Bottomley at hansenpartnership.com> wrote:
> > [...]
> > > > 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.
> >
> > Most Linux installations use LSMs to enforce and manage policies for
> > system integrity (they don't all use the same set of LSMs, but that's
> > not relevant to the argument).  So while Meta may not use LSMs for
> > system integrity the fact that practically everyone else does makes not
> > having a correctly functioning LSM hook for BPF signature verification
> > a problem for a huge set of users that goes way beyond just Microsoft.
>
> The core tenet of your claim is that  you need "LSM observability" but
> without any description of a security policy
> that cannot not be currently implemented. The responses I have
> received are generic statements that the loader verification is
> "unsafe"

As we've discussed this many times across various threads over the
past several months, I don't see much point in revisiting the
argument.  Instead I'll refer you back to my last response to this,
taken from earlier in this thread; the relevant portion is the last
paragraph:

https://lore.kernel.org/linux-security-module/CAHC9VhSDkwGgPfrBUh7EgBKEJj_JjnY68c0YAmuuLT_i--GskQ@mail.gmail.com/

> If you really consider this unsafe, then you can deny loading programs
> with relocations ...

This would require a LSM to inspect BPF programs and maps at load
time, something Alexei has previously rejected, are you now saying
that this would be acceptable?

https://lore.kernel.org/linux-security-module/CAADnVQJyNRZVLPj_nzegCyo+BzM1-whbnajotCXu+GW+5-=P6w@mail.gmail.com/

-- 
paul-moore.com