On Fri, 2 Oct 2020 at 15:12, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
Please read
https://u-boot.readthedocs.io/en/latest/uefi/uefi.html#launching-a-uefi-bina...
Up to now the signed fit image can provide the UEFI binary and the FDT.
We could easily and probably should extend U-Boot to provide the RAM disk loaded as part of a fit image via the EFI_LOAD_FILE2_PROTOCOL for consumption by Linux.
@Ard: Is there any documentation for the usage of the EFI_LOAD_FILE2_PROTOCOL by Linux? I could not find anything in https://www.kernel.org/doc/html/latest/search.html. We should document how the RAM disk is passed to the EFI stub and how it is communicated to the main Linux.
To my understanding this is how it works:
If the the kernel command line contains "noinitrd", no RAM disk is loaded by the EFI stub.
If the parameter is not passed the initial RAM disk is searched in the following sequence:
- EFI_LOAD_FILE2_PROTOCOL
- file path indicated by initrd= command line argument.
After successfully loading a RAM disk the Linux EFI stub sets the device tree properties "linux,initrd-start" and "linux,initrd-end" in the "/chosen" node to indicated the location of the RAM disk.
If the EFI stub is called without a device-tree, an empty device tree is created for adding these properties. So on boards with ACPI the initrd address is passed via the device-tree too.
GRUB uses the same DT properties to pass a RAM disk (function linux_prepare_fdt()). So the RAM disk position passed by GRUB is only a fallback replaced by the kernel EFI stub when loading an image via the EFI_LOAD_FILE2_PROTOCOL or the initrd= parameter.
Indeed.
The need to modify the DT to pass parameters to the incoming kernel is problematic, because it interferes with the OS's ability to authenticate it (assuming we ever get to that point).
What we attempted with these changes is to have a cleaner separation between a) h/w description b) data provided by the boot environment.
in a way that enables authentication and attestation in a arch-agnostic manner.
Note that initrd= is problematic because it only supports loading the initrd from the same block device that the kernel image itself was loaded from, which may be overly restrictive in some cases.