Re: [PATCH] efi/libstub: measure initrd to PCR9 independent of source

[Ard Biesheuvel]

On Wed, 2 Oct 2024 at 20:25, Ilias Apalodimas
<ilias.apalodimas@xxxxxxxxxx> wrote:
>
> Hi Jeremy,
>
> [...]
>
> > >>>
> > >>> Back when we added this we intentionally left loading an initramfs
> > >>> loaded via the command line out.
> > >>> We wanted people to start using the LoadFile2 protocol instead of the
> > >>> command line option, which suffered from various issues  -- e.g could
> > >>> only be loaded if it resided in the same filesystem as the kernel and
> > >>> the bootloader had to reason about the kernel memory layout.
> > >>> I don't think measuring the command line option as well is going to
> > >>> cause any problems, but isn't it a step backward?
> > >>
> > >> Thanks for looking at this. Since no one else seems to have commented, I
> > >> will just express IMHO, that both methods are useful in differing
> > >> circumstances.
> > >>
> > >> For a heavyweight Linux aware bootloader like grub/sd-boot the
> > >> INITRD_MEDIA_GUID is obviously preferred. But, for booting strictly out
> > >> out of a pure UEFI environment or Linux unaware bootloader (ex: UEFI
> > >> shell),
> > >
> > > I am not sure I am following on the EfiShell. It has to run from an
> > > EFI firmware somehow. The two open-source options I am aware of are
> > > U-Boot and EDK2.
> > > U-Boot has full support for the LoadFile2 protocol (and the
> > > INITRD_MEDIA_GUID). In fact, you can add the initramfs/dtb/kernel
> > > triplets as your boot options, supported by the EfiBoot manager and
> > > you don't need grub/systemd boot etc.
> > >
> > > I don't think you can do that from EDK2 -- encode the initrd in a boot
> > > option, but you can configure the initramfs to be loaded via LoadFile2
> > > in OMVF via the 'initrd' shell command.
> >
> > Oh, I guess the shell is a bad example because I was unaware that there
> > was a initrd option in it now. I'm buying into the boot loader/boot
> > manager distinction, where the manager is largely unaware of the target
> > OS's specific needs (in this case, having the initrd GUID set).
>
> Yes, FWIW what was added in U-Boot needs to be aware of the
> Linux-specific GUID, but as far as the EFI BootOptions defined in the
> Boot manager, we aren't violating anything in the EFI spec. On the
> contrary, we use the _EFI_LOAD_OPTION exactly as the spec describes.
>
> >
> >
> > >
> > >> the commandline based initrd loader is a useful function.
> > >> Because, the kernel stub should continue to serve as a complete, if
> > >> minimal implementation for booting Linux out of a pure UEFI environment
> > >> without additional support infrastructure (shim/grub/etc). So, it seems
> > >> that unless there is a reason for divergent behavior it shouldn't exist.
> > >> And at the moment, the two primary linux bootloaders grub2 and sdboot
> > >> are both using the INITRD_MEDIA_GUID. Given the battering ram has been
> > >> successful, it isn't a step backward.
> > >
> > > I am not saying we shouldn't. As I said I don't think this patch
> > > breaks anything. I am just wondering if enhancing EDK2 to load the
> > > initramfs via LoadFile2 for more than OVMF is a better option.
> >
> > There is a separation of concerns argument here. People regularly
> > complain about firmware implementations tuned for windows, but making
> > the FW aware of this GUID is doing the same thing for Linux.
> > So, IMHO
> > that should be avoided, rather assuring the firmware is made as OS
> > agnostic as possible, and the OS specifics are moved into the OS boot
> > loader, one of which is this stub. It would make more logical sense to
> > have the stub set the GUID from built in command line defaults. To be
> > clear, i'm not suggesting that.
>
> I get the separation point but ....
> If you do it the other way around you *force* people to use specific
> OS loaders that implement OS-specific protocols. And the EFI stub is
> not the problem here nor are distros that use such loaders. However,
> vertical distros for embedded boards which don't need all the added
> complexity have a reasonable way out.
>
> Anyway, since Ard doesn't plan to deprecate initrd=, the patch is
> reasonable, I have no objections
>

I've queued this up now - thanks all.