From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Mon, 5 Oct 2020 19:14:06 +0200 Subject: Fit images and EFI_LOAD_FILE2_PROTOCOL In-Reply-To: <20201005152513.5txxae7idr6ruart@holly.lan> References: <951b8fca-da6b-c4bb-8e5a-fc96646f7f07@gmx.de> <20201005152513.5txxae7idr6ruart@holly.lan> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, 5 Oct 2020 at 17:25, Daniel Thompson wrote: > 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. > here it is: https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?usp=sharing > > 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 wrote: > > > > > > > > > > > On Sat, 3 Oct 2020 at 13:16, Fran?ois Ozog > > > wrote: > > > > > >> > > >> > > >> Le sam. 3 oct. 2020 ? 13:14, Fran?ois Ozog > a > > >> ?crit : > > >> > > >>> > > >>> > > >>> Le sam. 3 oct. 2020 ? 10:51, Heinrich Schuchardt > 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.ozog at linaro.org | Skype: ffozog > > _______________________________________________ > > boot-architecture mailing list > > boot-architecture at lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- Fran?ois-Fr?d?ric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog at linaro.org | Skype: ffozog