Hi Ilias,
On 10/2/24 11:35 AM, Ilias Apalodimas wrote:
Hi Jeremy,
On Wed, 2 Oct 2024 at 18:37, Jeremy Linton <jeremy.linton@xxxxxxx> wrote:
Hi,
On 10/1/24 2:19 AM, Ilias Apalodimas wrote:
Thanks, Ard
On Tue, 1 Oct 2024 at 08:59, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
(cc Ilias)
On Tue, 1 Oct 2024 at 05:20, Jeremy Linton <jeremy.linton@xxxxxxx> wrote:
Currently the initrd is only measured if it can be loaded using the
INITRD_MEDIA_GUID, if we are loading it from a path provided via the
command line it is never measured. Lets move the check down a couple
lines so the measurement happens independent of the source.
Signed-off-by: Jeremy Linton <jeremy.linton@xxxxxxx>
---
drivers/firmware/efi/libstub/efi-stub-helper.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index de659f6a815f..555f84287f0b 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -621,10 +621,6 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
status = efi_load_initrd_dev_path(&initrd, hard_limit);
if (status == EFI_SUCCESS) {
efi_info("Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path\n");
- if (initrd.size > 0 &&
- efi_measure_tagged_event(initrd.base, initrd.size,
- EFISTUB_EVT_INITRD) == EFI_SUCCESS)
- efi_info("Measured initrd data into PCR 9\n");
} else if (status == EFI_NOT_FOUND) {
status = efi_load_initrd_cmdline(image, &initrd, soft_limit,
hard_limit);
@@ -637,6 +633,11 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
if (status != EFI_SUCCESS)
goto failed;
+ if (initrd.size > 0 &&
+ efi_measure_tagged_event(initrd.base, initrd.size,
+ EFISTUB_EVT_INITRD) == EFI_SUCCESS)
+ efi_info("Measured initrd data into PCR 9\n");
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).
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.
