On Wed, Jun 11, 2025 at 4:43 PM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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 >
