arch-agnostic initrd loading method for EFI systems

There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM)

In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

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.

Signed-off-by Ard Biesheuvel <[email protected]>

---
  drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
  drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
  drivers/firmware/efi/libstub/efistub.h         | 12 ++++
  drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
  include/linux/efi.h                            |  1 +
  5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +12 -4

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
  	enum efi_secureboot_mode secure_boot;
  	struct screen_info *si;
  	efi_properties_table_t *prop_tbl;
+	unsigned long max_addr;
 
  	sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
  	if (!fdt_addr)
  		pr_efi("Generating empty DTB\n");
 
-	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 (status == EFI_SUCCESS)
+			pr_efi("Loaded initrd from command line option\n");
+	}
  	if (status != EFI_SUCCESS)
-		pr_efi_err("Failed initrd from command line!\n");
+		pr_efi_err("Failed to load initrd!\n");
 
  	efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +31 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
  	efi_call_proto(efi_table_attr(efi_system_table(), con_out),
  		       output_string, str);
  }
+
+static const struct {
+	struct efi_vendor_dev_path	vendor;
+	struct efi_generic_dev_path	end;
+} __packed initrd_devpath = {
+	{
+		EFI_DEV_MEDIA,
+		EFI_DEV_MEDIA_VENDOR,
+		sizeof(struct efi_vendor_dev_path),
+		LINUX_EFI_INITRD_MEDIA_GUID
+	}, {
+		EFI_DEV_END_PATH,
+		EFI_DEV_END_ENTIRE,
+		sizeof(struct efi_generic_dev_path)
+	}
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max)
+{
+	efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+	efi_device_path_protocol_t *dp;
+	efi_load_file2_protocol_t *lf2;
+	unsigned long initrd_addr;
+	unsigned long initrd_size;
+	efi_handle_t handle;
+	efi_status_t status;
+
+	if (!load_addr || !load_size)
+		return EFI_INVALID_PARAMETER;

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+	initrd_size = 0;
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, NULL);
+	if (status != EFI_BUFFER_TOO_SMALL)
+		return EFI_LOAD_ERROR;
+
+	status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, (void *)initrd_addr);
+	if (status != EFI_SUCCESS) {
+		efi_free(initrd_size, initrd_addr);
+		return status;
+	}
+
+	*load_addr = initrd_addr;
+	*load_size = initrd_size;
+	return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
  	} mixed_mode;
  };
 
+struct efi_vendor_dev_path {
+	u8		type;
+	u8		sub_type;
+	u16		length;
+	efi_guid_t	vendorguid;
+	u8		vendordata[];
+} __packed;
+
  void efi_pci_disable_bridge_busmaster(void);
 
  typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
  			     unsigned long *load_addr,
  			     unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max);
+
  #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
  	if (status != EFI_SUCCESS)
  		goto fail2;
 
-	status = efi_load_initrd(image, hdr->initrd_addr_max,
-				 above4g ? ULONG_MAX : hdr->initrd_addr_max,
-				 &ramdisk_addr, &ramdisk_size);
+	/*
+	 * The initrd loaded from the Linux initrd vendor device
+	 * path should take precedence, as we don't want the
+	 * [unverified] command line to override the initrd
+	 * supplied by the [potentially verified] firmware.
+	 */
+	status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max);
+	if (status == EFI_NOT_FOUND)
+		status = efi_load_initrd(image, hdr->initrd_addr_max,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max,
+					 &ramdisk_addr, &ramdisk_size);
  	if (status != EFI_SUCCESS)
  		goto fail2;
  	hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
  			 ((u64)boot_params->ext_cmd_line_ptr << 32));
  	efi_parse_options((char *)cmdline_paddr);
 
+	if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+		unsigned long max = hdr->initrd_addr_max;
+		unsigned long addr, size;
+
+		if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+			max = ULONG_MAX;
+
+		status = efi_load_initrd_devpath(&addr, &size, max);
+		if (status == EFI_SUCCESS) {
+			hdr->ramdisk_image		= (u32)addr;
+			hdr->ramdisk_size 		= (u32)size;
+			boot_params->ext_ramdisk_image	= (u64)addr >> 32;
+			boot_params->ext_ramdisk_size 	= (u64)size >> 32;
+		} else if (status != EFI_NOT_FOUND) {
+			efi_printk("efi_load_initrd_devpath() failed!\n");
+			goto fail;
+		}
+	}
+
  	/*
  	 * If the boot loader gave us a value for secure_boot then we use that,
  	 * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
  #define LINUX_EFI_TPM_EVENT_LOG_GUID		EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
  #define LINUX_EFI_TPM_FINAL_LOG_GUID		EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
  #define LINUX_EFI_MEMRESERVE_TABLE_GUID		EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID		EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
  /* OEM GUIDs */
  #define DELLEMC_EFI_RCI2_TABLE_GUID		EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 3 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

Quoted 11 lines

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.

Quoted 10 lines

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.

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

Quoted 84 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
  drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
  drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
  drivers/firmware/efi/libstub/efistub.h         | 12 ++++
  drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
  include/linux/efi.h                            |  1 +
  5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +12 -4

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
  	enum efi_secureboot_mode secure_boot;
  	struct screen_info *si;
  	efi_properties_table_t *prop_tbl;
+	unsigned long max_addr;
 
  	sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
  	if (!fdt_addr)
  		pr_efi("Generating empty DTB\n");
 
-	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 (status == EFI_SUCCESS)
+			pr_efi("Loaded initrd from command line option\n");
+	}
  	if (status != EFI_SUCCESS)
-		pr_efi_err("Failed initrd from command line!\n");
+		pr_efi_err("Failed to load initrd!\n");
 
  	efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +31 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
  	efi_call_proto(efi_table_attr(efi_system_table(), con_out),
  		       output_string, str);
  }
+
+static const struct {
+	struct efi_vendor_dev_path	vendor;
+	struct efi_generic_dev_path	end;
+} __packed initrd_devpath = {
+	{
+		EFI_DEV_MEDIA,
+		EFI_DEV_MEDIA_VENDOR,
+		sizeof(struct efi_vendor_dev_path),
+		LINUX_EFI_INITRD_MEDIA_GUID
+	}, {
+		EFI_DEV_END_PATH,
+		EFI_DEV_END_ENTIRE,
+		sizeof(struct efi_generic_dev_path)
+	}
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max)
+{
+	efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+	efi_device_path_protocol_t *dp;
+	efi_load_file2_protocol_t *lf2;
+	unsigned long initrd_addr;
+	unsigned long initrd_size;
+	efi_handle_t handle;
+	efi_status_t status;
+
+	if (!load_addr || !load_size)
+		return EFI_INVALID_PARAMETER;

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 10 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +10 -0

+
+	dp = (efi_device_path_protocol_t *)&initrd_devpath;
+	status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,
+			     (void **)&lf2);
+	if (status != EFI_SUCCESS)
+		return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Best regards

Heinrich

Quoted 119 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+	initrd_size = 0;
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, NULL);
+	if (status != EFI_BUFFER_TOO_SMALL)
+		return EFI_LOAD_ERROR;
+
+	status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, (void *)initrd_addr);
+	if (status != EFI_SUCCESS) {
+		efi_free(initrd_size, initrd_addr);
+		return status;
+	}
+
+	*load_addr = initrd_addr;
+	*load_size = initrd_size;
+	return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
  	} mixed_mode;
  };
 
+struct efi_vendor_dev_path {
+	u8		type;
+	u8		sub_type;
+	u16		length;
+	efi_guid_t	vendorguid;
+	u8		vendordata[];
+} __packed;
+
  void efi_pci_disable_bridge_busmaster(void);
 
  typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
  			     unsigned long *load_addr,
  			     unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max);
+
  #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
  	if (status != EFI_SUCCESS)
  		goto fail2;
 
-	status = efi_load_initrd(image, hdr->initrd_addr_max,
-				 above4g ? ULONG_MAX : hdr->initrd_addr_max,
-				 &ramdisk_addr, &ramdisk_size);
+	/*
+	 * The initrd loaded from the Linux initrd vendor device
+	 * path should take precedence, as we don't want the
+	 * [unverified] command line to override the initrd
+	 * supplied by the [potentially verified] firmware.
+	 */
+	status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max);
+	if (status == EFI_NOT_FOUND)
+		status = efi_load_initrd(image, hdr->initrd_addr_max,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max,
+					 &ramdisk_addr, &ramdisk_size);
  	if (status != EFI_SUCCESS)
  		goto fail2;
  	hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
  			 ((u64)boot_params->ext_cmd_line_ptr << 32));
  	efi_parse_options((char *)cmdline_paddr);
 
+	if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+		unsigned long max = hdr->initrd_addr_max;
+		unsigned long addr, size;
+
+		if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+			max = ULONG_MAX;
+
+		status = efi_load_initrd_devpath(&addr, &size, max);
+		if (status == EFI_SUCCESS) {
+			hdr->ramdisk_image		= (u32)addr;
+			hdr->ramdisk_size 		= (u32)size;
+			boot_params->ext_ramdisk_image	= (u64)addr >> 32;
+			boot_params->ext_ramdisk_size 	= (u64)size >> 32;
+		} else if (status != EFI_NOT_FOUND) {
+			efi_printk("efi_load_initrd_devpath() failed!\n");
+			goto fail;
+		}
+	}
+
  	/*
  	 * If the boot loader gave us a value for secure_boot then we use that,
  	 * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
  #define LINUX_EFI_TPM_EVENT_LOG_GUID		EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
  #define LINUX_EFI_TPM_FINAL_LOG_GUID		EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
  #define LINUX_EFI_MEMRESERVE_TABLE_GUID		EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID		EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
  /* OEM GUIDs */
  #define DELLEMC_EFI_RCI2_TABLE_GUID		EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Hi Heinrich,

I actually like the approach.

On Thu, Feb 06, 2020 at 07:26:20PM +0100, Heinrich Schuchardt wrote:
[...]

Quoted 4 lines

Quoted 3 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Quoted 2 lines

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

This patch isn't supposed to protect you against a bogus initrd and I don't think it should be the bootloaders job to verify that. The kernel already has tools to do that.

Quoted 6 lines

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

The problem with parsing the kernel command line is that at the moment, different options are supported by different architectures. A quick grep for CONFIG_CMDLINE_(FORCE/OVERWRITE/EXTEND/FROM_BOOTLOADER) will give you an idea.

What you can do in U-Boot currently is not have an environment in any of the flashes and set the bootdelay to 0, in order to prevent the user from changing that command line.

Quoted 23 lines

Quoted 12 lines

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.

Quoted 10 lines

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.

Quoted 8 lines

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?

Quoted 1 line

Quoted 2 lines

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.

Quoted 6 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

Thanks
/Ilias

Quoted 236 lines

Quoted 84 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
   drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
   drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
   drivers/firmware/efi/libstub/efistub.h         | 12 ++++
   drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
   include/linux/efi.h                            |  1 +
   5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +12 -4

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
   	enum efi_secureboot_mode secure_boot;
   	struct screen_info *si;
   	efi_properties_table_t *prop_tbl;
+	unsigned long max_addr;
 
   	sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
   	if (!fdt_addr)
   		pr_efi("Generating empty DTB\n");
 
-	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 (status == EFI_SUCCESS)
+			pr_efi("Loaded initrd from command line option\n");
+	}
   	if (status != EFI_SUCCESS)
-		pr_efi_err("Failed initrd from command line!\n");
+		pr_efi_err("Failed to load initrd!\n");
 
   	efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +31 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
   	efi_call_proto(efi_table_attr(efi_system_table(), con_out),
   		       output_string, str);
   }
+
+static const struct {
+	struct efi_vendor_dev_path	vendor;
+	struct efi_generic_dev_path	end;
+} __packed initrd_devpath = {
+	{
+		EFI_DEV_MEDIA,
+		EFI_DEV_MEDIA_VENDOR,
+		sizeof(struct efi_vendor_dev_path),
+		LINUX_EFI_INITRD_MEDIA_GUID
+	}, {
+		EFI_DEV_END_PATH,
+		EFI_DEV_END_ENTIRE,
+		sizeof(struct efi_generic_dev_path)
+	}
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max)
+{
+	efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+	efi_device_path_protocol_t *dp;
+	efi_load_file2_protocol_t *lf2;
+	unsigned long initrd_addr;
+	unsigned long initrd_size;
+	efi_handle_t handle;
+	efi_status_t status;
+
+	if (!load_addr || !load_size)
+		return EFI_INVALID_PARAMETER;

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 10 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +10 -0

+
+	dp = (efi_device_path_protocol_t *)&initrd_devpath;
+	status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,
+			     (void **)&lf2);
+	if (status != EFI_SUCCESS)
+		return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Best regards

Heinrich

Quoted 119 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+	initrd_size = 0;
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, NULL);
+	if (status != EFI_BUFFER_TOO_SMALL)
+		return EFI_LOAD_ERROR;
+
+	status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, (void *)initrd_addr);
+	if (status != EFI_SUCCESS) {
+		efi_free(initrd_size, initrd_addr);
+		return status;
+	}
+
+	*load_addr = initrd_addr;
+	*load_size = initrd_size;
+	return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
   	} mixed_mode;
   };
 
+struct efi_vendor_dev_path {
+	u8		type;
+	u8		sub_type;
+	u16		length;
+	efi_guid_t	vendorguid;
+	u8		vendordata[];
+} __packed;
+
   void efi_pci_disable_bridge_busmaster(void);
 
   typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
   			     unsigned long *load_addr,
   			     unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max);
+
   #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
   	if (status != EFI_SUCCESS)
   		goto fail2;
 
-	status = efi_load_initrd(image, hdr->initrd_addr_max,
-				 above4g ? ULONG_MAX : hdr->initrd_addr_max,
-				 &ramdisk_addr, &ramdisk_size);
+	/*
+	 * The initrd loaded from the Linux initrd vendor device
+	 * path should take precedence, as we don't want the
+	 * [unverified] command line to override the initrd
+	 * supplied by the [potentially verified] firmware.
+	 */
+	status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max);
+	if (status == EFI_NOT_FOUND)
+		status = efi_load_initrd(image, hdr->initrd_addr_max,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max,
+					 &ramdisk_addr, &ramdisk_size);
   	if (status != EFI_SUCCESS)
   		goto fail2;
   	hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
   			 ((u64)boot_params->ext_cmd_line_ptr << 32));
   	efi_parse_options((char *)cmdline_paddr);
 
+	if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+		unsigned long max = hdr->initrd_addr_max;
+		unsigned long addr, size;
+
+		if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+			max = ULONG_MAX;
+
+		status = efi_load_initrd_devpath(&addr, &size, max);
+		if (status == EFI_SUCCESS) {
+			hdr->ramdisk_image		= (u32)addr;
+			hdr->ramdisk_size 		= (u32)size;
+			boot_params->ext_ramdisk_image	= (u64)addr >> 32;
+			boot_params->ext_ramdisk_size 	= (u64)size >> 32;
+		} else if (status != EFI_NOT_FOUND) {
+			efi_printk("efi_load_initrd_devpath() failed!\n");
+			goto fail;
+		}
+	}
+
   	/*
   	 * If the boot loader gave us a value for secure_boot then we use that,
   	 * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
   #define LINUX_EFI_TPM_EVENT_LOG_GUID		EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
   #define LINUX_EFI_TPM_FINAL_LOG_GUID		EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
   #define LINUX_EFI_MEMRESERVE_TABLE_GUID		EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID		EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
   /* OEM GUIDs */
   #define DELLEMC_EFI_RCI2_TABLE_GUID		EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 13 lines · Ilias Apalodimas

Hi Heinrich,

I actually like the approach.

On Thu, Feb 06, 2020 at 07:26:20PM +0100, Heinrich Schuchardt wrote:
[...]

Quoted 6 lines

Quoted 3 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

Quoted 3 lines

This patch isn't supposed to protect you against a bogus initrd and I don't think it should be the bootloaders job to verify that. The kernel already has tools to do that.

How do you expect a bootloader identify if the initrd is compatible with the kernel?

Quoted 12 lines

Quoted 7 lines

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

The problem with parsing the kernel command line is that at the moment, different options are supported by different architectures. A quick grep for CONFIG_CMDLINE_(FORCE/OVERWRITE/EXTEND/FROM_BOOTLOADER) will give you an idea.

Quoted 3 lines

What you can do in U-Boot currently is not have an environment in any of the flashes and set the bootdelay to 0, in order to prevent the user from changing that command line.

If you don't have an environment or boot script how would update-initramfs set the path of the initrd when it is updated?

Using a UEFI variable seems to be the natural choice.

Quoted 38 lines

Quoted 23 lines

Quoted 12 lines

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.

Quoted 10 lines

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.

Quoted 8 lines

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?

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

Quoted 3 lines

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.

Best regards

Heinrich

Quoted 246 lines

Quoted 6 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

Thanks
/Ilias

Quoted 236 lines

Quoted 84 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
   drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
   drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
   drivers/firmware/efi/libstub/efistub.h         | 12 ++++
   drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
   include/linux/efi.h                            |  1 +
   5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +12 -4

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
   	enum efi_secureboot_mode secure_boot;
   	struct screen_info *si;
   	efi_properties_table_t *prop_tbl;
+	unsigned long max_addr;
 
   	sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
   	if (!fdt_addr)
   		pr_efi("Generating empty DTB\n");
 
-	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 (status == EFI_SUCCESS)
+			pr_efi("Loaded initrd from command line option\n");
+	}
   	if (status != EFI_SUCCESS)
-		pr_efi_err("Failed initrd from command line!\n");
+		pr_efi_err("Failed to load initrd!\n");
 
   	efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +31 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
   	efi_call_proto(efi_table_attr(efi_system_table(), con_out),
   		       output_string, str);
   }
+
+static const struct {
+	struct efi_vendor_dev_path	vendor;
+	struct efi_generic_dev_path	end;
+} __packed initrd_devpath = {
+	{
+		EFI_DEV_MEDIA,
+		EFI_DEV_MEDIA_VENDOR,
+		sizeof(struct efi_vendor_dev_path),
+		LINUX_EFI_INITRD_MEDIA_GUID
+	}, {
+		EFI_DEV_END_PATH,
+		EFI_DEV_END_ENTIRE,
+		sizeof(struct efi_generic_dev_path)
+	}
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max)
+{
+	efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+	efi_device_path_protocol_t *dp;
+	efi_load_file2_protocol_t *lf2;
+	unsigned long initrd_addr;
+	unsigned long initrd_size;
+	efi_handle_t handle;
+	efi_status_t status;
+
+	if (!load_addr || !load_size)
+		return EFI_INVALID_PARAMETER;

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 10 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +10 -0

+
+	dp = (efi_device_path_protocol_t *)&initrd_devpath;
+	status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,
+			     (void **)&lf2);
+	if (status != EFI_SUCCESS)
+		return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Best regards

Heinrich

Quoted 119 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+	initrd_size = 0;
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, NULL);
+	if (status != EFI_BUFFER_TOO_SMALL)
+		return EFI_LOAD_ERROR;
+
+	status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, (void *)initrd_addr);
+	if (status != EFI_SUCCESS) {
+		efi_free(initrd_size, initrd_addr);
+		return status;
+	}
+
+	*load_addr = initrd_addr;
+	*load_size = initrd_size;
+	return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
   	} mixed_mode;
   };
 
+struct efi_vendor_dev_path {
+	u8		type;
+	u8		sub_type;
+	u16		length;
+	efi_guid_t	vendorguid;
+	u8		vendordata[];
+} __packed;
+
   void efi_pci_disable_bridge_busmaster(void);
 
   typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
   			     unsigned long *load_addr,
   			     unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max);
+
   #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
   	if (status != EFI_SUCCESS)
   		goto fail2;
 
-	status = efi_load_initrd(image, hdr->initrd_addr_max,
-				 above4g ? ULONG_MAX : hdr->initrd_addr_max,
-				 &ramdisk_addr, &ramdisk_size);
+	/*
+	 * The initrd loaded from the Linux initrd vendor device
+	 * path should take precedence, as we don't want the
+	 * [unverified] command line to override the initrd
+	 * supplied by the [potentially verified] firmware.
+	 */
+	status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max);
+	if (status == EFI_NOT_FOUND)
+		status = efi_load_initrd(image, hdr->initrd_addr_max,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max,
+					 &ramdisk_addr, &ramdisk_size);
   	if (status != EFI_SUCCESS)
   		goto fail2;
   	hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
   			 ((u64)boot_params->ext_cmd_line_ptr << 32));
   	efi_parse_options((char *)cmdline_paddr);
 
+	if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+		unsigned long max = hdr->initrd_addr_max;
+		unsigned long addr, size;
+
+		if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+			max = ULONG_MAX;
+
+		status = efi_load_initrd_devpath(&addr, &size, max);
+		if (status == EFI_SUCCESS) {
+			hdr->ramdisk_image		= (u32)addr;
+			hdr->ramdisk_size 		= (u32)size;
+			boot_params->ext_ramdisk_image	= (u64)addr >> 32;
+			boot_params->ext_ramdisk_size 	= (u64)size >> 32;
+		} else if (status != EFI_NOT_FOUND) {
+			efi_printk("efi_load_initrd_devpath() failed!\n");
+			goto fail;
+		}
+	}
+
   	/*
   	 * If the boot loader gave us a value for secure_boot then we use that,
   	 * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
   #define LINUX_EFI_TPM_EVENT_LOG_GUID		EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
   #define LINUX_EFI_TPM_FINAL_LOG_GUID		EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
   #define LINUX_EFI_MEMRESERVE_TABLE_GUID		EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID		EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
   /* OEM GUIDs */
   #define DELLEMC_EFI_RCI2_TABLE_GUID		EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 14 lines · Heinrich Schuchardt

Quoted 13 lines · Ilias Apalodimas

Hi Heinrich,

I actually like the approach.

On Thu, Feb 06, 2020 at 07:26:20PM +0100, Heinrich Schuchardt wrote:
[...]

Quoted 6 lines

Quoted 3 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

Quoted 6 lines

Quoted 3 lines

This patch isn't supposed to protect you against a bogus initrd and I don't think it should be the bootloaders job to verify that. The kernel already has tools to do that.

How do you expect a bootloader identify if the initrd is compatible with the kernel?

Uh? Were exactly did i say that i expect that to happen?

Quoted 16 lines

Quoted 15 lines

Quoted 7 lines

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

The problem with parsing the kernel command line is that at the moment, different options are supported by different architectures. A quick grep for CONFIG_CMDLINE_(FORCE/OVERWRITE/EXTEND/FROM_BOOTLOADER) will give you an idea.

What you can do in U-Boot currently is not have an environment in any of the flashes and set the bootdelay to 0, in order to prevent the user from changing that command line.

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 42 lines

Quoted 41 lines

Quoted 23 lines

Quoted 12 lines

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.

Quoted 10 lines

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.

Quoted 8 lines

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?

Quoted 3 lines

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.

Quoted 4 lines

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.

Thanks
/Ilias

Quoted 41 lines

Best regards

Heinrich

Quoted 36 lines

Quoted 6 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

Thanks
/Ilias

Quoted 26 lines

Quoted 26 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
    drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
    drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
    drivers/firmware/efi/libstub/efistub.h         | 12 ++++
    drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
    include/linux/efi.h                            |  1 +
    5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +1 -0

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
    	enum efi_secureboot_mode secure_boot;
    	struct screen_info *si;
    	efi_properties_table_t *prop_tbl;
+	unsigned long max_addr;
 
    	sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
    	if (!fdt_addr)
    		pr_efi("Generating empty DTB\n");
 

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

drivers/firmware/efi/libstub/arm-stub.c unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg, · line 265

Quoted 10 lines

drivers/firmware/efi/libstub/arm-stub.c +7 -3

-	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);

Quoted 201 lines

Quoted 200 lines

Quoted 200 lines

Quoted 48 lines

drivers/firmware/efi/libstub/arm-stub.c +4 -1

+		if (status == EFI_SUCCESS)
+			pr_efi("Loaded initrd from command line option\n");
+	}
    	if (status != EFI_SUCCESS)
-		pr_efi_err("Failed initrd from command line!\n");
+		pr_efi_err("Failed to load initrd!\n");
 
    	efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +31 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
    	efi_call_proto(efi_table_attr(efi_system_table(), con_out),
    		       output_string, str);
    }
+
+static const struct {
+	struct efi_vendor_dev_path	vendor;
+	struct efi_generic_dev_path	end;
+} __packed initrd_devpath = {
+	{
+		EFI_DEV_MEDIA,
+		EFI_DEV_MEDIA_VENDOR,
+		sizeof(struct efi_vendor_dev_path),
+		LINUX_EFI_INITRD_MEDIA_GUID
+	}, {
+		EFI_DEV_END_PATH,
+		EFI_DEV_END_ENTIRE,
+		sizeof(struct efi_generic_dev_path)
+	}
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max)
+{
+	efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+	efi_device_path_protocol_t *dp;
+	efi_load_file2_protocol_t *lf2;
+	unsigned long initrd_addr;
+	unsigned long initrd_size;
+	efi_handle_t handle;
+	efi_status_t status;
+
+	if (!load_addr || !load_size)
+		return EFI_INVALID_PARAMETER;

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 10 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +10 -0

+
+	dp = (efi_device_path_protocol_t *)&initrd_devpath;
+	status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,
+			     (void **)&lf2);
+	if (status != EFI_SUCCESS)
+		return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Best regards

Heinrich

Quoted 119 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+	initrd_size = 0;
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, NULL);
+	if (status != EFI_BUFFER_TOO_SMALL)
+		return EFI_LOAD_ERROR;
+
+	status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	status = efi_call_proto(lf2, load_file,
+				(efi_device_path_protocol_t *)&initrd_devpath,
+				false, &initrd_size, (void *)initrd_addr);
+	if (status != EFI_SUCCESS) {
+		efi_free(initrd_size, initrd_addr);
+		return status;
+	}
+
+	*load_addr = initrd_addr;
+	*load_size = initrd_size;
+	return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
    	} mixed_mode;
    };
 
+struct efi_vendor_dev_path {
+	u8		type;
+	u8		sub_type;
+	u16		length;
+	efi_guid_t	vendorguid;
+	u8		vendordata[];
+} __packed;
+
    void efi_pci_disable_bridge_busmaster(void);
 
    typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
    			     unsigned long *load_addr,
    			     unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max);
+
    #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
    	if (status != EFI_SUCCESS)
    		goto fail2;
 
-	status = efi_load_initrd(image, hdr->initrd_addr_max,
-				 above4g ? ULONG_MAX : hdr->initrd_addr_max,
-				 &ramdisk_addr, &ramdisk_size);
+	/*
+	 * The initrd loaded from the Linux initrd vendor device
+	 * path should take precedence, as we don't want the
+	 * [unverified] command line to override the initrd
+	 * supplied by the [potentially verified] firmware.
+	 */
+	status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max);
+	if (status == EFI_NOT_FOUND)
+		status = efi_load_initrd(image, hdr->initrd_addr_max,
+					 above4g ? ULONG_MAX
+						 : hdr->initrd_addr_max,
+					 &ramdisk_addr, &ramdisk_size);
    	if (status != EFI_SUCCESS)
    		goto fail2;
    	hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
    			 ((u64)boot_params->ext_cmd_line_ptr << 32));
    	efi_parse_options((char *)cmdline_paddr);
 
+	if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+		unsigned long max = hdr->initrd_addr_max;
+		unsigned long addr, size;
+
+		if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+			max = ULONG_MAX;
+
+		status = efi_load_initrd_devpath(&addr, &size, max);
+		if (status == EFI_SUCCESS) {
+			hdr->ramdisk_image		= (u32)addr;
+			hdr->ramdisk_size 		= (u32)size;
+			boot_params->ext_ramdisk_image	= (u64)addr >> 32;
+			boot_params->ext_ramdisk_size 	= (u64)size >> 32;
+		} else if (status != EFI_NOT_FOUND) {
+			efi_printk("efi_load_initrd_devpath() failed!\n");
+			goto fail;
+		}
+	}
+
    	/*
    	 * If the boot loader gave us a value for secure_boot then we use that,
    	 * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
    #define LINUX_EFI_TPM_EVENT_LOG_GUID		EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
    #define LINUX_EFI_TPM_FINAL_LOG_GUID		EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
    #define LINUX_EFI_MEMRESERVE_TABLE_GUID		EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID		EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
    /* OEM GUIDs */
    #define DELLEMC_EFI_RCI2_TABLE_GUID		EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 4 lines

Quoted 3 lines

If you don't have an environment or boot script how would update-initramfs set the path of the initrd when it is updated?

Quoted 4 lines

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.

Quoted 9 lines

Quoted 4 lines

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.

If you want extra security, Linux can use an authenticated variable.

Quoted 42 lines

Quoted 42 lines

Quoted 41 lines

Quoted 23 lines

Quoted 12 lines

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.

Quoted 10 lines

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.

Quoted 8 lines

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?

Quoted 3 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 9 lines

Thanks
/Ilias

Quoted 6 lines

Best regards

Heinrich

Quoted 1 line

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

drivers/firmware/efi/libstub/arm-stub.c unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg, · line 265

Quoted 10 lines

drivers/firmware/efi/libstub/arm-stub.c +7 -3

-	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?

Quoted 8 lines · Ard Biesheuvel

There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM)

Quoted 2 lines

In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted

Hello Ard,

"same file system" is not a limitation of using a command line parameter. Any device path can be passed as a string.

Quoted 3 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

Quoted 11 lines

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.

Quoted 10 lines

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.

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

Quoted 91 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
  drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
  drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
  drivers/firmware/efi/libstub/efistub.h         | 12 ++++
  drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
  include/linux/efi.h                            |  1 +
  5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +12 -4

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
      enum efi_secureboot_mode secure_boot;
      struct screen_info *si;
      efi_properties_table_t *prop_tbl;
+     unsigned long max_addr;
 
      sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
      if (!fdt_addr)
              pr_efi("Generating empty DTB\n");
 
-     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 (status == EFI_SUCCESS)
+                     pr_efi("Loaded initrd from command line option\n");
+     }
      if (status != EFI_SUCCESS)
-             pr_efi_err("Failed initrd from command line!\n");
+             pr_efi_err("Failed to load initrd!\n");
 
      efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +38 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
      efi_call_proto(efi_table_attr(efi_system_table(), con_out),
                     output_string, str);
  }
+
+static const struct {
+     struct efi_vendor_dev_path      vendor;
+     struct efi_generic_dev_path     end;
+} __packed initrd_devpath = {
+     {
+             EFI_DEV_MEDIA,
+             EFI_DEV_MEDIA_VENDOR,
+             sizeof(struct efi_vendor_dev_path),
+             LINUX_EFI_INITRD_MEDIA_GUID
+     }, {
+             EFI_DEV_END_PATH,
+             EFI_DEV_END_ENTIRE,
+             sizeof(struct efi_generic_dev_path)
+     }
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max)
+{
+     efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+     efi_device_path_protocol_t *dp;
+     efi_load_file2_protocol_t *lf2;
+     unsigned long initrd_addr;
+     unsigned long initrd_size;
+     efi_handle_t handle;
+     efi_status_t status;
+
+     if (!load_addr || !load_size)
+             return EFI_INVALID_PARAMETER;
+
+     dp = (efi_device_path_protocol_t *)&initrd_devpath;
+     status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 3 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +3 -0

+                          (void **)&lf2);
+     if (status != EFI_SUCCESS)
+             return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Quoted 120 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+     initrd_size = 0;
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, NULL);
+     if (status != EFI_BUFFER_TOO_SMALL)
+             return EFI_LOAD_ERROR;
+
+     status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, (void *)initrd_addr);
+     if (status != EFI_SUCCESS) {
+             efi_free(initrd_size, initrd_addr);
+             return status;
+     }
+
+     *load_addr = initrd_addr;
+     *load_size = initrd_size;
+     return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
      } mixed_mode;
  };
 
+struct efi_vendor_dev_path {
+     u8              type;
+     u8              sub_type;
+     u16             length;
+     efi_guid_t      vendorguid;
+     u8              vendordata[];
+} __packed;
+
  void efi_pci_disable_bridge_busmaster(void);
 
  typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
                           unsigned long *load_addr,
                           unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max);
+
  #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
      if (status != EFI_SUCCESS)
              goto fail2;
 
-     status = efi_load_initrd(image, hdr->initrd_addr_max,
-                              above4g ? ULONG_MAX : hdr->initrd_addr_max,
-                              &ramdisk_addr, &ramdisk_size);
+     /*
+      * The initrd loaded from the Linux initrd vendor device
+      * path should take precedence, as we don't want the
+      * [unverified] command line to override the initrd
+      * supplied by the [potentially verified] firmware.
+      */
+     status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max);
+     if (status == EFI_NOT_FOUND)
+             status = efi_load_initrd(image, hdr->initrd_addr_max,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max,
+                                      &ramdisk_addr, &ramdisk_size);
      if (status != EFI_SUCCESS)
              goto fail2;
      hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
                       ((u64)boot_params->ext_cmd_line_ptr << 32));
      efi_parse_options((char *)cmdline_paddr);
 
+     if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+             unsigned long max = hdr->initrd_addr_max;
+             unsigned long addr, size;
+
+             if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+                     max = ULONG_MAX;
+
+             status = efi_load_initrd_devpath(&addr, &size, max);
+             if (status == EFI_SUCCESS) {
+                     hdr->ramdisk_image              = (u32)addr;
+                     hdr->ramdisk_size               = (u32)size;
+                     boot_params->ext_ramdisk_image  = (u64)addr >> 32;
+                     boot_params->ext_ramdisk_size   = (u64)size >> 32;
+             } else if (status != EFI_NOT_FOUND) {
+                     efi_printk("efi_load_initrd_devpath() failed!\n");
+                     goto fail;
+             }
+     }
+
      /*
       * If the boot loader gave us a value for secure_boot then we use that,
       * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
  #define LINUX_EFI_TPM_EVENT_LOG_GUID                EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
  #define LINUX_EFI_TPM_FINAL_LOG_GUID                EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
  #define LINUX_EFI_MEMRESERVE_TABLE_GUID             EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID          EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
  /* OEM GUIDs */
  #define DELLEMC_EFI_RCI2_TABLE_GUID         EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 15 lines · Heinrich Schuchardt

Quoted 10 lines · Ard Biesheuvel

There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM)

In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted

Hello Ard,

Quoted 3 lines

"same file system" is not a limitation of using a command line parameter. Any device path can be passed as a string.

What do you mean? The current implementation opens the volume via the loaded_image_info struct, and finds the file based on its filename, not on a device path. So how can it access files on other file systems?

Quoted 8 lines

Quoted 4 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

It does. It ensures that [signed] bootloader code is in charge of providing the initrd at the point during the boot where the kernel is ready to consume this data.

Quoted 4 lines

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

A signed initrd would be useful, too, but it doesn't fix the whole problem.

Linux does not support signed initrds today, and this feature permits a firmware implementation to do something very similar, i.e., it permits the bootloader to perform the verification as it is passed to the kernel.

Quoted 24 lines

Quoted 13 lines

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.

Quoted 10 lines

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.

Quoted 7 lines

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.

You know we are currently patching bootparams struct and DTs to provide the initrd information, right? And we have code that knows about low/high memory limits, alignment, etc, that is different per architecture.

Quoted 2 lines

When booting via GRUB it will be GRUB knowing which initrd to load.

Exactly, which is why GRUB will implement this protocol. That way, it does not have to touch the DT at all, or create a bootparams struct from setup data and inspect the various flags about placement, alignment, preferred addresses, etc.

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

Quoted 26 lines

Quoted 26 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
   drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
   drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
   drivers/firmware/efi/libstub/efistub.h         | 12 ++++
   drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
   include/linux/efi.h                            |  1 +
   5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +1 -0

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
       enum efi_secureboot_mode secure_boot;
       struct screen_info *si;
       efi_properties_table_t *prop_tbl;
+     unsigned long max_addr;
 
       sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
       if (!fdt_addr)
               pr_efi("Generating empty DTB\n");
 

Quoted 5 lines

Quoted 5 lines

drivers/firmware/efi/libstub/arm-stub.c +2 -3

-     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);

Quoted 8 lines

drivers/firmware/efi/libstub/arm-stub.c unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg, · line 268

Quoted 8 lines

drivers/firmware/efi/libstub/arm-stub.c +8 -0

+     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 (status == EFI_SUCCESS)
+                     pr_efi("Loaded initrd from command line option\n");
+     }

Quoted 52 lines

Quoted 52 lines

drivers/firmware/efi/libstub/arm-stub.c +1 -1

       if (status != EFI_SUCCESS)
-             pr_efi_err("Failed initrd from command line!\n");
+             pr_efi_err("Failed to load initrd!\n");
 
       efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +38 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
       efi_call_proto(efi_table_attr(efi_system_table(), con_out),
                      output_string, str);
   }
+
+static const struct {
+     struct efi_vendor_dev_path      vendor;
+     struct efi_generic_dev_path     end;
+} __packed initrd_devpath = {
+     {
+             EFI_DEV_MEDIA,
+             EFI_DEV_MEDIA_VENDOR,
+             sizeof(struct efi_vendor_dev_path),
+             LINUX_EFI_INITRD_MEDIA_GUID
+     }, {
+             EFI_DEV_END_PATH,
+             EFI_DEV_END_ENTIRE,
+             sizeof(struct efi_generic_dev_path)
+     }
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max)
+{
+     efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+     efi_device_path_protocol_t *dp;
+     efi_load_file2_protocol_t *lf2;
+     unsigned long initrd_addr;
+     unsigned long initrd_size;
+     efi_handle_t handle;
+     efi_status_t status;
+
+     if (!load_addr || !load_size)
+             return EFI_INVALID_PARAMETER;
+
+     dp = (efi_device_path_protocol_t *)&initrd_devpath;
+     status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,

Quoted 9 lines

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 3 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +3 -0

+                          (void **)&lf2);
+     if (status != EFI_SUCCESS)
+             return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

Exactly.

Quoted 3 lines

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

How do I distinguish the initrd from other EFI_LOAD_FILE2_PROTOCOL instances? For instance, PCI option ROMs are also exposed as EFI_LOAD_FILE2_PROTOCOL.

Quoted 10 lines

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Yes, that is a good point. I will work on factoring out the generic parts and share them.

Thanks for the review,
Ard.

Quoted 121 lines

Quoted 120 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+     initrd_size = 0;
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, NULL);
+     if (status != EFI_BUFFER_TOO_SMALL)
+             return EFI_LOAD_ERROR;
+
+     status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, (void *)initrd_addr);
+     if (status != EFI_SUCCESS) {
+             efi_free(initrd_size, initrd_addr);
+             return status;
+     }
+
+     *load_addr = initrd_addr;
+     *load_size = initrd_size;
+     return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
       } mixed_mode;
   };
 
+struct efi_vendor_dev_path {
+     u8              type;
+     u8              sub_type;
+     u16             length;
+     efi_guid_t      vendorguid;
+     u8              vendordata[];
+} __packed;
+
   void efi_pci_disable_bridge_busmaster(void);
 
   typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
                            unsigned long *load_addr,
                            unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max);
+
   #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
       if (status != EFI_SUCCESS)
               goto fail2;
 
-     status = efi_load_initrd(image, hdr->initrd_addr_max,
-                              above4g ? ULONG_MAX : hdr->initrd_addr_max,
-                              &ramdisk_addr, &ramdisk_size);
+     /*
+      * The initrd loaded from the Linux initrd vendor device
+      * path should take precedence, as we don't want the
+      * [unverified] command line to override the initrd
+      * supplied by the [potentially verified] firmware.
+      */
+     status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max);
+     if (status == EFI_NOT_FOUND)
+             status = efi_load_initrd(image, hdr->initrd_addr_max,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max,
+                                      &ramdisk_addr, &ramdisk_size);
       if (status != EFI_SUCCESS)
               goto fail2;
       hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
                        ((u64)boot_params->ext_cmd_line_ptr << 32));
       efi_parse_options((char *)cmdline_paddr);
 
+     if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+             unsigned long max = hdr->initrd_addr_max;
+             unsigned long addr, size;
+
+             if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+                     max = ULONG_MAX;
+
+             status = efi_load_initrd_devpath(&addr, &size, max);
+             if (status == EFI_SUCCESS) {
+                     hdr->ramdisk_image              = (u32)addr;
+                     hdr->ramdisk_size               = (u32)size;
+                     boot_params->ext_ramdisk_image  = (u64)addr >> 32;
+                     boot_params->ext_ramdisk_size   = (u64)size >> 32;
+             } else if (status != EFI_NOT_FOUND) {
+                     efi_printk("efi_load_initrd_devpath() failed!\n");
+                     goto fail;
+             }
+     }
+
       /*
        * If the boot loader gave us a value for secure_boot then we use that,
        * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
   #define LINUX_EFI_TPM_EVENT_LOG_GUID                EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
   #define LINUX_EFI_TPM_FINAL_LOG_GUID                EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
   #define LINUX_EFI_MEMRESERVE_TABLE_GUID             EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID          EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
   /* OEM GUIDs */
   #define DELLEMC_EFI_RCI2_TABLE_GUID         EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 16 lines · Ard Biesheuvel

Quoted 15 lines · Heinrich Schuchardt

Quoted 10 lines · Ard Biesheuvel

There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM)

In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted

Hello Ard,

Quoted 9 lines

Quoted 3 lines

"same file system" is not a limitation of using a command line parameter. Any device path can be passed as a string.

What do you mean? The current implementation opens the volume via the loaded_image_info struct, and finds the file based on its filename, not on a device path. So how can it access files on other file systems?

I talked aobut the information can be transmitted in a parameter not about the restrictions the current Linux command line implementation has.

If you would pass a complete device path as parameter, you could use the UEFI API to find the device with block file system and use the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to load the file.

Quoted 18 lines

Quoted 8 lines

Quoted 4 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

It does. It ensures that [signed] bootloader code is in charge of providing the initrd at the point during the boot where the kernel is ready to consume this data.

Quoted 4 lines

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

Quoted 6 lines

A signed initrd would be useful, too, but it doesn't fix the whole problem.

Linux does not support signed initrds today, and this feature permits a firmware implementation to do something very similar, i.e., it permits the bootloader to perform the verification as it is passed to the kernel.

One source of changed initrds is update-initramfs called in an operating system update process.

How shall a bootloader verify the new initrd if we do not define what a signed initrd looks like?

Would a bootloader be in a better position to verify an intird then Linux which already has code for file verification used when loading modules?

Quoted 59 lines

Quoted 24 lines

Quoted 13 lines

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.

Quoted 10 lines

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.

Quoted 7 lines

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.

You know we are currently patching bootparams struct and DTs to provide the initrd information, right? And we have code that knows about low/high memory limits, alignment, etc, that is different per architecture.

Quoted 2 lines

When booting via GRUB it will be GRUB knowing which initrd to load.

Exactly, which is why GRUB will implement this protocol. That way, it does not have to touch the DT at all, or create a bootparams struct from setup data and inspect the various flags about placement, alignment, preferred addresses, etc.

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

Quoted 6 lines

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

I would not have a problem if this would only touch GRUB. But if listen to Ilias we are replacing one implementation in Linux by one in GRUB and one in U-Boot and one in EDK2 and one in any other firmware.

Quoted 6 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

At least on my Debian system it is the operating system creating initrd and defining which initrd matches which kernel. GRUB simply assumes that files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

The chain of trust would not be broken if the kernel were responsible for loading the initrd and for checking if it matches the kernel. Linux already does this for the kernel modules in initrd.

Quoted 5 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same code in GRUB, U-Boot, EDK2, etc.

As said Linux updates the initrd often. If that file is not signed by Linux in a well defined way, do not expect any security at all.

If Linux does not tell which kernel matches which initrd, how should U-Boot know? - How do you plan to transfer this piece of information?

Quoted 35 lines

Quoted 35 lines

Quoted 35 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
   drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
   drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
   drivers/firmware/efi/libstub/efistub.h         | 12 ++++
   drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
   include/linux/efi.h                            |  1 +
   5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +7 -3

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
       enum efi_secureboot_mode secure_boot;
       struct screen_info *si;
       efi_properties_table_t *prop_tbl;
+     unsigned long max_addr;
 
       sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
       if (!fdt_addr)
               pr_efi("Generating empty DTB\n");
 
-     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,

Quoted 4 lines

Quoted 4 lines

drivers/firmware/efi/libstub/arm-stub.c unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg, · line 268

Quoted 4 lines

drivers/firmware/efi/libstub/arm-stub.c +4 -0

+                                      &initrd_addr, &initrd_size);
+             if (status == EFI_SUCCESS)
+                     pr_efi("Loaded initrd from command line option\n");
+     }

As already mentioned in another mail: If the initrd intended to be loaded by the the EFI_LOAD_FILE2_PROTOCOL, you fall back to the old behavior. So the security is not increased by this patch.

Quoted 64 lines

Quoted 52 lines

Quoted 52 lines

drivers/firmware/efi/libstub/arm-stub.c +1 -1

       if (status != EFI_SUCCESS)
-             pr_efi_err("Failed initrd from command line!\n");
+             pr_efi_err("Failed to load initrd!\n");
 
       efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +38 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
       efi_call_proto(efi_table_attr(efi_system_table(), con_out),
                      output_string, str);
   }
+
+static const struct {
+     struct efi_vendor_dev_path      vendor;
+     struct efi_generic_dev_path     end;
+} __packed initrd_devpath = {
+     {
+             EFI_DEV_MEDIA,
+             EFI_DEV_MEDIA_VENDOR,
+             sizeof(struct efi_vendor_dev_path),
+             LINUX_EFI_INITRD_MEDIA_GUID
+     }, {
+             EFI_DEV_END_PATH,
+             EFI_DEV_END_ENTIRE,
+             sizeof(struct efi_generic_dev_path)
+     }
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max)
+{
+     efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+     efi_device_path_protocol_t *dp;
+     efi_load_file2_protocol_t *lf2;
+     unsigned long initrd_addr;
+     unsigned long initrd_size;
+     efi_handle_t handle;
+     efi_status_t status;
+
+     if (!load_addr || !load_size)
+             return EFI_INVALID_PARAMETER;
+
+     dp = (efi_device_path_protocol_t *)&initrd_devpath;
+     status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,

Quoted 9 lines

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 3 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +3 -0

+                          (void **)&lf2);
+     if (status != EFI_SUCCESS)
+             return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

Exactly.

Quoted 7 lines

Quoted 3 lines

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

How do I distinguish the initrd from other EFI_LOAD_FILE2_PROTOCOL instances? For instance, PCI option ROMs are also exposed as EFI_LOAD_FILE2_PROTOCOL.

These would respond with EFI_NOT_FOUND. The advantage of looping over all instances could be that the same handle could be used to provide multiple files. But how this is implemented is the least of my worries.

Best regards

Heinrich

Quoted 141 lines

Quoted 10 lines

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Yes, that is a good point. I will work on factoring out the generic parts and share them.

Thanks for the review,
Ard.

Quoted 121 lines

Quoted 120 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+     initrd_size = 0;
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, NULL);
+     if (status != EFI_BUFFER_TOO_SMALL)
+             return EFI_LOAD_ERROR;
+
+     status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, (void *)initrd_addr);
+     if (status != EFI_SUCCESS) {
+             efi_free(initrd_size, initrd_addr);
+             return status;
+     }
+
+     *load_addr = initrd_addr;
+     *load_size = initrd_size;
+     return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
       } mixed_mode;
   };
 
+struct efi_vendor_dev_path {
+     u8              type;
+     u8              sub_type;
+     u16             length;
+     efi_guid_t      vendorguid;
+     u8              vendordata[];
+} __packed;
+
   void efi_pci_disable_bridge_busmaster(void);
 
   typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
                            unsigned long *load_addr,
                            unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max);
+
   #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
       if (status != EFI_SUCCESS)
               goto fail2;
 
-     status = efi_load_initrd(image, hdr->initrd_addr_max,
-                              above4g ? ULONG_MAX : hdr->initrd_addr_max,
-                              &ramdisk_addr, &ramdisk_size);
+     /*
+      * The initrd loaded from the Linux initrd vendor device
+      * path should take precedence, as we don't want the
+      * [unverified] command line to override the initrd
+      * supplied by the [potentially verified] firmware.
+      */
+     status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max);
+     if (status == EFI_NOT_FOUND)
+             status = efi_load_initrd(image, hdr->initrd_addr_max,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max,
+                                      &ramdisk_addr, &ramdisk_size);
       if (status != EFI_SUCCESS)
               goto fail2;
       hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
                        ((u64)boot_params->ext_cmd_line_ptr << 32));
       efi_parse_options((char *)cmdline_paddr);
 
+     if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+             unsigned long max = hdr->initrd_addr_max;
+             unsigned long addr, size;
+
+             if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+                     max = ULONG_MAX;
+
+             status = efi_load_initrd_devpath(&addr, &size, max);
+             if (status == EFI_SUCCESS) {
+                     hdr->ramdisk_image              = (u32)addr;
+                     hdr->ramdisk_size               = (u32)size;
+                     boot_params->ext_ramdisk_image  = (u64)addr >> 32;
+                     boot_params->ext_ramdisk_size   = (u64)size >> 32;
+             } else if (status != EFI_NOT_FOUND) {
+                     efi_printk("efi_load_initrd_devpath() failed!\n");
+                     goto fail;
+             }
+     }
+
       /*
        * If the boot loader gave us a value for secure_boot then we use that,
        * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
   #define LINUX_EFI_TPM_EVENT_LOG_GUID                EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
   #define LINUX_EFI_TPM_FINAL_LOG_GUID                EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
   #define LINUX_EFI_MEMRESERVE_TABLE_GUID             EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID          EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
   /* OEM GUIDs */
   #define DELLEMC_EFI_RCI2_TABLE_GUID         EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 28 lines · Heinrich Schuchardt

Quoted 16 lines · Ard Biesheuvel

Quoted 15 lines · Heinrich Schuchardt

Quoted 10 lines · Ard Biesheuvel

There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM)

In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted

Hello Ard,

Quoted 9 lines

Quoted 3 lines

"same file system" is not a limitation of using a command line parameter. Any device path can be passed as a string.

What do you mean? The current implementation opens the volume via the loaded_image_info struct, and finds the file based on its filename, not on a device path. So how can it access files on other file systems?

Quoted 7 lines

I talked aobut the information can be transmitted in a parameter not about the restrictions the current Linux command line implementation has.

If you would pass a complete device path as parameter, you could use the UEFI API to find the device with block file system and use the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to load the file.

Yes, but that still requires the bootloader to expose the file system via EFI protocols, and it requires some degree of trust in the contents of the command line. The command line in Linux is a bit hairy in any case, but allowing it to override the very first thing that gets executed is something we should try to avoid.

Quoted 25 lines

Quoted 18 lines

Quoted 8 lines

Quoted 4 lines

boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

Not relying on the command line for finding the initrd image does not secure the integrity and the validity of the initrd image.

It does. It ensures that [signed] bootloader code is in charge of providing the initrd at the point during the boot where the kernel is ready to consume this data.

Quoted 4 lines

A signature on the initrd image could solve the security problem you describe. It would not require non-Linux software to be changed, and would provide much better security.

Quoted 6 lines

A signed initrd would be useful, too, but it doesn't fix the whole problem.

Linux does not support signed initrds today, and this feature permits a firmware implementation to do something very similar, i.e., it permits the bootloader to perform the verification as it is passed to the kernel.

Quoted 6 lines

One source of changed initrds is update-initramfs called in an operating system update process.

How shall a bootloader verify the new initrd if we do not define what a signed initrd looks like?

Initrd signing is probably not feasible for this reason. But measuring it, and using PCR value prediction to reseal keys when they change is something we should be able to do in this context.

For that reason, it would be preferable for the command line not to have control over whether or not an initrd gets loaded, and which.

Quoted 4 lines

Would a bootloader be in a better position to verify an intird then Linux which already has code for file verification used when loading modules?

The bootloader already has code for file verification when loading the kernel, so I fail to see your point here.

Quoted 66 lines

Quoted 65 lines

Quoted 24 lines

Quoted 13 lines

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.

Quoted 10 lines

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.

Quoted 7 lines

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.

You know we are currently patching bootparams struct and DTs to provide the initrd information, right? And we have code that knows about low/high memory limits, alignment, etc, that is different per architecture.

Quoted 2 lines

When booting via GRUB it will be GRUB knowing which initrd to load.

Exactly, which is why GRUB will implement this protocol. That way, it does not have to touch the DT at all, or create a bootparams struct from setup data and inspect the various flags about placement, alignment, preferred addresses, etc.

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Quoted 2 lines

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

No. I am not interested in EFI_FILE_PROTOCOL, only in LoadFile2, which is a single method that needs to be implemented.

Quoted 5 lines

I would not have a problem if this would only touch GRUB. But if listen to Ilias we are replacing one implementation in Linux by one in GRUB and one in U-Boot and one in EDK2 and one in any other firmware.

If u-boot will be used to boot RISC-V in EFI mode without GRUB, then I expect that we will need an implementation of this in u-boot.

Quoted 8 lines

Quoted 7 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

Quoted 9 lines

At least on my Debian system it is the operating system creating initrd and defining which initrd matches which kernel. GRUB simply assumes that files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

The chain of trust would not be broken if the kernel were responsible for loading the initrd and for checking if it matches the kernel. Linux already does this for the kernel modules in initrd.

We can still sign the initrd and Linux can verify the signature. What I am after is an interface that does not require the initrd to originate from a EFI file system protocol, and which doesn't require the loaded initrd to sit in memory for an unspecified amount of time and its information passed via DT properties or bootparams structs.

So invoking EFI_FILE_PROTOCOL directly is not going to work, regardless of whether we get the devicepath from the command line or from a EFI variable.

Quoted 14 lines

Quoted 6 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same code in GRUB, U-Boot, EDK2, etc.

Quoted 3 lines

As said Linux updates the initrd often. If that file is not signed by Linux in a well defined way, do not expect any security at all.

It is not only about security. The primary goal is to remove the need for arch specific knowledge in the firmware about DT, bootparams and initrd allocation policies without being forced to load the initrd from a filesystem that is exposed via a EFI protocol.

Quoted 4 lines

If Linux does not tell which kernel matches which initrd, how should U-Boot know? - How do you plan to transfer this piece of information?

How does u-boot know today? If you can tell it which initrd to load into memory, why is it difficult to put that same data into a buffer in response to a protocol invocation?

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Quoted 36 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
    drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
    drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
    drivers/firmware/efi/libstub/efistub.h         | 12 ++++
    drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
    include/linux/efi.h                            |  1 +
    5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +7 -3

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
        enum efi_secureboot_mode secure_boot;
        struct screen_info *si;
        efi_properties_table_t *prop_tbl;
+     unsigned long max_addr;
 
        sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
        if (!fdt_addr)
                pr_efi("Generating empty DTB\n");
 
-     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,

Quoted 9 lines

Quoted 4 lines

Quoted 4 lines

drivers/firmware/efi/libstub/arm-stub.c unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg, · line 268

Quoted 4 lines

drivers/firmware/efi/libstub/arm-stub.c +4 -0

+                                      &initrd_addr, &initrd_size);
+             if (status == EFI_SUCCESS)
+                     pr_efi("Loaded initrd from command line option\n");
+     }

As already mentioned in another mail: If the initrd intended to be loaded by the the EFI_LOAD_FILE2_PROTOCOL, you fall back to the old behavior. So the security is not increased by this patch.

If the bootloader is signed, it is justified to place a higher degree of trust in the code we run than in the [unsigned] data we pass as the command line.

Quoted 223 lines

Quoted 65 lines

Quoted 53 lines

Quoted 53 lines

drivers/firmware/efi/libstub/arm-stub.c +1 -1

        if (status != EFI_SUCCESS)
-             pr_efi_err("Failed initrd from command line!\n");
+             pr_efi_err("Failed to load initrd!\n");
 
        efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +38 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
        efi_call_proto(efi_table_attr(efi_system_table(), con_out),
                       output_string, str);
    }
+
+static const struct {
+     struct efi_vendor_dev_path      vendor;
+     struct efi_generic_dev_path     end;
+} __packed initrd_devpath = {
+     {
+             EFI_DEV_MEDIA,
+             EFI_DEV_MEDIA_VENDOR,
+             sizeof(struct efi_vendor_dev_path),
+             LINUX_EFI_INITRD_MEDIA_GUID
+     }, {
+             EFI_DEV_END_PATH,
+             EFI_DEV_END_ENTIRE,
+             sizeof(struct efi_generic_dev_path)
+     }
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max)
+{
+     efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+     efi_device_path_protocol_t *dp;
+     efi_load_file2_protocol_t *lf2;
+     unsigned long initrd_addr;
+     unsigned long initrd_size;
+     efi_handle_t handle;
+     efi_status_t status;
+
+     if (!load_addr || !load_size)
+             return EFI_INVALID_PARAMETER;
+
+     dp = (efi_device_path_protocol_t *)&initrd_devpath;
+     status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,

Quoted 9 lines

drivers/firmware/efi/libstub/efi-stub-helper.c void efi_char16_printk(efi_char16_t *str) · line 366

Quoted 3 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +3 -0

+                          (void **)&lf2);
+     if (status != EFI_SUCCESS)
+             return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

Exactly.

Quoted 7 lines

Quoted 3 lines

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

How do I distinguish the initrd from other EFI_LOAD_FILE2_PROTOCOL instances? For instance, PCI option ROMs are also exposed as EFI_LOAD_FILE2_PROTOCOL.

These would respond with EFI_NOT_FOUND. The advantage of looping over all instances could be that the same handle could be used to provide multiple files. But how this is implemented is the least of my worries.

Best regards

Heinrich

Quoted 141 lines

Quoted 10 lines

It would be worthwhile to describe the requirements on the implementation of the EFI_LOAD_FILE2_PROTOCOL in a code comment and in the documentation.

Unfortunately the documentation of UEFI has been duplicated into two files:

Documentation/arm/uefi.rst
Documentation/x86/x86_64/uefi.rst

Yes, that is a good point. I will work on factoring out the generic parts and share them.

Thanks for the review,
Ard.

Quoted 121 lines

Quoted 120 lines

drivers/firmware/efi/libstub/efi-stub-helper.c +24 -0

+
+     initrd_size = 0;
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, NULL);
+     if (status != EFI_BUFFER_TOO_SMALL)
+             return EFI_LOAD_ERROR;
+
+     status = efi_allocate_pages(initrd_size, &initrd_addr, max);
+     if (status != EFI_SUCCESS)
+             return status;
+
+     status = efi_call_proto(lf2, load_file,
+                             (efi_device_path_protocol_t *)&initrd_devpath,
+                             false, &initrd_size, (void *)initrd_addr);
+     if (status != EFI_SUCCESS) {
+             efi_free(initrd_size, initrd_addr);
+             return status;
+     }
+
+     *load_addr = initrd_addr;
+     *load_size = initrd_size;
+     return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
        } mixed_mode;
    };
 
+struct efi_vendor_dev_path {
+     u8              type;
+     u8              sub_type;
+     u16             length;
+     efi_guid_t      vendorguid;
+     u8              vendordata[];
+} __packed;
+
    void efi_pci_disable_bridge_busmaster(void);
 
    typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
                             unsigned long *load_addr,
                             unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+                                  unsigned long *load_size,
+                                  unsigned long max);
+
    #endif

drivers/firmware/efi/libstub/x86-stub.c +33 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
        if (status != EFI_SUCCESS)
                goto fail2;
 
-     status = efi_load_initrd(image, hdr->initrd_addr_max,
-                              above4g ? ULONG_MAX : hdr->initrd_addr_max,
-                              &ramdisk_addr, &ramdisk_size);
+     /*
+      * The initrd loaded from the Linux initrd vendor device
+      * path should take precedence, as we don't want the
+      * [unverified] command line to override the initrd
+      * supplied by the [potentially verified] firmware.
+      */
+     status = efi_load_initrd_devpath(&ramdisk_addr, &ramdisk_size,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max);
+     if (status == EFI_NOT_FOUND)
+             status = efi_load_initrd(image, hdr->initrd_addr_max,
+                                      above4g ? ULONG_MAX
+                                              : hdr->initrd_addr_max,
+                                      &ramdisk_addr, &ramdisk_size);
        if (status != EFI_SUCCESS)
                goto fail2;
        hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
                         ((u64)boot_params->ext_cmd_line_ptr << 32));
        efi_parse_options((char *)cmdline_paddr);
 
+     if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+             unsigned long max = hdr->initrd_addr_max;
+             unsigned long addr, size;
+
+             if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+                     max = ULONG_MAX;
+
+             status = efi_load_initrd_devpath(&addr, &size, max);
+             if (status == EFI_SUCCESS) {
+                     hdr->ramdisk_image              = (u32)addr;
+                     hdr->ramdisk_size               = (u32)size;
+                     boot_params->ext_ramdisk_image  = (u64)addr >> 32;
+                     boot_params->ext_ramdisk_size   = (u64)size >> 32;
+             } else if (status != EFI_NOT_FOUND) {
+                     efi_printk("efi_load_initrd_devpath() failed!\n");
+                     goto fail;
+             }
+     }
+
        /*
         * If the boot loader gave us a value for secure_boot then we use that,
         * otherwise we ask the BIOS.

include/linux/efi.h +1 -0

index 9ccf313fe9de..75c83c322c40 100644
@@ -353,6 +353,7 @@ void efi_native_runtime_setup(void);
    #define LINUX_EFI_TPM_EVENT_LOG_GUID                EFI_GUID(0xb7799cb0, 0xeca2, 0x4943,  0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
    #define LINUX_EFI_TPM_FINAL_LOG_GUID                EFI_GUID(0x1e2ed096, 0x30e2, 0x4254,  0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
    #define LINUX_EFI_MEMRESERVE_TABLE_GUID             EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5,  0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
+#define LINUX_EFI_INITRD_MEDIA_GUID          EFI_GUID(0x5568e427, 0x68fc, 0x4f3d,  0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68)
 
    /* OEM GUIDs */
    #define DELLEMC_EFI_RCI2_TABLE_GUID         EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)

Quoted 4 lines · Ard Biesheuvel

Quoted 3 lines · Heinrich Schuchardt

Quoted 1 line · Ard Biesheuvel

On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt <[email protected]> wrote:

Quoted 21 lines

Quoted 21 lines

Quoted 20 lines

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Quoted 5 lines

Quoted 2 lines

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

No. I am not interested in EFI_FILE_PROTOCOL, only in LoadFile2, which is a single method that needs to be implemented.

I said you move complexity because GRUB will need to use the EFI_FILE_PROTOCOL to do the job that you do not want to do in Linux.

Quoted 6 lines

Quoted 5 lines

I would not have a problem if this would only touch GRUB. But if listen to Ilias we are replacing one implementation in Linux by one in GRUB and one in U-Boot and one in EDK2 and one in any other firmware.

Quoted 2 lines

If u-boot will be used to boot RISC-V in EFI mode without GRUB, then I expect that we will need an implementation of this in u-boot.

What sets RISC-V apart? GRUB for RISC-V is available.

Quoted 24 lines

Quoted 8 lines

Quoted 7 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

Quoted 9 lines

At least on my Debian system it is the operating system creating initrd and defining which initrd matches which kernel. GRUB simply assumes that files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

The chain of trust would not be broken if the kernel were responsible for loading the initrd and for checking if it matches the kernel. Linux already does this for the kernel modules in initrd.

We can still sign the initrd and Linux can verify the signature. What I am after is an interface that does not require the initrd to originate from a EFI file system protocol, and which doesn't require the loaded initrd to sit in memory for an unspecified amount of time and its information passed via DT properties or bootparams structs.

Quoted 3 lines

So invoking EFI_FILE_PROTOCOL directly is not going to work, regardless of whether we get the devicepath from the command line or from a EFI variable.

What do you mean by "is not going to work"?

With the device path you can find the handle implementing the EFI_SIMPLE_FIL_SYSTEM_PROTOCOL.

Quoted 14 lines

Quoted 14 lines

Quoted 6 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same code in GRUB, U-Boot, EDK2, etc.

Quoted 8 lines

Quoted 3 lines

As said Linux updates the initrd often. If that file is not signed by Linux in a well defined way, do not expect any security at all.

It is not only about security. The primary goal is to remove the need for arch specific knowledge in the firmware about DT, bootparams and initrd allocation policies without being forced to load the initrd from a filesystem that is exposed via a EFI protocol.

Where are device-trees touched by this patch?

When booting via UEFI there is no need for knowledge of initrd allocation policies in U-Boot because up to now Linux or GRUB or iPXE load initrd.

