Fit images and EFI_LOAD_FILE2_PROTOCOL

[Cristian Ciocaltea <cristian.ciocaltea@gmail.com>]

Hello Heinrich,

On Sat, Oct 03, 2020 at 10:51:24AM +0200, 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.

Thanks for sharing this information, I was not aware of the work
related to the EFI_FILE_LOAD2_PROTOCOL, neither in the Linux kernel
nor in U-Boot.

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

I think having initial RAM disk support in UEFI FIT images would be a
great improvement.

For the moment I had to put on hold my experiments around bootefi and
verified boot scenarios, but I will do my best to resume this work in
the foreseeable future.

> Best regards
> 
> Heinrich

Kind regards,
Cristi