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.
