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