On Tue, 15 Apr 2025 at 17:12, Tom Rini <tr...@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 <tr...@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
