[PATCH v2] emulation: fdt: Allow using U-Boot's device tree with QEMU

[Ilias Apalodimas]

On Tue, 15 Apr 2025 at 17:12, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Apr 15, 2025 at 10:22:50AM +0300, Ilias Apalodimas wrote:
> > Hi Tom
> >
> > Thanks for roping me in.
>
> You were cc'd on the original, FWIW.

I completely missed that and only noticed it with your reply. Thanks!

>
> >
> > On Tue, 15 Apr 2025 at 01:53, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sun, Apr 06, 2025 at 07:07:04AM +1200, Simon Glass wrote:
> > >
> > > > At present it is impossible to change the qemu_arm64 defconfig to
> > > > obtain a devicetree from the U-Boot build.
> > > >
> > > > This is necessary for FIT validation, for example, where the signature
> > > > node must be compiled into U-Boot.
> >
> > I'll repeat once more, that using the DT to store whatever random data
> > you invent makes little sense.
> > No one is obliged to follow internal U-Boot ABIs. Instead, it would
> > make much more sense to store the data in the U-Boot binary somewhere
> > and retrieve them. On top of that we now have proper memory
> > permissions at least for arm64 and you can place certificates in
> > .rodata.
>
> I don't see the high level difference really between blob with a
> signature attached somewhere being good (signed EFI files where the
> signature isn't an external file) vs blob with a signature attached
> somewhere being bad (what Simon is doing with FIT here).

There really isn't a technical one. The only thing that makes our
lives a lot easier is that DT is governed by a spec and adding u-boot
signatures in there feels a bit weird. It also *requires* us to do
things like the current patchset, while using the binary itself
doesn't.

>  So as long as
> we can drop the antagonism (and don't break other use cases) I'm fine
> with letting this alternate way of securing a system proceed.
>

Thanks
/Ilias
> --
> Tom