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