Furthermore I need no knowledge of bootparams in U-Boot once we properly we support UEFI variables at runtime because grub-update will pass the command line in one of the Bootxxxx UEFI variables.

But most importantly I do not have to implement anything Linux specific in U-Boot for booting via UEFI up to now.

Your patch claims to fend off a specific threat scenario: A user puts an untrusted initrd on the disk and references it in the Linux command line.

If he is able to do so with your current bootloader (signed or not signed), he most probably will also be able to delete a good initrd from the filesystem and thus force your code into the unsafe path.

That is why I say that with the current fallback logic this patch achieves no increase in security. Of cause you could remove the fallback logic. But in this case your Linux will not boot with any legacy bootloader or firmware.

Quoted 6 lines · Heinrich Schuchardt

Quoted 4 lines · Ard Biesheuvel

Quoted 3 lines · Heinrich Schuchardt

Quoted 1 line · Ard Biesheuvel

On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt <[email protected]> wrote:

...

Quoted 36 lines

Quoted 21 lines

Quoted 21 lines

Quoted 20 lines

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Quoted 5 lines

Quoted 2 lines

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

No. I am not interested in EFI_FILE_PROTOCOL, only in LoadFile2, which is a single method that needs to be implemented.

I said you move complexity because GRUB will need to use the EFI_FILE_PROTOCOL to do the job that you do not want to do in Linux.

Quoted 6 lines

Quoted 5 lines

I would not have a problem if this would only touch GRUB. But if listen to Ilias we are replacing one implementation in Linux by one in GRUB and one in U-Boot and one in EDK2 and one in any other firmware.

Quoted 5 lines

Quoted 2 lines

If u-boot will be used to boot RISC-V in EFI mode without GRUB, then I expect that we will need an implementation of this in u-boot.

What sets RISC-V apart? GRUB for RISC-V is available.

RISC-V EFI boot is not supported yet in upstream Linux.

Quoted 63 lines

Quoted 25 lines

Quoted 9 lines

Quoted 8 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

Quoted 9 lines

At least on my Debian system it is the operating system creating initrd and defining which initrd matches which kernel. GRUB simply assumes that files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

The chain of trust would not be broken if the kernel were responsible for loading the initrd and for checking if it matches the kernel. Linux already does this for the kernel modules in initrd.

We can still sign the initrd and Linux can verify the signature. What I am after is an interface that does not require the initrd to originate from a EFI file system protocol, and which doesn't require the loaded initrd to sit in memory for an unspecified amount of time and its information passed via DT properties or bootparams structs.

Quoted 3 lines

So invoking EFI_FILE_PROTOCOL directly is not going to work, regardless of whether we get the devicepath from the command line or from a EFI variable.

What do you mean by "is not going to work"?

With the device path you can find the handle implementing the EFI_SIMPLE_FIL_SYSTEM_PROTOCOL.

Quoted 14 lines

Quoted 14 lines

Quoted 6 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same code in GRUB, U-Boot, EDK2, etc.

Quoted 8 lines

Quoted 3 lines

As said Linux updates the initrd often. If that file is not signed by Linux in a well defined way, do not expect any security at all.

It is not only about security. The primary goal is to remove the need for arch specific knowledge in the firmware about DT, bootparams and initrd allocation policies without being forced to load the initrd from a filesystem that is exposed via a EFI protocol.

Where are device-trees touched by this patch?

When booting via UEFI there is no need for knowledge of initrd allocation policies in U-Boot because up to now Linux or GRUB or iPXE load initrd.

Quoted 7 lines

Furthermore I need no knowledge of bootparams in U-Boot once we properly we support UEFI variables at runtime because grub-update will pass the command line in one of the Bootxxxx UEFI variables.

But most importantly I do not have to implement anything Linux specific in U-Boot for booting via UEFI up to now.

Adding Linux specific stuff to u-boot is arguably more appropriate than adding architecture specific stuff to EFI loaders that could otherwise be entirely generic.

...

Quoted 4 lines

Your patch claims to fend off a specific threat scenario: A user puts an untrusted initrd on the disk and references it in the Linux command line.

Quoted 9 lines

If he is able to do so with your current bootloader (signed or not signed), he most probably will also be able to delete a good initrd from the filesystem and thus force your code into the unsafe path.

That is why I say that with the current fallback logic this patch achieves no increase in security. Of cause you could remove the fallback logic. But in this case your Linux will not boot with any legacy bootloader or firmware.

If there is a better way to expose the initrd that
a) does not require the initrd to reside on a file system that is accessible via EFI protocols, and
b) does not require the loader to know about arch specific policies regarding the placement of the initrd in memory, and
c) does not leave a time window between the time that the initrd is loaded/verified/measured by the firmware and the time that the kernel gets handed the buffer

then I am happy to discuss it. This proposal is the best I could come up with to achieve the above.

Quoted 47 lines · Ard Biesheuvel

Quoted 6 lines · Heinrich Schuchardt

Quoted 4 lines · Ard Biesheuvel

Quoted 3 lines · Heinrich Schuchardt

Quoted 1 line · Ard Biesheuvel

On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt <[email protected]> wrote:

...

Quoted 39 lines

Quoted 21 lines

Quoted 21 lines

Quoted 20 lines

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Quoted 5 lines

Quoted 2 lines

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

No. I am not interested in EFI_FILE_PROTOCOL, only in LoadFile2, which is a single method that needs to be implemented.

I said you move complexity because GRUB will need to use the EFI_FILE_PROTOCOL to do the job that you do not want to do in Linux.

Quoted 8 lines

Quoted 5 lines

I would not have a problem if this would only touch GRUB. But if listen to Ilias we are replacing one implementation in Linux by one in GRUB and one in U-Boot and one in EDK2 and one in any other firmware.

If u-boot will be used to boot RISC-V in EFI mode without GRUB, then I expect that we will need an implementation of this in u-boot.

Quoted 4 lines

Quoted 2 lines

What sets RISC-V apart? GRUB for RISC-V is available.

RISC-V EFI boot is not supported yet in upstream Linux.

It is currently prepared Atish Patra of WDC.

Quoted 99 lines

Quoted 63 lines

Quoted 25 lines

Quoted 9 lines

Quoted 8 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

Quoted 9 lines

At least on my Debian system it is the operating system creating initrd and defining which initrd matches which kernel. GRUB simply assumes that files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

The chain of trust would not be broken if the kernel were responsible for loading the initrd and for checking if it matches the kernel. Linux already does this for the kernel modules in initrd.

We can still sign the initrd and Linux can verify the signature. What I am after is an interface that does not require the initrd to originate from a EFI file system protocol, and which doesn't require the loaded initrd to sit in memory for an unspecified amount of time and its information passed via DT properties or bootparams structs.

Quoted 3 lines

So invoking EFI_FILE_PROTOCOL directly is not going to work, regardless of whether we get the devicepath from the command line or from a EFI variable.

What do you mean by "is not going to work"?

With the device path you can find the handle implementing the EFI_SIMPLE_FIL_SYSTEM_PROTOCOL.

Quoted 14 lines

Quoted 14 lines

Quoted 6 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same code in GRUB, U-Boot, EDK2, etc.

Quoted 8 lines

Quoted 3 lines

As said Linux updates the initrd often. If that file is not signed by Linux in a well defined way, do not expect any security at all.

It is not only about security. The primary goal is to remove the need for arch specific knowledge in the firmware about DT, bootparams and initrd allocation policies without being forced to load the initrd from a filesystem that is exposed via a EFI protocol.

Where are device-trees touched by this patch?

When booting via UEFI there is no need for knowledge of initrd allocation policies in U-Boot because up to now Linux or GRUB or iPXE load initrd.

Quoted 7 lines

Furthermore I need no knowledge of bootparams in U-Boot once we properly we support UEFI variables at runtime because grub-update will pass the command line in one of the Bootxxxx UEFI variables.

But most importantly I do not have to implement anything Linux specific in U-Boot for booting via UEFI up to now.

Adding Linux specific stuff to u-boot is arguably more appropriate than adding architecture specific stuff to EFI loaders that could otherwise be entirely generic.

...

Quoted 4 lines

Your patch claims to fend off a specific threat scenario: A user puts an untrusted initrd on the disk and references it in the Linux command line.

Quoted 9 lines

If he is able to do so with your current bootloader (signed or not signed), he most probably will also be able to delete a good initrd from the filesystem and thus force your code into the unsafe path.

That is why I say that with the current fallback logic this patch achieves no increase in security. Of cause you could remove the fallback logic. But in this case your Linux will not boot with any legacy bootloader or firmware.

If there is a better way to expose the initrd that
a) does not require the initrd to reside on a file system that is accessible via EFI protocols, and
b) does not require the loader to know about arch specific policies regarding the placement of the initrd in memory, and
c) does not leave a time window between the time that the initrd is loaded/verified/measured by the firmware and the time that the kernel gets handed the buffer

Quoted 3 lines

then I am happy to discuss it. This proposal is the best I could come up with to achieve the above.

Hello Ard,

I think part of our different views is that we are thinking about two different use cases which both have their relevance:

If I understand you correctly, you are thinking about an embedded device where the kernel and the initrd is essentially part of the firmware provided by the device.

I am thinking of a system running a standard Linux distribution like Debian where the initrd is generated by the operating system

In both use cases verifying the initrd is of importance.

Now concerning the requirements:

a) In U-Boot all file systems on block devices can be made accessible via EFI protocols. Are you thinking about initrds that are not in a file system?

b) My suggestion to use a UEFI variable for communicating the device path would not require any arch specific policies either.

c) I proposed that the kernel does the verification. So there would be equally nothing in between loading the file and its verification. Yet responsibilities would be changed.

But possibly I missed some requirements you have in mind that I should consider.

Quoted 38 lines · Heinrich Schuchardt

Quoted 35 lines · Ard Biesheuvel

Quoted 4 lines · Heinrich Schuchardt

Quoted 3 lines · Ard Biesheuvel

Quoted 2 lines · Heinrich Schuchardt

Quoted 1 line · Ard Biesheuvel

On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt <[email protected]> wrote:

...

Quoted 29 lines

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Quoted 4 lines

Quoted 2 lines

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

No. I am not interested in EFI_FILE_PROTOCOL, only in LoadFile2, which is a single method that needs to be implemented.

I said you move complexity because GRUB will need to use the EFI_FILE_PROTOCOL to do the job that you do not want to do in Linux.

Quoted 4 lines

Quoted 4 lines

I would not have a problem if this would only touch GRUB. But if listen to Ilias we are replacing one implementation in Linux by one in GRUB and one in U-Boot and one in EDK2 and one in any other firmware.

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

If u-boot will be used to boot RISC-V in EFI mode without GRUB, then I expect that we will need an implementation of this in u-boot.

What sets RISC-V apart? GRUB for RISC-V is available.

RISC-V EFI boot is not supported yet in upstream Linux.

It is currently prepared Atish Patra of WDC.

Exactly. So it is not in the upstream yet, and I want to converge on a sane generic interface before it gets merged.

Quoted 100 lines

Quoted 85 lines

Quoted 52 lines

Quoted 20 lines

Quoted 5 lines

Quoted 5 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

Quoted 9 lines

At least on my Debian system it is the operating system creating initrd and defining which initrd matches which kernel. GRUB simply assumes that files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

The chain of trust would not be broken if the kernel were responsible for loading the initrd and for checking if it matches the kernel. Linux already does this for the kernel modules in initrd.

We can still sign the initrd and Linux can verify the signature. What I am after is an interface that does not require the initrd to originate from a EFI file system protocol, and which doesn't require the loaded initrd to sit in memory for an unspecified amount of time and its information passed via DT properties or bootparams structs.

Quoted 3 lines

So invoking EFI_FILE_PROTOCOL directly is not going to work, regardless of whether we get the devicepath from the command line or from a EFI variable.

What do you mean by "is not going to work"?

With the device path you can find the handle implementing the EFI_SIMPLE_FIL_SYSTEM_PROTOCOL.

Quoted 11 lines

Quoted 11 lines

Quoted 4 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same code in GRUB, U-Boot, EDK2, etc.

Quoted 7 lines

Quoted 3 lines

As said Linux updates the initrd often. If that file is not signed by Linux in a well defined way, do not expect any security at all.

It is not only about security. The primary goal is to remove the need for arch specific knowledge in the firmware about DT, bootparams and initrd allocation policies without being forced to load the initrd from a filesystem that is exposed via a EFI protocol.

Where are device-trees touched by this patch?

When booting via UEFI there is no need for knowledge of initrd allocation policies in U-Boot because up to now Linux or GRUB or iPXE load initrd.

Quoted 7 lines

Furthermore I need no knowledge of bootparams in U-Boot once we properly we support UEFI variables at runtime because grub-update will pass the command line in one of the Bootxxxx UEFI variables.

But most importantly I do not have to implement anything Linux specific in U-Boot for booting via UEFI up to now.

Adding Linux specific stuff to u-boot is arguably more appropriate than adding architecture specific stuff to EFI loaders that could otherwise be entirely generic.

...

Quoted 12 lines

