Hi Heinrich
[...]
> > >
> > > If you don't have an environment or boot script how would
> > > update-initramfs set the path of the initrd when it is updated?
> >
> > The path isn't hardcoded in any code here is it?
> > This specifies a way for the linux stub to load the actual file. It's pretty a
> > callback to the firmware. Were the firmware will find and how it will load it
> > eventually is implementation specific.
>
> "Implementation specific" - This does not sound like anything you would
> want to have in mainline Linux, U-Boot, or EDK2.
>
And it isn't. The *only* thing that's specific to the firmware itself, is
how/where to find the file. The whole handover mechanism after
that is generic for everyone.
> >
> > >
> > > Using a UEFI variable seems to be the natural choice.
> > >
> >
> > You might as well use that to specify were you should load the file from.
> > The Loadfile2 (with the specified guid) implementation of the firmware will
> > take care of that.
> >
>
> If we have a UEFI variable, the Linux kernel can use it to find the
> handle with the file system and load initrd via the
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
>
> This way we stay within the existing UEFI specification and avoid
> anything "implementation specific" in the firmware.
Is this going to limit the directories we can place the file or not?
>
> If you want extra security, Linux can use an authenticated variable.
>
> > > >
> > > > > >
> > > > > > In the second case, we force the bootloader to duplicate knowledge about
> > > > > > the boot protocol which is already encoded in the stub, and which may be
> > > > > > subject to change over time, e.g., bootparams struct definitions, memory
> > > > > > allocation/alignment requirements for the placement of the initrd etc etc.
> > > > > > In the ARM case, it also requires the bootloader to modify the hardware
> > > > > > description provided by the firmware, as it is passed in the same file.
> > > > > > On systems where the initrd is measured after loading, it creates a time
> > > > > > window where the initrd contents might be manipulated in memory before
> > > > > > handing over to the kernel.
> > > > > >
> > > > > > Address these concerns by adding support for loading the initrd into
> > > > > > memory by invoking the EFI LoadFile2 protocol installed on a vendor
> > > > > > GUIDed device path that specifically designates a Linux initrd.
> > > > > > This addresses the above concerns, by putting the EFI stub in charge of
> > > > > > placement in memory and of passing the base and size to the kernel proper
> > > > > > (via whatever means it desires) while still leaving it up to the firmware
> > > > > > or bootloader to obtain the file contents, potentially from other file
> > > > > > systems than the one the kernel itself was loaded from. On platforms that
> > > > > > implement measured boot, it permits the firmware to take the measurement
> > > > > > right before the kernel actually consumes the contents.
> > > > >
> > > > > A firmware implementing the UEFI standard will not be aware of any
> > > > > initrd image as such an object does not exist in the standard. It was a
> > > > > wise decision that the UEFI standard is operating system agnostic
> > > > > (accomodating BSD, Linux, Windows, etc.). So the firmware (EDK2, U-Boot,
> > > > > etc.) seems to be out of scope for providing a Linux specific
> > > > > EFI_LOAD_FILE2_PROTOCOL.
> > > > >
> > > > > When booting via GRUB it will be GRUB knowing which initrd to load.
> > > >
> > > > What about booting the kernel directly?
> > > >
> > > > >
> > > > > Please, indicate which software you expect to expose the initrd related
> > > > > EFI_LOAD_FILE2_PROTOCOL.
> > > >
> > > > I have an implementation for this on U-Boot which works. The file and device are
> > > > hardcoded at the moment, but the rest of the functionality works fine. I'll
> > > > share it with you once I clean it up a bit.
> > >
> > > Using a UEFI variable for passing the intird device path to Linux does
> > > not require any change in U-Boot and is compatible with the UEFI
> > > implementations of existing hardware like the laptop on which I am
> > > writing this email.
> >
> > This still has the same issues we have now, uefi variable, kernel command line
> > or whatever, it won't be common across architectures.
>
> This would be a bad design choice by Linux. I cannot see why a UEFI
> variable should not be interpreted in a consistent way inside Linux to
> load a file via the EFI_SIMPLE_FILE_PROTOCOL.
>
> >
> > Thanks
> > /Ilias
> > >
> > > Best regards
> > >
> > > Heinrich
> > >
> > > >
> > > > > > - status = efi_load_initrd(image, ULONG_MAX,
> > > > > > - efi_get_max_initrd_addr(dram_base, *image_addr),
> > > > > > - &initrd_addr, &initrd_size);
> > > > > > + max_addr = efi_get_max_initrd_addr(dram_base, *image_addr);
> > > > > > + status = efi_load_initrd_devpath(&initrd_addr, &initrd_size, max_addr);
> > > > > > + if (status == EFI_SUCCESS)
> > > > > > + pr_efi("Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path\n");
> > > > > > + else if (status == EFI_NOT_FOUND) {
> > > > > > + status = efi_load_initrd(image, ULONG_MAX, max_addr,
> > > > > > + &initrd_addr, &initrd_size);
>
> If I delete the initrd that otherwise would be loaded by the
> EFI_LOAD_FILE2_PROTOCOL I end up with the old behavior. So where is the
> security gain provided by this patch?
If you delete the initrd, there is no initrd to load :)
Thanks
/Ilias
