Fit images and EFI_LOAD_FILE2_PROTOCOL

[Daniel Thompson]

On Tue, Oct 06, 2020 at 10:00:40AM +0200, François Ozog wrote:
> Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel <ardb at kernel.org> a écrit :
> 
> > On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt <xypron.glpk at gmx.de>
> > wrote:
> > >
> > > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely <
> > grant.likely at arm.com>:
> > > >
> > > >
> > > >On 03/10/2020 09:51, Heinrich Schuchardt wrote:
> > > >> 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?
> > > >
> > > >Hi Heinrich,
> > > >
> > > >I've got concerns about this approach. Even though it uses the UEFI
> > > >infrastructure, images deployed in this way are U-Boot specific and
> > > >won't ever be applicable on EDK2 or other UEFI implementations.
> > > >
> > > >However there is another way to approach it which I think Francois
> > > >touched on. If instead a UEFI stub was added to the FIT image, in the
> > > >same way that the kernel has a UEFI stub, then the logic of decoding
> > > >the
> > > >FIT and choosing the correct DTB & initrd can be part of the image and
> > > >it becomes applicable to any UEFI implementation. It would also address
> > > >
> > > >Ard's concern of loading the FIT into memory, and then copying due to
> > > >the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
> > > >in
> > > >RAM, that is is reserved correctly, and just pass the correct addresses
> > > >
> > > >to the kernel as part of the normal boot flow.
> > > >
> > > >Signing would also be taken care of because the whole FIT can be
> > > >signed,
> > > >and that signature would be checked when it gets loaded.
> > > >
> > > >Thoughts?
> > > >
> > >
> > > The gain of a fit image in U-Boot used for calling the Linux kernel via
> > the EFI stub vs calling the legacy entry point comes down to providing the
> > EFI_RNG_PROTOCOL to be used for KASLR.
> > >
> > > For initrd a stub UEFI binary will work. But if you want to provide a
> > kernel specific  dtb with the same stub binary it will require a new
> > service for device-tree fixups.
> > >
> > > Both approaches are on Francois' DTE slidedeck.
> > >
> > > When thinking of security what really is unclear to me is how we can
> > safely provide the decryption key for the root partition. Without such a
> > means secure boot stops being secure once Linux starts the init process. I
> > would assume that only the secure world can provide the key.
> > >
> >
> > Secure boot only deals with authentication, which does not require any
> > secret keys.
> >
> > Encrypted file systems are a completely separate matter. Typically,
> > this is based on TPM-based local attestation, where the decryption key
> > has been sealed into the TPM, and is only unsealed when all the boot
> > components check out (based on their 'measurements' [aka hashes] that
> > are cumulatively recorded in TPM hardware registers called PCRs)
> >
> > In general, keeping secrets on a device is much more difficult than
> > authenticating executable images, and typically involves some user
> > provided secret, or h/w support. UEFI secure boot only reasons about
> > authentication.
> 
> 
> If SecureBoot is involving Microsoft certificate, a US governmental agency
> could get its code signed and insert itself in a stealth mode (efi apps or
> drivers -> rootkit?)

It is possible that user customizable systems (EBBR booting something
like a normal distro) might choose to ship with Microsoft certificates.
However in the general case there is no good reason to ship a fully
integrated embedded product (e.g. not user modifiable) that trusts the
MS certificate.


> If the set of keys must include this certificate  , then to achieve
> SecureBoot you actually need the TPM to control what signed code you
> accept.

I don't quite follow here.

Why does choosing to trust MS reqiure a second signature. Surely
either we do trust MS or we don't enroll the cert. Why is there a third
way here?


Daniel.


> If the certificate can be omitted I would either sign the shim or add the
> sha256 of trustable ones.
> 
> The unsealing if keys for rootfs decryption is yet another capability that
> is offered by TPM to protect against different nature of attacks
> (conuterfeit products, confidentiality...)

> 
> >
> > --
> 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