Your patch claims to fend off a specific threat scenario: A user puts an untrusted initrd on the disk and references it in the Linux command line.

If he is able to do so with your current bootloader (signed or not signed), he most probably will also be able to delete a good initrd from the filesystem and thus force your code into the unsafe path.

That is why I say that with the current fallback logic this patch achieves no increase in security. Of cause you could remove the fallback logic. But in this case your Linux will not boot with any legacy bootloader or firmware.

If there is a better way to expose the initrd that
a) does not require the initrd to reside on a file system that is accessible via EFI protocols, and
b) does not require the loader to know about arch specific policies regarding the placement of the initrd in memory, and
c) does not leave a time window between the time that the initrd is loaded/verified/measured by the firmware and the time that the kernel gets handed the buffer

Quoted 3 lines

then I am happy to discuss it. This proposal is the best I could come up with to achieve the above.

Hello Ard,

I think part of our different views is that we are thinking about two different use cases which both have their relevance:

If I understand you correctly, you are thinking about an embedded device where the kernel and the initrd is essentially part of the firmware provided by the device.

I am thinking of a system running a standard Linux distribution like Debian where the initrd is generated by the operating system

Quoted 8 lines

In both use cases verifying the initrd is of importance.

Now concerning the requirements:

a) In U-Boot all file systems on block devices can be made accessible via EFI protocols. Are you thinking about initrds that are not in a file system?

The typical GRUB deployment keeps the core GRUB itself (or the entire thing if it is built as standalone) in the ESP, and the GRUB modules, kernel images and initrds are in /boot, which is typically not a file system that EFI understands. So in that case, initrd= does not work, which is why GRUB loads the initrd into memory directly and passes the base address and size via DT or bootparams structure.

Quoted 3 lines

b) My suggestion to use a UEFI variable for communicating the device path would not require any arch specific policies either.

Passing the EFI device path is not going to help us since the initrd may not be representable as a device path. That is the whole point, actually - this series makes the initrd representable as a device path, but in a simple way that doesn't rely on EFI_FILE_PROTOCOL but only on EFI_LOAD_FILE2_PROTOCOL, which is *much* simpler.

Quoted 8 lines

c) I proposed that the kernel does the verification. So there would be equally nothing in between loading the file and its verification. Yet responsibilities would be changed.

But possibly I missed some requirements you have in mind that I should consider.

1) The assumption that the initrd can always be loaded from a EFI device path directly does not hold.

2) Loading the initrd into memory and passing the address and size is not acceptable.

3) Having a special device path that designates the initrd specifically (which will be treated in a special way by the kernel) makes it very easy for the boot firmware to attach policy to the loading of the initrd that can be enforced right when the file is being passed into the kernel.

Putting an arbitrary device path in a EFI variable doesn't address 1), and it complicates 3), since you cannot easily distinguish whether the file load that is occurring is the EFI stub loading the initrd at boot.

Quoted 164 lines · Ard Biesheuvel

Quoted 38 lines · Heinrich Schuchardt

Quoted 35 lines · Ard Biesheuvel

Quoted 4 lines · Heinrich Schuchardt

Quoted 3 lines · Ard Biesheuvel

Quoted 2 lines · Heinrich Schuchardt

Quoted 1 line · Ard Biesheuvel

On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt <[email protected]> wrote:

...

Quoted 29 lines

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines

Using an UEFI variable for passing the initrd device path would be a leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Quoted 4 lines

Quoted 2 lines

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

No. I am not interested in EFI_FILE_PROTOCOL, only in LoadFile2, which is a single method that needs to be implemented.

I said you move complexity because GRUB will need to use the EFI_FILE_PROTOCOL to do the job that you do not want to do in Linux.

Quoted 4 lines

Quoted 4 lines

I would not have a problem if this would only touch GRUB. But if listen to Ilias we are replacing one implementation in Linux by one in GRUB and one in U-Boot and one in EDK2 and one in any other firmware.

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

If u-boot will be used to boot RISC-V in EFI mode without GRUB, then I expect that we will need an implementation of this in u-boot.

What sets RISC-V apart? GRUB for RISC-V is available.

RISC-V EFI boot is not supported yet in upstream Linux.

It is currently prepared Atish Patra of WDC.

Exactly. So it is not in the upstream yet, and I want to converge on a sane generic interface before it gets merged.

Quoted 100 lines

Quoted 85 lines

Quoted 52 lines

Quoted 20 lines

Quoted 5 lines

Quoted 5 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that the bootloader or firmware intended it to load, and having a piece of simple [signed] code that implements this is the easiest way to achieve that.

Quoted 9 lines

At least on my Debian system it is the operating system creating initrd and defining which initrd matches which kernel. GRUB simply assumes that files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

The chain of trust would not be broken if the kernel were responsible for loading the initrd and for checking if it matches the kernel. Linux already does this for the kernel modules in initrd.

We can still sign the initrd and Linux can verify the signature. What I am after is an interface that does not require the initrd to originate from a EFI file system protocol, and which doesn't require the loaded initrd to sit in memory for an unspecified amount of time and its information passed via DT properties or bootparams structs.

Quoted 3 lines

So invoking EFI_FILE_PROTOCOL directly is not going to work, regardless of whether we get the devicepath from the command line or from a EFI variable.

What do you mean by "is not going to work"?

With the device path you can find the handle implementing the EFI_SIMPLE_FIL_SYSTEM_PROTOCOL.

Quoted 11 lines

Quoted 11 lines

Quoted 4 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same code in GRUB, U-Boot, EDK2, etc.

Quoted 7 lines

Quoted 3 lines

As said Linux updates the initrd often. If that file is not signed by Linux in a well defined way, do not expect any security at all.

It is not only about security. The primary goal is to remove the need for arch specific knowledge in the firmware about DT, bootparams and initrd allocation policies without being forced to load the initrd from a filesystem that is exposed via a EFI protocol.

Where are device-trees touched by this patch?

When booting via UEFI there is no need for knowledge of initrd allocation policies in U-Boot because up to now Linux or GRUB or iPXE load initrd.

Quoted 7 lines

Furthermore I need no knowledge of bootparams in U-Boot once we properly we support UEFI variables at runtime because grub-update will pass the command line in one of the Bootxxxx UEFI variables.

But most importantly I do not have to implement anything Linux specific in U-Boot for booting via UEFI up to now.

Adding Linux specific stuff to u-boot is arguably more appropriate than adding architecture specific stuff to EFI loaders that could otherwise be entirely generic.

...

Quoted 12 lines

Your patch claims to fend off a specific threat scenario: A user puts an untrusted initrd on the disk and references it in the Linux command line.

If he is able to do so with your current bootloader (signed or not signed), he most probably will also be able to delete a good initrd from the filesystem and thus force your code into the unsafe path.

That is why I say that with the current fallback logic this patch achieves no increase in security. Of cause you could remove the fallback logic. But in this case your Linux will not boot with any legacy bootloader or firmware.

If there is a better way to expose the initrd that
a) does not require the initrd to reside on a file system that is accessible via EFI protocols, and
b) does not require the loader to know about arch specific policies regarding the placement of the initrd in memory, and
c) does not leave a time window between the time that the initrd is loaded/verified/measured by the firmware and the time that the kernel gets handed the buffer

Quoted 3 lines

then I am happy to discuss it. This proposal is the best I could come up with to achieve the above.

Hello Ard,

I think part of our different views is that we are thinking about two different use cases which both have their relevance:

If I understand you correctly, you are thinking about an embedded device where the kernel and the initrd is essentially part of the firmware provided by the device.

I am thinking of a system running a standard Linux distribution like Debian where the initrd is generated by the operating system

Quoted 8 lines

In both use cases verifying the initrd is of importance.

Now concerning the requirements:

a) In U-Boot all file systems on block devices can be made accessible via EFI protocols. Are you thinking about initrds that are not in a file system?

The typical GRUB deployment keeps the core GRUB itself (or the entire thing if it is built as standalone) in the ESP, and the GRUB modules, kernel images and initrds are in /boot, which is typically not a file system that EFI understands. So in that case, initrd= does not work, which is why GRUB loads the initrd into memory directly and passes the base address and size via DT or bootparams structure.

Quoted 8 lines

Quoted 3 lines

b) My suggestion to use a UEFI variable for communicating the device path would not require any arch specific policies either.

Passing the EFI device path is not going to help us since the initrd may not be representable as a device path. That is the whole point, actually - this series makes the initrd representable as a device path, but in a simple way that doesn't rely on EFI_FILE_PROTOCOL but only on EFI_LOAD_FILE2_PROTOCOL, which is *much* simpler.

So if we had support in grub to just export its own file systems as UEFI protocols, that problem would disappear, right? What other reasons are left to not just use normal file load operations from the Linux EFI stub?

IIRC you mentioned that the fwcfg -kernel and -initrd parameters are already exposed as pseudo filesystem inside AAVMF, so that one is solved.

I think that only leaves the UEFI shell case? But if you have a UEFI shell, then you can only load from an existing file system as well, no?

What I can't quite grasp yet is how you would handle multiple initrds with a single device path. How would that work?

Quoted 9 lines

Quoted 9 lines

c) I proposed that the kernel does the verification. So there would be equally nothing in between loading the file and its verification. Yet responsibilities would be changed.

But possibly I missed some requirements you have in mind that I should consider.

Quoted 2 lines

1) The assumption that the initrd can always be loaded from a EFI device path directly does not hold.

Can you think of good reasons why this is true? I understand the grub one, but that's solvable. What other cases are there?

Quoted 3 lines

2) Loading the initrd into memory and passing the address and size is not acceptable.

This would basically be the option to pass the initrd as configuration table, right? The only reason that definitely goes against that one that I can think of right now is to avoid double copying?

Quoted 6 lines

3) Having a special device path that designates the initrd specifically (which will be treated in a special way by the kernel) makes it very easy for the boot firmware to attach policy to the loading of the initrd that can be enforced right when the file is being passed into the kernel.

I don't fully understand this one. Can you give examples for such policies? :)

Quoted 5 lines

Putting an arbitrary device path in a EFI variable doesn't address 1), and it complicates 3), since you cannot easily distinguish whether the file load that is occurring is the EFI stub loading the initrd at boot.

Why do we need to distinguish? I'm missing creativity for the use case right now. For 1), we just need to make sure that boot loaders that implement their own file systems also expose those file systems as UEFI protocols, right?

That said, I don't think the proposed approach of using EFI_LOAD_FILE2_PROTOCOL is bad. Whatever we do, we always will need to treat initrds special in one way or another; at least by exposing a command to specify which one(s) you want to load.

Quoted 193 lines · Ard Biesheuvel

Quoted 50 lines · Heinrich Schuchardt

Quoted 47 lines · Ard Biesheuvel

Quoted 6 lines · Heinrich Schuchardt

Quoted 5 lines · Ard Biesheuvel

Quoted 3 lines · Heinrich Schuchardt

Quoted 2 lines · Ard Biesheuvel

On Thu, 6 Feb 2020 at 18:26, Heinrich Schuchardt
<[email protected]> wrote:

...

Quoted 38 lines

Quoted 23 lines

Quoted 23 lines

Quoted 23 lines

Quoted 4 lines

Please, indicate which software you expect to expose the initrd related
EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it
would remove any need for these components to know any such details.
My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 5 lines

Using an UEFI variable for passing the initrd device path would be a
leaner solution on the bootloader side than requiring an extra EFI_LOAD_FILE2_PROTOCOL implementation.

This would also require kernel changes, since we don't currently load
initrds from arbitrary device paths. The EFI_FILE_PROTOCOL is much more complicated than needed, and it doesn't work well with mixed mode. It also requires GRUB to expose the filesystem it loads the initrd from via EFI protocols, which is currently unnecessary and therefore not implemented.

Quoted 6 lines

Quoted 3 lines

This means you move the complexity of EFI_FILE_PROTOCOL from Linux to GRUB.

No. I am not interested in EFI_FILE_PROTOCOL, only in LoadFile2, which
is a single method that needs to be implemented.

I said you move complexity because GRUB will need to use the EFI_FILE_PROTOCOL to do the job that you do not want to do in Linux.

Quoted 6 lines

Quoted 6 lines

I would not have a problem if this would only touch GRUB. But if listen
to Ilias we are replacing one implementation in Linux by one in GRUB and
one in U-Boot and one in EDK2 and one in any other firmware.

Quoted 8 lines

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

If u-boot will be used to boot RISC-V in EFI mode without GRUB, then I
expect that we will need an implementation of this in u-boot.

What sets RISC-V apart? GRUB for RISC-V is available.

   >>

Quoted 1 line

RISC-V EFI boot is not supported yet in upstream Linux.

It is currently prepared Atish Patra of WDC.

Exactly. So it is not in the upstream yet, and I want to converge on a sane generic interface before it gets merged.

Quoted 115 lines

Quoted 100 lines

Quoted 61 lines

Quoted 26 lines

Quoted 14 lines

Quoted 7 lines

Also, using an EFI variable defeats the purpose. The whole point of this is making it more likely that the kernel loaded the initrd that
the bootloader or firmware intended it to load, and having a piece of
simple [signed] code that implements this is the easiest way to achieve that.

