On Mon, Oct 05, 2020 at 04:12:11PM +0200, François Ozog wrote: > The driving idea is that there is an existing bootflow, non UEFI that > allows vmlinuz, initrd and DTB to be protected in a single FIT. The > trustworthiness of the solution is higher that regular distro on pure UEFI > systems but does not allow initrd changes as you install stuff. We need to > keep in mind the use cases: most of the cases are for production devices > where updates are not "calculated" in place but rather deployed with > various means. > > I'd like to define two EBBR boot flows: > 1) typical distro (with its weakness) > 2) typical embedded (as of today, addressing security and mix/match > protection) > > The 1) is described in slide 4 of the deck > The 2) is described in slide 5.
It seems these discussion keeps looping back to out-of-band resources. If we have to keep referring to out-of-band resources to follow discussion can you ensure there is a link to said out-of-band resources when citing modifications to them. It's frustrating to have to go rummaging through my mail archives to find your doc. Daniel. > > The UEFI interface is still OS independent but comes with an additional > opportunity: the ESP File System is "merged" with contents of a FIT (kind > of overlayfs). This way the content of the FIT can be checked and EFIStub > with EFI-LOAD_FILE2 the initrd. The bootXXXX will still indirectly point to > the FIT contained .EFI application, the firmware DTB may be overwritten by > a FIT DTB. > > Is this a better scenario to establish 2)? > > Cheers > > > FF > > On Sat, 3 Oct 2020 at 15:12, Ard Biesheuvel <a...@kernel.org> wrote: > > > > > > > On Sat, 3 Oct 2020 at 13:16, François Ozog <francois.o...@linaro.org> > > wrote: > > > >> > >> > >> Le sam. 3 oct. 2020 à 13:14, François Ozog <francois.o...@linaro.org> a > >> écrit : > >> > >>> > >>> > >>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt <xypron.g...@gmx.de> a > >>> écrit : > >>> > >>>> 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? > >>> > >>> 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. > > > > > > > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > _______________________________________________ > boot-architecture mailing list > boot-architect...@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/boot-architecture