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

[Ilias Apalodimas]

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.

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

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

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