Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

On 06/10/2020 05:35, Heinrich Schuchardt wrote:
> Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely <grant.likely at arm.com>:
>>
>>
>> On 03/10/2020 09:51, Heinrich Schuchardt wrote:
>>> Hello Ilias, hello Christian,
>>>
>>> with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
>> initramfs
>>> loading") Ilias provided the possibility to specify a device path
>>> (CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
>>> served via the EFI_FILE_LOAD2_PROTOCOL.
>>>
>>> Ard extended the Linux EFI stub to allow loading the initial RAM disk
>>> via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.
>>>
>>> With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
>>> IH_OS_EFI") Cristian enabled signed FIT images that contain a device
>>> tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).
>>>
>>> In the DTE calls we have discussed that it is unfortunate that we do
>> not
>>> have a method to validate initial RAM images in the UEFI context.
>>>
>>> To me it would look like a good path forward to combine the two
>> ideas:
>>>
>>> * Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
>>> * Pass location and size to the UEFI subsystem and serve them via
>>>     the EFI_FILE_LOAD2_PROTOCOL.
>>>
>>> We could also extend the bootefi command to be callable as
>>>
>>>      bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
>>>
>>> like the booti command to serve an initial RAM disk.
>>>
>>> What are your thoughts?
>>
>> 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.

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