At least on my Debian system it is the operating system creating initrd
and defining which initrd matches which kernel. GRUB simply assumes that
files ending on the same version number match. Therefore I would say Linux hopes that GRUB loads what Linux intended.

Quoted 6 lines

The chain of trust would not be broken if the kernel were responsible
for loading the initrd and for checking if it matches the kernel. Linux
already does this for the kernel modules in initrd.

We can still sign the initrd and Linux can verify the signature. What I am after is an interface that does not require the initrd to originate from a EFI file system protocol, and which doesn't require the loaded initrd to sit in memory for an unspecified amount of time and its information passed via DT properties or bootparams structs.

Quoted 3 lines

So invoking EFI_FILE_PROTOCOL directly is not going to work, regardless of whether we get the devicepath from the command line or from a EFI variable.

What do you mean by "is not going to work"?

With the device path you can find the handle implementing the EFI_SIMPLE_FIL_SYSTEM_PROTOCOL.

Quoted 13 lines

Quoted 13 lines

Quoted 5 lines

For u-boot, it should be trivial to implement a simple LoadFile2 protocol wrapper around EFI_FILE_PROTOCOL that can be installed on a
handle that also carries EFI_FILE_PROTOCOL.

A U-Boot implementation of the EFI_LOAD_FILE2_PROTOCOL would need a device path variable to find the block device and to open the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL before accessing the file.

Linux would not be needing more lines and we would not repeat the same
code in GRUB, U-Boot, EDK2, etc.

Quoted 8 lines

Quoted 4 lines

As said Linux updates the initrd often. If that file is not signed by
Linux in a well defined way, do not expect any security at all.

It is not only about security. The primary goal is to remove the need for arch specific knowledge in the firmware about DT, bootparams and initrd allocation policies without being forced to load the initrd from a filesystem that is exposed via a EFI protocol.

Where are device-trees touched by this patch?

When booting via UEFI there is no need for knowledge of initrd allocation policies in U-Boot because up to now Linux or GRUB or iPXE load initrd.

Quoted 9 lines

Furthermore I need no knowledge of bootparams in U-Boot once we properly
we support UEFI variables at runtime because grub-update will pass the command line in one of the Bootxxxx UEFI variables.

But most importantly I do not have to implement anything Linux specific
in U-Boot for booting via UEFI up to now.

Adding Linux specific stuff to u-boot is arguably more appropriate than adding architecture specific stuff to EFI loaders that could otherwise be entirely generic.

...

Quoted 10 lines

Your patch claims to fend off a specific threat scenario: A user puts an
untrusted initrd on the disk and references it in the Linux command line.

If he is able to do so with your current bootloader (signed or not signed), he most probably will also be able to delete a good initrd from
the filesystem and thus force your code into the unsafe path.

Quoted 6 lines

That is why I say that with the current fallback logic this patch achieves no increase in security. Of cause you could remove the fallback
logic. But in this case your Linux will not boot with any legacy bootloader or firmware.

If there is a better way to expose the initrd that
a) does not require the initrd to reside on a file system that is accessible via EFI protocols, and
b) does not require the loader to know about arch specific policies regarding the placement of the initrd in memory, and
c) does not leave a time window between the time that the initrd is loaded/verified/measured by the firmware and the time that the kernel gets handed the buffer

Quoted 3 lines

then I am happy to discuss it. This proposal is the best I could come up with to achieve the above.

Hello Ard,

I think part of our different views is that we are thinking about two different use cases which both have their relevance:

If I understand you correctly, you are thinking about an embedded device where the kernel and the initrd is essentially part of the firmware provided by the device.

I am thinking of a system running a standard Linux distribution like Debian where the initrd is generated by the operating system

Quoted 8 lines

In both use cases verifying the initrd is of importance.

Now concerning the requirements:

a) In U-Boot all file systems on block devices can be made accessible via EFI protocols. Are you thinking about initrds that are not in a file system?

The typical GRUB deployment keeps the core GRUB itself (or the entire thing if it is built as standalone) in the ESP, and the GRUB modules, kernel images and initrds are in /boot, which is typically not a file system that EFI understands. So in that case, initrd= does not work, which is why GRUB loads the initrd into memory directly and passes the base address and size via DT or bootparams structure.

Quoted 8 lines

Quoted 3 lines

b) My suggestion to use a UEFI variable for communicating the device path would not require any arch specific policies either.

Passing the EFI device path is not going to help us since the initrd may not be representable as a device path. That is the whole point, actually - this series makes the initrd representable as a device path, but in a simple way that doesn't rely on EFI_FILE_PROTOCOL but only on EFI_LOAD_FILE2_PROTOCOL, which is *much* simpler.

So if we had support in grub to just export its own file systems as UEFI protocols, that problem would disappear, right? What other reasons are left to not just use normal file load operations from the Linux EFI stub?

IIRC you mentioned that the fwcfg -kernel and -initrd parameters are already exposed as pseudo filesystem inside AAVMF, so that one is solved.

I think that only leaves the UEFI shell case? But if you have a UEFI shell, then you can only load from an existing file system as well, no?

What I can't quite grasp yet is how you would handle multiple initrds with a single device path. How would that work?

Quoted 7 lines

Quoted 7 lines

c) I proposed that the kernel does the verification. So there would be equally nothing in between loading the file and its verification. Yet responsibilities would be changed.

Quoted 5 lines

Quoted 3 lines

But possibly I missed some requirements you have in mind that I should consider.

1) The assumption that the initrd can always be loaded from a EFI device path directly does not hold.

Can you think of good reasons why this is true? I understand the grub one, but that's solvable. What other cases are there?

Quoted 2 lines

2) Loading the initrd into memory and passing the address and size is not acceptable.

This would basically be the option to pass the initrd as configuration table, right? The only reason that definitely goes against that one that I can think of right now is to avoid double copying?

Quoted 5 lines

3) Having a special device path that designates the initrd specifically (which will be treated in a special way by the kernel) makes it very easy for the boot firmware to attach policy to the loading of the initrd that can be enforced right when the file is being passed into the kernel.

I don't fully understand this one. Can you give examples for such policies? :)

Quoted 4 lines

Putting an arbitrary device path in a EFI variable doesn't address 1), and it complicates 3), since you cannot easily distinguish whether the file load that is occurring is the EFI stub loading the initrd at boot.

Why do we need to distinguish? I'm missing creativity for the use case right now. For 1), we just need to make sure that boot loaders that implement their own file systems also expose those file systems as UEFI protocols, right?

That said, I don't think the proposed approach of using EFI_LOAD_FILE2_PROTOCOL is bad. Whatever we do, we always will need to treat initrds special in one way or another; at least by exposing a command to specify which one(s) you want to load.

Alex

Quoted 2 lines · Heinrich Schuchardt

When booting via GRUB it will be GRUB knowing which initrd to load.

Exactly, which is why GRUB will implement this protocol. That way, it does not have to touch the DT at all, or create a bootparams struct from setup data and inspect the various flags about placement, alignment, preferred addresses, etc.

Quoted 3 lines

Please, indicate which software you expect to expose the initrd related EFI_LOAD_FILE2_PROTOCOL.

The primary use case is GRUB and other intermediate loaders, since it would remove any need for these components to know any such details. My aim is to make the next architecture that gets added to GRUB for EFI boot 100% generic.

Quoted 4 lines · Ard Biesheuvel

+    status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid, +                 (void **)&lf2);
+    if (status != EFI_SUCCESS)
+        return status;

You require here that there is a handle exposing the device path protocol with the initrd specific device path. On the same handle the EFI_LOAD_FILE2_PROTOCOL must be installed which will load the initrd file when called with the same device path.

An alternative implementation would simple loop over all instances of the EFI_LOAD_FILE2_PROTOCOL and try to load the initrd.

There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM)

In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.

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.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 drivers/firmware/efi/libstub/arm-stub.c        | 16 +++--
 drivers/firmware/efi/libstub/efi-stub-helper.c | 65 ++++++++++++++++++++
 drivers/firmware/efi/libstub/efistub.h         | 12 ++++
 drivers/firmware/efi/libstub/x86-stub.c        | 36 ++++++++++-
 include/linux/efi.h                            |  1 +
 5 files changed, 123 insertions(+), 7 deletions(-)

drivers/firmware/efi/libstub/arm-stub.c +1 -0

index c7b091f50e55..1db943c1ba2b 100644
@@ -157,6 +157,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
 	enum efi_secureboot_mode secure_boot;
 	struct screen_info *si;
 	efi_properties_table_t *prop_tbl;
+	unsigned long max_addr;
 
 	sys_table = sys_table_arg;
 

@@ -255,11 +256,18 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table_arg,
 	if (!fdt_addr)
 		pr_efi("Generating empty DTB\n");
 

drivers/firmware/efi/libstub/arm-stub.c +4 -1

+		if (status == EFI_SUCCESS)
+			pr_efi("Loaded initrd from command line option\n");
+	}
 	if (status != EFI_SUCCESS)
-		pr_efi_err("Failed initrd from command line!\n");
+		pr_efi_err("Failed to load initrd!\n");
 
 	efi_random_get_seed();
 

drivers/firmware/efi/libstub/efi-stub-helper.c +36 -0

index 8e60a39df3c5..eaf45ea749b3 100644
@@ -323,3 +323,68 @@ void efi_char16_printk(efi_char16_t *str)
 	efi_call_proto(efi_table_attr(efi_system_table(), con_out),
 		       output_string, str);
 }
+
+static const struct {
+	struct efi_vendor_dev_path	vendor;
+	struct efi_generic_dev_path	end;
+} __packed initrd_devpath = {
+	{
+		EFI_DEV_MEDIA,
+		EFI_DEV_MEDIA_VENDOR,
+		sizeof(struct efi_vendor_dev_path),
+		LINUX_EFI_INITRD_MEDIA_GUID
+	}, {
+		EFI_DEV_END_PATH,
+		EFI_DEV_END_ENTIRE,
+		sizeof(struct efi_generic_dev_path)
+	}
+};
+
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max)
+{
+	efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
+	efi_device_path_protocol_t *dp;
+	efi_load_file2_protocol_t *lf2;
+	unsigned long initrd_addr;
+	unsigned long initrd_size;
+	efi_handle_t handle;
+	efi_status_t status;
+
+	if (!load_addr || !load_size)
+		return EFI_INVALID_PARAMETER;
+
+	dp = (efi_device_path_protocol_t *)&initrd_devpath;
+	status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
+	if (status != EFI_SUCCESS)
+		return status;

drivers/firmware/efi/libstub/efi-stub-helper.c +9 -0

+	if (status != EFI_SUCCESS) {
+		efi_free(initrd_size, initrd_addr);
+		return status;
+	}
+
+	*load_addr = initrd_addr;
+	*load_size = initrd_size;
+	return EFI_SUCCESS;
+}

drivers/firmware/efi/libstub/efistub.h +12 -0

index 99e93fd76ec5..fbf9f9442eed 100644
@@ -566,6 +566,14 @@ union efi_load_file_protocol {
 	} mixed_mode;
 };
 
+struct efi_vendor_dev_path {
+	u8		type;
+	u8		sub_type;
+	u16		length;
+	efi_guid_t	vendorguid;
+	u8		vendordata[];
+} __packed;
+
 void efi_pci_disable_bridge_busmaster(void);
 
 typedef efi_status_t (*efi_exit_boot_map_processing)(

@@ -651,4 +659,8 @@ efi_status_t efi_load_initrd(efi_loaded_image_t *image,
 			     unsigned long *load_addr,
 			     unsigned long *load_size);
 
+efi_status_t efi_load_initrd_devpath(unsigned long *load_addr,
+				     unsigned long *load_size,
+				     unsigned long max);
+
 #endif

drivers/firmware/efi/libstub/x86-stub.c +4 -3

index f3e2ff31b624..7f38f95676dd 100644
@@ -419,9 +419,20 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	if (status != EFI_SUCCESS)
 		goto fail2;
 
-	status = efi_load_initrd(image, hdr->initrd_addr_max,
-				 above4g ? ULONG_MAX : hdr->initrd_addr_max,
-				 &ramdisk_addr, &ramdisk_size);
+	/*
+	 * The initrd loaded from the Linux initrd vendor device
+	 * path should take precedence, as we don't want the
+	 * [unverified] command line to override the initrd

drivers/firmware/efi/libstub/x86-stub.c +9 -0

 	if (status != EFI_SUCCESS)
 		goto fail2;
 	hdr->ramdisk_image = ramdisk_addr & 0xffffffff;

@@ -732,6 +743,25 @@ struct boot_params *efi_main(efi_handle_t handle,
 			 ((u64)boot_params->ext_cmd_line_ptr << 32));
 	efi_parse_options((char *)cmdline_paddr);
 
+	if (!hdr->ramdisk_size && !boot_params->ext_ramdisk_size) {
+		unsigned long max = hdr->initrd_addr_max;
+		unsigned long addr, size;
+
+		if (hdr->xloadflags & XLF_CAN_BE_LOADED_ABOVE_4G)
+			max = ULONG_MAX;
+
+		status = efi_load_initrd_devpath(&addr, &size, max);
+		if (status == EFI_SUCCESS) {