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

[James Bottomley]

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 at 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
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
future backport issues.

Regards,

James