Re: [PATCH 10/12] libbpf: Embed and verify the metadata hash in the loader

[KP Singh <kpsingh@kernel.org>]

On Wed, Jun 11, 2025 at 4:43 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Wed, 2025-06-11 at 15:41 +0200, KP Singh wrote:
> > On Wed, Jun 11, 2025 at 3:18 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > >
> > > On Wed, 2025-06-11 at 14:33 +0200, KP Singh wrote:
> > > > [...]
> > > > I have read and understood the code, there is no technical
> > > > misalignment.
> > > >
> > > > I am talking about a trusted user space loader. You seem to
> > > > confuse the trusted BPF loader program as userspace, no this is
> > > > not userspace, it runs in the kernel context.
> > >
> > > So your criticism isn't that it doesn't cover your use case from
> > > the signature point of view but that it didn't include a loader for
> > > it?
> > >
> > > The linked patch was a sketch of how to verify signatures not a
> > > full
> >
> > It was a non functional sketch that did not address much of the
> > feedback that was given, that's not how collaboration works.
>
> It was somewhat functional for the security use case but could be
> extended for yours and provably allowed both was the point of the
> sketch.  The feedback it addressed was your desire for a signed trusted
> loader.
>
> > > implementation.  The pieces like what the loader looks like and
> > > which keyring gets used are implementation details which can be
> > > filled in later by combining the patch series with review and
> > > discussion.  It's not a requirement that one person codes
> > > everyone's use case before they get theirs in, it's usually a
> > > collaborative effort ... I mean, why
> >
> > Yeah, it's surely a collaborative effort, but the collaboration has
> > been aggressive and tied to a specific implementation (at least from
> > some folks). Rather than working with the feedback received it has
> > been accusational of mandating and forcing.
>
> I don't see how that squares with producing a sketch that supports your
> use case ... clearly feedback has been incorporated.
>
> >  If the intent is to really collaborate, let's land this base
> > implementation and discuss further. I am not willing to add
> > additional stuff into this base implementation.
>
> Just so I'm clear: your definition of collaboration means Blaise takes
> feedback from you at all times but you don't take it from him until
> you've got your use case upstream?  This might be OK if the two use
> cases were thousands of lines apart, but, as I've said before, it seems
> to be less than a hundred lines which doesn't seem to be a huge
> integration burden given the size of the patch set you're trying to
> land.  I'm sure Blaise would be willing to produce the patch set that
> adds the incremental over what you've published here to demonstrate its
> smallness.
>
> > > would you want Microsoft coding up the loader?  If they don't have
> > > a use case for it they don't have much incentive to test it
> > > thoroughly whereas you do.
> >
> > It seems that your incentives are purely aligned with Microsoft and
> > not that of the BPF community at large (this is also visible from the
> > patches and the engagement).
>
> No, as has been stated many times before there are other companies than
> Microsoft who want supply chain integrity for BPF code which the data
> block hash chaining you proposed but didn't implement does perfectly.
> I shouldn't have to remind people that open source is about scratching
> your own itch and thus you can determine a company's investments in
> open source by its goals.   I've even given a few talks about this:
>
> https://archive.fosdem.org/2020/schedule/event/selfish_contributor/
>
> As a Linux community we're usually good at creaming off additional
> things around the edges,  such as integrating the two approaches, which
> I'm sure Microsoft will be happy to invest Blaise's time on, but I'm
> equally sure they won't invest huge amounts in testing the trusted
> loader until they have a use case for it.
>
> >  FWIW, There is no urgency for my employer to have signed BPF
> > programs, yet I am working on this purely to help you and the
> > community.
>
> From what I heard Google is using signed BPF internally but has no
> urgency to get it upstream.  However, in my experience Google always

This is incorrect.

> has a lack of upstream urgency until they run into a backporting
> problem, so I'm sure they'll give you credit for avoiding potential

Also not correct, please stop assuming things.

> future backport issues.



>
> Regards,
>
> James
>