Fit images and EFI_LOAD_FILE2_PROTOCOL

[Daniel Thompson]

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 <ardb at kernel.org> wrote:
> 
> >
> >
> > On Sat, 3 Oct 2020 at 13:16, François Ozog <francois.ozog at linaro.org>
> > wrote:
> >
> >>
> >>
> >> Le sam. 3 oct. 2020 à 13:14, François Ozog <francois.ozog at linaro.org> a
> >> écrit :
> >>
> >>>
> >>>
> >>> Le sam. 3 oct. 2020 à 10:51, Heinrich Schuchardt <xypron.glpk at 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.ozog at linaro.org | Skype: ffozog
> _______________________________________________
> boot-architecture mailing list
> boot-architecture at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture