[PATCH 00/16] tools: Add support for signing devicetree blobs

[Tom Rini]

On Wed, Nov 24, 2021 at 05:12:12PM -0700, Simon Glass wrote:
> Hi François,
> 
> On Sat, 13 Nov 2021 at 11:53, François Ozog <francois.ozog at linaro.org> wrote:
> >
> > Hi Simon
> >
> > Le sam. 13 nov. 2021 à 14:57, Simon Glass <sjg at chromium.org> a écrit :
> >>
> >> Hi Heinrich,
> >>
> >> On Sat, 13 Nov 2021 at 04:57, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >> >
> >> >
> >> >
> >> > On 11/13/21 04:30, Simon Glass wrote:
> >> > > Hi Heinrich,
> >> > >
> >> > > On Fri, 12 Nov 2021 at 17:02, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >> > >>
> >> > >>
> >> > >>
> >> > >> On 11/12/21 20:49, François Ozog wrote:
> >> > >>> Hi Simon
> >> > >>>
> >> > >>> Le ven. 12 nov. 2021 à 20:36, Simon Glass <sjg at chromium.org
> >> > >>> <mailto:sjg at chromium.org>> a écrit :
> >> > >>>
> >> > >>>      At present mkimage supports signing FITs, the standard U-Boot image
> >> > >>>      type.
> >> > >>>
> >> > >>>      Various people are opposed to using FIT since:
> >> > >>>
> >> > >>> just to be sure: I am not one of those.
> >> > >>>
> >> > >>>
> >> > >>>      a) it requires adding support for FIT into other bootloaders, notably
> >> > >>>          UEFI
> >> > >>>
> >> > >>> whatever happens to FIT is entirely orthogonal to U-Boot UEFI subsystem.
> >> > >>> FIT can evolve,  U-Boot UEFI does not have to change.
> >> > >>
> >> > >> We already can create signed FIT images containing a UEFI binary and a
> >> > >> devcie-tree and launch the FIT image with the bootm command.
> >> > >>
> >> > >> Cf.
> >> > >> CONFIG_BOOTM_EFI
> >> > >> test/py/tests/test_efi_fit.py
> >> > >> doc/usage/bootefi.rst
> >> > >>
> >> > >> Simon, what are you missing?
> >> > >
> >> > > Some people don't want to use FIT.
> >> >
> >> > The problem with FIT is that other firmware like EDK II does not support it.
> >> >
> >> > Why do you expect those people to like your new tool better?
> >>
> >> I believe the EDK decision is not so much that it *does* not support
> >> FIT, which is after all not a lot of code, but that it *should* not.
> >> If I have that wrong, please let me know.
> >
> > UEFI (EDK2 and now U-Boot) design choice is that it does not include *any* technologies for OS: UEFI launches an OS loader that know about those.
> > A possible way to introduce a FIT is by adding a protocol that can register a vendor media file , assign a UUID to a FIT. Add support for this in the UEFI stub of the kernel.
> > Another way would be a minimalistic UEFI app that will fetch the second parameter as a FIT. The FIT format parsing code is only in this minimalistic loader. U-Boot can play this role based on your efforts to have U-Boot as UEFI application.
> > You could also promote FIT in the systemd-boot UeFi application. I believe this is a very good option BTW.
> 
> I think UEFI is making things very complicated. If we define a
> standard boot flow we should not need grub.

To be clear, UEFI doesn't require grub (nor systemd-boot) but off the
shelf distributions tend to really really like that, rather than
modifying UEFI variables more directly to implement some sort of boot
menu and other related features.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211124/4fc0c17f/attachment.sig>