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

[KP Singh]

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"

If you really consider this unsafe, then you can deny loading programs
with relocations and re-enable them when / if we achieve stable
instruction buffers. To be honest, with this restriction of all
signature verification happening in the kernel you also need to deny
key real-world BPF use-cases like Cilium, bpftrace which generate eBPF
programs on the target host which also shows me how out of touch you
are with the eBPF eco-system and users.

- KP

> Regards,
>
> James
>