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

[Ilias Apalodimas]

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

And interfaces are there to change if needed, not to mention various
people have stated it's an obvious violation of the DT spec.
This doesn't break any forward or backwards compatibility, so I really
don't see the point of tthis.

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

But you still haven't responded on what we will do if a previous
loader hands us the DT not to mention that making the DT RO is not
really doable easily, with all the code we have for fixing it up in
random stages.

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

There are people that agreed and tested it and you are the only one
still objecting and imho for non-valid reasons.
Anyway, unless there's a very good reason to revert this, i much
prefer it over what we had.

Thanks
/Ilias

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