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

[Simon Glass]

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?

Regards,
Simon


>
> > > > [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