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:
- typical distro (with its weakness)
- 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/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRr...
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@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture