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.o...@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 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
