Fit images and EFI_LOAD_FILE2_PROTOCOL

[François Ozog]

On Tue, 6 Oct 2020 at 15:12, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:

> On 06.10.20 14:46, Grant Likely wrote:
> >
> >
> > On 06/10/2020 13:41, Ilias Apalodimas wrote:
> >> Hi Grant,
> >>
> >> [...]
> >>>>>
> >>>>> Hi Heinrich,
> >>>>>
> >>>>> I've got concerns about this approach. Even though it uses the UEFI
> >>>>> infrastructure, images deployed in this way are U-Boot specific and
> >>>>> won't ever be applicable on EDK2 or other UEFI implementations.
> >>>>>
> >>>>> However there is another way to approach it which I think Francois
> >>>>> touched on. If instead a UEFI stub was added to the FIT image, in the
> >>>>> same way that the kernel has a UEFI stub, then the logic of decoding
> >>>>> the
> >>>>> FIT and choosing the correct DTB & initrd can be part of the image
> and
> >>>>> it becomes applicable to any UEFI implementation. It would also
> >>>>> address
> >>>>>
> >>>>> Ard's concern of loading the FIT into memory, and then copying due to
> >>>>> the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
> >>>>> in
> >>>>> RAM, that is is reserved correctly, and just pass the correct
> >>>>> addresses
> >>>>>
> >>>>> to the kernel as part of the normal boot flow.
> >>>>>
> >>>>> Signing would also be taken care of because the whole FIT can be
> >>>>> signed,
> >>>>> and that signature would be checked when it gets loaded.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>
> >>>> The gain of a fit image in U-Boot used for calling the Linux kernel
> >>>> via the EFI stub vs calling the legacy entry point comes down to
> >>>> providing the EFI_RNG_PROTOCOL to be used for KASLR.
> >>>
> >>> I agree with that, but that is not my concern.
> >>>
> >>> My concern is that the FIT image format will only be supported by
> >>> U-Boot.
> >>> Other UEFI implementations do not implement it.
> >>>
> >>> On the other hand, adding a UEFI Stub to the FIT image format makes it
> a
> >>> generic solution that can be used by any UEFI implementation. This
> >>> would be
> >>> separate from the linux kernel's UEFI stub, and should only deal with
> >>> choosing the appropriate kernel/initrd/dtb from the FIT and then
> calling
> >>> into the kernel's stub to actually boot the kernel.
> >>
> >> If we are considering a cross-firmware solution for this why base it
> >> on FIT?
> >> Wouldn't a single EFI application (that's aware of the signatures and
> how
> >> to verify them) do the job? Just to inherit the work on signatures
> >> already done
> >> in FIT?
> >
> > Hahaha! I wasn't going to bring that up because I didn't want to cause
> > extra trouble. :-) But yes, you're right. If we have a UEFI stub on the
> > container, then it doesn't matter what the container format is. cpio,
> > tar.gz, zip, FAT image, etc. Any of those would work.
> >
> >>>> For initrd a stub UEFI binary will work. But if you want to provide
> >>>> a kernel specific  dtb with the same stub binary it will require a
> >>>> new service for device-tree fixups.
> >>>
> >>> Devicetree fixups indeed needs to be solved. I would propose
> >>> registering a
> >>> new protocol for fixups. If the protocol is present, then stub can
> >>> call it.
> >>> If not, then the DTB from the fit should be used unmodified.
> >>>
> >>> g.
> >>
> >> So if you do this in a single EFI app, you wont need an extra protocol
> >> for it
> >> right?
> >
> > True, you could embed the DT fixups into the EFI stub itself, but that
> > would end up being completely separate logic from the fixup code already
> > in U-Boot.
>
> Many fixups are hardware related. We should not write that logic twice.
>
> You could think of copying fixups from the firmware device-tree to the
> stub device-tree but this too would be a very device specific solution.
>
> Having the firmware (e.g. U-Boot) do the fixup would provide a solution
> that is much more generic.
>
Agreed. U-Boot actually should orchestrate fixups (the protocol you just
proposed) and do its own fixups ([chosen][, serial numbers][, part
numbers][, MAC addresses]...).

>
> Best regards
>
> Heinrich
>


-- 
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog