On Tue, 6 Oct 2020 at 15:12, Heinrich Schuchardt xypron.glpk@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