[PATCH 0/3] efi_loader: Move the public cerificate back to the devicetree

[Tom Rini]

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 <trini at 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.apalodimas at linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Tue, 27 May 2025 at 11:20, Simon Glass <sjg at chromium.org> wrote:
> > > > >
> > > > > Hi Ilias,
> > > > >
> > > > > On Sat, 24 May 2025 at 19:13, Ilias Apalodimas
> > > > > <ilias.apalodimas at linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Sat, 24 May 2025 at 15:09, Simon Glass <sjg at 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.

> > > > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20250401112729.2181793-1-ilias.apalodimas@linaro.org/
> > > > > [2] https://patchwork.kernel.org/project/qemu-devel/patch/20210926183410.256484-1-sjg@chromium.org/#24481799
> > > > > [3] https://lore.kernel.org/u-boot/CAPnjgZ2uM=n8Qo-a=DUkx5VW5Bzp5Xy8=Wgmrw8ESqUBK00YJQ@mail.gmail.com/
> > > > > [4] https://patchwork.ozlabs.org/project/uboot/list/?series=253693&state=*&archive=both
> > > > > [5] https://patchwork.ozlabs.org/project/uboot/cover/20210802144431.2396678-1-sjg@chromium.org/
> > > > > [6] https://patchwork.kernel.org/project/qemu-devel/patch/20250405191352.2597585-1-sjg@chromium.org/
> > > > > [7] https://patchwork.kernel.org/project/qemu-devel/patch/20250405191352.2597585-1-sjg@chromium.org/
> > > [8] https://lore.kernel.org/u-boot/20250510134253.1581164-2-sjg@chromium.org/
> > > [9] https://docs.u-boot.org/en/latest/develop/devicetree/dt_qemu.html
> >
> > --
> > Tom

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250528/390c198b/attachment.sig>