-next status as at v7.1-rc6

[James Bottomley]

On Fri, 2026-06-05 at 08:45 -0500, Serge E. Hallyn wrote:
> On Thu, Jun 04, 2026 at 04:18:46PM -0700, Linus Torvalds wrote:
> > On Thu, 4 Jun 2026 at 15:23, Paul Moore <paul at paul-moore.com>
> > wrote:
> > > 
> > > While you didn't reply to any of my comments explaining how
> > > Hornet works, specifically how it ties into the kernel, I'm
> > > assuming you've read the overview.  Can you help those of us in
> > > the LSM space understand why a BPF dev's NACK on code that lives
> > > strictly under security/ is sufficient grounds to reject an LSM
> > > patch?
> > 
> > Honestly, I'm not competent to make a judgment call between two
> > different models for hash chain verification, so I basically *have*
> > to go by maintainer opinions.
> > 
> > And the discussions I have been cc'd on have not been what I'd call
> > enlightening.
> > 
> > But people have pointed out that the LSM code mucks around with bpf
> > internals, and those NAK's have had reasons for them.
> > 
> > And honestly, I don't understand *why* Hornet does what it does -
> > and does it in ways that obviously annoy the bpf people. There is
> > no *reason* to look at the bpf maps that I can see, and from my
> > understanding of Alexei's arguments (which may be lacking), the
> > fact that Hornet does that is the main reason for the NAK.
> 
> The two most useful threads I believe were from a year ago,
> 20250502184421.1424368-1-bboscaccy at linux.microsoft.com
> and
> 20250528215037.2081066-1-bboscaccy at linux.microsoft.com
> which includes the proposal by the BPF side:
> https://lore.kernel.org/linux-security-module/CACYkzJ6VQUExfyt0=-FmXz46GHJh3d=FXh5j4KfexcEFbHV-vg@mail.gmail.com/
> 
> There were 2 or three objections from each side iiuc, but the main
> ones that stuck in my mind were
> 
> 1. whether it is ok to rely on a signed userspace bpf verifier
> program to
>    verify the signature.
> 2. objection by James Bottomley 
>   
> (2f71d6c03698eb17d51f7247efde777627ee578a.camel at HansenPartnership.com
> )
>    about the verifiability of the hash chain link.

My objection to the upstream signature scheme in that email was that if
you hand me a lskel consisting of a loader and a map and ask me to sign
it, how do I know the loader actually verifies the hash of the map
without having to disassemble and analyze it.

I think the second patch set (not yet upstream) makes that task easier
because it now calls out to the bpf_loader_verify_metadata() kfunc to
verify the map.  That means I can run the loader in a sandbox and see
if it makes the call, which is way easier than having to disassemble
and analyse its byte code.  Note: it's still not as easy as the hornet
method of simply having the map hash as a signed attribute I can
extract and verify, though.  However, the required task has gone from
pretty impossible to doable.

Regards,

James