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

[Simon Glass]

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

> (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*.

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

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