On Tue, Oct 06, 2020 at 10:00:40AM +0200, François Ozog wrote: > Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel <a...@kernel.org> a écrit : > > > On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt <xypron.g...@gmx.de> > > wrote: > > > > > > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely < > > grant.lik...@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.o...@linaro.org | Skype: ffozog > _______________________________________________ > boot-architecture mailing list > boot-architect...@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/boot-architecture