Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ilias Apalodimas]

On Sat, Oct 03, 2020 at 03:12:30PM +0200, Ard Biesheuvel wrote:
> On Sat, 3 Oct 2020 at 13:16, François Ozog <francois.ozog at linaro.org> wrote:
> 
> >
> >> that looks super interesting.
[...]
> >> I propose something (in the latest desk preparing oct 14th) similar
> >> except the an efi application boots the FIT.
> >> I view UEFI as booting a PE coff and pass a set of config tables. Today
> >> we have DTB, we could just add Initrd (you command line). Bootefi would be
> >> responsible to valide the containing FIT before pushing initrd (and
> >> dTB?)into the table. It would be the responsibility of the efi stub to get
> >> the initrd from the config table (GUID to be defined).
> >>
> > the memory attributes of the initrd config table should be such that it
> > can be recovered for normal use. That may be tricky though.
> >
> 
> The purpose of the EFI_FILE_LOAD2_PROTOCOL based initrd loading mechanism
> is to allow the EFI stub (which is tightly coupled to the kernel
> arch/version/etc) to allocate the memory for the initrd, and pass it into
> the LoadFile2() request, using whichever policy it wants to adhere to for
> alignment, offset and/or vicinity of the kernel image. It also ensures that
> any measurement performed by the bootloader for attestation or
> authentication can be delayed to the point where the booting kernel assumes
> ownership of the initrd contents, preventing potential TOCTOU issues where
> intermediate boot stages are involved (shim+grub etc)
> 
> Creating an initrd config table would mean that the bootloader decides
> where to load the initrd in memory, and only passes the address and size.
> This is exactly what we wanted to avoid, because now, the bootloader has to
> know all these different rules that vary between kernel version,
> configurations and architectures.
> 
> For uboot's implementation of FIT based EFI_FILE_LOAD2_PROTOCOL, this might
> mean that the initrd is loaded into memory first, and copied to another
> location (and [re-]authenticated) when LoadFile2() is invoked. I don't
> think this is a problem in the general case, but we might think about ways
> to avoid this if this turns out to be a problem for memory constrained
> devices with huge initrds.

+1 
That sounds like the easiest and sanest path at the moment. 
I think that standardizing a Linux construct (initramfs) authentication from a
firmware doesn't make too much sense.
I haven't seen FIT images in detail (so shout if I am horribly wrong), but changing 
lib/efi_loader/efi_load_initrd.c to authenticate the FIT image and extract the
initramfs for the kernel seems possible and it's close to what we do today.

Right now u-boot is reading a .config path to determine and load the file, 
something like <device> <partition> <file> i.e mmc 0:1 initrd.cpio.gz. 
Can't we just detect it's a FIT image that contains it, authenticate and extract 
it before passing it on?


Cheers
/Ilias