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

[Tom Rini]

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.

> > > [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
-------------- 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/4f0a35e7/attachment.sig>