Fit images and EFI_LOAD_FILE2_PROTOCOL

["François Ozog" <francois.ozog@linaro.org>]

On Mon, 5 Oct 2020 at 17:25, Daniel Thompson <daniel.thompson@linaro.org>
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 <ardb@kernel.org> wrote:
> >
> > >
> > >
> > > On Sat, 3 Oct 2020 at 13:16, Fran?ois Ozog <francois.ozog@linaro.org>
> > > wrote:
> > >
> > >>
> > >>
> > >> Le sam. 3 oct. 2020 ? 13:14, Fran?ois Ozog <francois.ozog@linaro.org>
> a
> > >> ?crit :
> > >>
> > >>>
> > >>>
> > >>> Le sam. 3 oct. 2020 ? 10:51, Heinrich Schuchardt <xypron.glpk@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
>


-- 
Fran?ois-Fr?d?ric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog