From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Tue, 6 Oct 2020 15:12:36 +0200 Subject: Fit images and EFI_LOAD_FILE2_PROTOCOL In-Reply-To: <149c4a0c-c51e-c591-efc6-76755ed0d322@arm.com> References: <951b8fca-da6b-c4bb-8e5a-fc96646f7f07@gmx.de> <1b8fc3ff-ac50-6f70-db61-30f67dd69151@arm.com> <9B772910-62A9-4770-AE55-77460D1F369F@gmx.de> <70e79c8d-ad3f-f08b-1527-1d3cfb87fde9@arm.com> <20201006124143.GA236482@apalos.home> <149c4a0c-c51e-c591-efc6-76755ed0d322@arm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. Best regards Heinrich