On Wed, May 28, 2025 at 05:35:21PM +0100, Simon Glass wrote: > Hi Tom, > > On Wed, 28 May 2025 at 16:05, Tom Rini <tr...@konsulko.com> wrote: > > > > On Wed, May 28, 2025 at 03:32:08PM +0100, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 28 May 2025 at 15:12, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Wed, May 28, 2025 at 08:35:37AM +0100, Simon Glass wrote: > > > > > Hi Ilias, > > > > > > > > > > On Tue, 27 May 2025 at 10:20, Ilias Apalodimas > > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Tue, 27 May 2025 at 11:20, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > > > > > Hi Ilias, > > > > > > > > > > > > > > On Sat, 24 May 2025 at 19:13, Ilias Apalodimas > > > > > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Sat, 24 May 2025 at 15:09, Simon Glass <s...@chromium.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > A previously rejected patch to move the EFI public cerificate > > > > > > > > > out of the > > > > > > > > > devicetree has recently been applied. This series reverts the > > > > > > > > > change, > > > > > > > > > pending further discussion as to why it was accepted. > > > > > > > > > > > > > > > > I spent a good amount of time, writing the commit message an > > > > > > > > explaining why this patch was sent > > > > > > > > > > > > > > Yes, that is [1] and I did read it carefully before sending my > > > > > > > series. > > > > > > > > > > > > > > From my POV there are two things wrong there: > > > > > > > - The signature is not an internal U-Boot ABI. > > > > > > > > > > > > It is, as it is for every firmware that builds out there. EDKII does > > > > > > the same thing. > > > > > > > > > > I mean that in U-Boot's case it is a published and documented > > > > > interface, or was until a few weeks ago. > > > > > > > > > > > > > > > > > > It is how U-Boot works, > > > > > > > so if a build systems wants to inject a key it should use that > > > > > > > mechanism, not add a new mechanism into U-Boot's build system. If > > > > > > > it > > > > > > > would help to have some documentation somewhere which says this, I > > > > > > > would be happy to send a patch to add something > > > > > > > - QEMU is blocked from accepting devicetree additions due to > > > > > > > another > > > > > > > Linaro employee's refusal to accept a patch[2] > > > > > > > > > > > > It's not blocked. It has been NAK'ed and IMHO for a very good > > > > > > reason. > > > > > > > > > > > > > > > > > > > > > (which btw wasn't 'rejected', you > > > > > > > > forcefully reverted it back then with no agreements from anyone) > > > > > > > > > > > > > > The original series [4] was applied (I believe accidentally) > > > > > > > against > > > > > > > my objections. Heinrich pulled the revert [5]. I went ahead and > > > > > > > did > > > > > > > the QEMU patch, to help with your issue*. > > > > > > > > > > > > Heinrich applied the patches initially, and you send the revert, > > > > > > that > > > > > > none of the patch reviewers ack'ed. > > > > > > You reasoning back then is that the RO functionality was moot, > > > > > > because > > > > > > we didn't have it. It's here now. > > > > > > > > > > That was one aspect of my reasoning, but of course we can copy the > > > > > signature into protected memory, make the devicetree readonly, etc. if > > > > > desired. > > > > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > > why we prefer to do it this way. tl;dr early boot loaders that > > > > > > > > pass as > > > > > > > > a DT is a problem now. > > > > > > > > If there's a good reason to revert it, please explain it on the > > > > > > > > commit message > > > > > > > > > > > > > > The reasoning hasn't changed from the discussion three years ago - > > > > > > > please see [4]. There's also lots of discussion on your original > > > > > > > series and my revert, e.g the cover letter. A highly relevant > > > > > > > part of > > > > > > > this is that devicetree is where config should be stored, so the > > > > > > > build > > > > > > > system has control over what is placed there. > > > > > > > > > > > > > > But in any case, it isn't right to send the series again, under a > > > > > > > different name, e.g. not mentioning device tree. > > > > > > > > > > > > > > [..] > > > > > > > > > > > > > > Regards, > > > > > > > Simon > > > > > > > > > > > > > > * The QEMU patch is still outstanding after three years. Could you > > > > > > > please talk to Peter Maydell and see if you can get this > > > > > > > resolved? I > > > > > > > have sent it twice since, most recently in April [7] but there > > > > > > > was not > > > > > > > even a reply. > > > > > > > > > > > > Because they NAK'ed it a few years ago, and aren't willing to take > > > > > > it. > > > > > > I don't think there's anything to discuss and for the record I agree > > > > > > with the QEMU maintainers on this. > > > > > > > > > > Yes, I agree that discussion is unlikely to be fruitful. My point > > > > > remains though that your series should not have been applied, given > > > > > the previous discussion. > > > > > > > > > > This thread and the links should provide context for the future, if > > > > > needed. > > > > > > > > > > One other thing I forgot for the record is that [8] and [9] are only > > > > > needed due to Linaro's refusal to accept the QEMU patch or propose a > > > > ^^^^^ > > > > > > > convenient alternative. > > > > > > > > > > For now I've applied this series to my tree. > > > > > > > > You can do whatever you like in your downstream tree, but please stop > > > > implying that "Linaro" is in charge of QEMU. They very much are not and > > > > I don't want other communities to think that you and your attitude > > > > represent the U-Boot project. > > > > > > That wasn't my intention at all. Where are you reading that? > > > > > > I am just pointing out that Linaro rejected [2]. Ilias (also at > > > Linaro) has stated that he agreed with the decision. Do you agree with > > > my analysis here? > > > > And then your analysis here are where it sure sounds like you blame > > Linaro for what the QEMU project is doing. I am 100% certain that if > > Ilias and Peter left Linaro today, tomorrow they would still reject your > > changes on technical, not implicitly nefarious business, grounds. > > Not the QEMU project, just the ARM maintainer, who I believe is Peter > Maydell who I believe works at Linaro.
And you're implying that there's decisions being made for anything other than technical reasons, due to who employs people. Most people are going to find that insulting and I don't want people to think you speak for the U-Boot project when you talk like that. > I think it is important to call out this sort of thing, so people know > where the roadblocks are for U-Boot in the firmware world. This is > certainly one of them. It's not a roadblock for U-Boot. It may or may not be a challenge for your vision of a verified boot and update mechanism that I have implored you to get external feedback and buy in on instead of building a vision and then well I don't know how to charitably describe what you're doing. -- Tom
signature.asc
Description: PGP signature
