Re: -next status as at v7.1-rc6

["Serge E. Hallyn" <serge@hallyn.com>]

On Thu, Jun 04, 2026 at 04:18:46PM -0700, Linus Torvalds wrote:
> On Thu, 4 Jun 2026 at 15:23, Paul Moore <paul@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@linux.microsoft.com
and
20250528215037.2081066-1-bboscaccy@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@HansenPartnership.com)
   about the verifiability of the hash chain link.

> But instead of working with the bpf people on coming up with some
> model that does *not* do that, it all seems to have become a "we'll do
> it anyway, despite maintainer complaints".
> 
> And I *did* see the bpf people pointing to "this would be an
> acceptable alternative" with KP Singh outlining something that *had*
> been discussed.
> 
> But I never actually saw anybody say "ok, we'll try that instead".
> 
> Maybe I missed it.
> 
> But from what I saw, it really looked like "I see NAK's from three
> different bpf maintainers, with suggested alternate approaches". None
> of which resulted in anything that looked like "ok, we'll try to
> follow your guidance", only more of the same.
> 
> Why would *my* input then make any difference?
> 
> The bpf people's arguments resonated more with me. For example, the
> whole "we need to know if it passed the bpf signature" seems to be
> complate pointless silliness, and the bpf peoples responses to that
> resonated with me. There's *no* point in any LSM check whether the
> signature passed or not, since if it didn't pass, it's not getting
> loaded.
> 
> So that's basically where I stand - I've seen disagreement, and I've
> seen what looks to me like reasonable push-back, and I've not really
> seen the LSM response as taking it into account.
> 
>            Linus