From mboxrd@z Thu Jan  1 00:00:00 1970
From: Grant Likely <grant.likely@arm.com>
Date: Mon, 5 Oct 2020 23:37:58 +0100
Subject: Fit images and EFI_LOAD_FILE2_PROTOCOL
In-Reply-To: <951b8fca-da6b-c4bb-8e5a-fc96646f7f07@gmx.de>
References: <951b8fca-da6b-c4bb-8e5a-fc96646f7f07@gmx.de>
Message-ID: <1b8fc3ff-ac50-6f70-db61-30f67dd69151@arm.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de



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?

g.