Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

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?

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


Thanks
/Ilias