efi: implement generic compressed boot support

Relatively modern architectures such as arm64 or RISC-V don't implement a self-decompressing kernel, and leave it up to the bootloader to decompress the compressed image before executing it. For bare metal boot, this policy makes sense, as a self-decompressing image essentially duplicates a lot of fiddly preparation work to create a 1:1 mapping and set up the C runtime, and to discover or infer where DRAM lives from device trees or other firmware tables.

For EFI boot, the situation is a bit different: the EFI entrypoint is called with a 1:1 cached mapping covering all of DRAM already active, and with a stack, a heap, a memory map and boot services to load and start images. This means it is rather trivial to implement a self-decompressing wrapper for EFI boot in a generic manner, and reuse it across architectures that implement EFI boot.

The only slight downside is that when UEFI secure boot is enabled, the generic LoadImage/StartImage only allow signed images to be loaded and started, and we would prefer to avoid the need to sign both the inner and outer PE/COFF images.

However, the only truly generic and portable way to achieve this is to rely on LoadImage/StartImage as the EFI spec defines them, and avoid making assumptions about how things might work under the hood, and how we might circumvent that. This includes just loading the image into memory and jumping to the PE entry point: in the context of secure boot, measured boot and other hardening measures the firmware may take (such as disallowing mappings that are both writable and executable), using the firmware's image loading API is the only maintainable choice.

For this reason, this version of the series includes support for signing the images using sbsign, if the signing key and cert are specified in Kconfig.

The code is wired up for arm64, LoongArch and RISC-V. The latter was build tested only.

Changes since v3:
- add support for XZ and ZSTD compression
- deal with exit data returned by StartImage()
- use LoadFile2 based image loading instead of passing the raw buffer - this way, the provenance of the data is more visible, allowing us, for instance, to deal with initrd= on arm64 transparently (this means that systemd-boot on arm64 will work unmodified provided that the [deprecated] command line initrd loader is enabled in the kernel build)
- include LoongArch support
- rename compressed image to vmlinuz.efi on all architectures

Changes since v2:
- drop some of the refactoring work to make efi_printk() available in the decompressor, and just use fixed strings instead;
- provide memcpy/memmove/memset based on the UEFI boot services, instead of having to specify for each architecture how to wire these up;
- drop PI/DXE based signature check circumvention, and just sign the inner image instead, if needed;
- add a header to the zimage binary that identifies it as a EFI zboot image, and describes the compression algorithm and where the payload lives in the image - this might be used by non-EFI loaders to locate and decompress the bare metal image, given that the EFI zboot one is not a hybrid like the one it encapsulates.

Ard Biesheuvel (9):
efi: name the ARCH-stub.c files uniformly
efi/libstub: add some missing boot service prototypes efi/libstub: use EFI provided memcpy/memset routines efi/libstub: move efi_system_table global var into separate object efi/libstub: implement generic EFI zboot
arm64: efi: enable generic EFI compressed boot
riscv: efi: enable generic EFI compressed boot
loongarch: avoid orphan input sections
loongarch: efi: enable generic EFI compressed boot

 arch/arm64/Makefile                                       |   4 +-
 arch/arm64/boot/Makefile                                  |   6 +
 arch/arm64/kernel/image-vars.h                            |  13 -
 arch/loongarch/Kconfig                                    |   1 +
 arch/loongarch/Makefile                                   |   2 +-
 arch/loongarch/boot/Makefile                              |   6 +
 arch/loongarch/kernel/image-vars.h                        |   3 -
 arch/loongarch/kernel/vmlinux.lds.S                       |   2 +
 arch/riscv/Makefile                                       |   2 +-
 arch/riscv/boot/Makefile                                  |   6 +
 arch/riscv/kernel/image-vars.h                            |   9 -
 drivers/firmware/efi/Kconfig                              |  29 ++
 drivers/firmware/efi/libstub/Makefile                     |  21 +-
 drivers/firmware/efi/libstub/Makefile.zboot               |  70 +++++
 drivers/firmware/efi/libstub/{arm32-stub.c => arm-stub.c} |   0
 drivers/firmware/efi/libstub/efi-stub.c                   |   2 -
 drivers/firmware/efi/libstub/efistub.h                    |  35 ++-
 drivers/firmware/efi/libstub/file.c                       |  17 ++
 drivers/firmware/efi/libstub/intrinsics.c                 |  30 ++
 drivers/firmware/efi/libstub/systable.c                   |   8 +
 drivers/firmware/efi/libstub/zboot-header.S               | 139 ++++++++++
 drivers/firmware/efi/libstub/zboot.c                      | 289 ++++++++++++++++++++
 drivers/firmware/efi/libstub/zboot.lds                    |  41 +++
 include/linux/efi.h                                       |  13 +
 24 files changed, 699 insertions(+), 49 deletions(-)
 create mode 100644 drivers/firmware/efi/libstub/Makefile.zboot
 rename drivers/firmware/efi/libstub/{arm32-stub.c => arm-stub.c} (100%)
 create mode 100644 drivers/firmware/efi/libstub/intrinsics.c
 create mode 100644 drivers/firmware/efi/libstub/systable.c
 create mode 100644 drivers/firmware/efi/libstub/zboot-header.S
 create mode 100644 drivers/firmware/efi/libstub/zboot.c
 create mode 100644 drivers/firmware/efi/libstub/zboot.lds

2.35.1

Rename arm32-stub.c to arm-stub.c so that we can refer to all of them as $(ARCH)-stub.c

---
 drivers/firmware/efi/libstub/Makefile                     | 9 ++-------
 drivers/firmware/efi/libstub/{arm32-stub.c => arm-stub.c} | 0
 2 files changed, 2 insertions(+), 7 deletions(-)

index a4915cc499f3..68c181dcb8cf 100644
@@ -68,13 +68,8 @@ $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
 lib-$(CONFIG_EFI_GENERIC_STUB)	+= efi-stub.o fdt.o string.o \
 				   $(patsubst %.c,lib-%.o,$(efi-deps-y))
 
-lib-$(CONFIG_ARM)		+= arm32-stub.o
-lib-$(CONFIG_ARM64)		+= arm64-stub.o
-lib-$(CONFIG_X86)		+= x86-stub.o
-lib-$(CONFIG_RISCV)		+= riscv-stub.o
-lib-$(CONFIG_LOONGARCH)		+= loongarch-stub.o
-
-CFLAGS_arm32-stub.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
+lib-y				+= $(ARCH)-stub.o
+CFLAGS_arm-stub.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 
 # Even when -mbranch-protection=none is set, Clang will generate a
 # .note.gnu.property for code-less object files (like lib/ctype.c),

similarity index 100%
rename from drivers/firmware/efi/libstub/arm32-stub.c
rename to drivers/firmware/efi/libstub/arm-stub.c

2.35.1

Define the correct prototypes for the load_image, start_image and unload_image boot service pointers so we can call them from the EFI zboot code.

Also add some prototypes related to installation and deinstallation of protocols in to the EFI protocol database, including some definitions related to device paths.

---
Note that the device-path-to-text protocol is not used in this series, but it was useful during development so I retained the definitions.

 drivers/firmware/efi/libstub/efistub.h | 31 ++++++++++++++++----
 include/linux/efi.h                    | 12 ++++++++
 2 files changed, 38 insertions(+), 5 deletions(-)

index b0ae0a454404..c7efc404e663 100644
@@ -171,6 +171,23 @@ struct efi_boot_memmap {
 
 typedef struct efi_generic_dev_path efi_device_path_protocol_t;
 
+union efi_device_path_to_text_protocol {
+	struct {
+		efi_char16_t *(__efiapi *convert_device_node_to_text)(
+					const efi_device_path_protocol_t *,
+					bool, bool);
+		efi_char16_t *(__efiapi *convert_device_path_to_text)(
+					const efi_device_path_protocol_t *,
+					bool, bool);
+	};
+	struct {
+		u32 convert_device_node_to_text;
+		u32 convert_device_path_to_text;
+	} mixed_mode;
+};
+
+typedef union efi_device_path_to_text_protocol efi_device_path_to_text_protocol_t;
+
 typedef void *efi_event_t;
 /* Note that notifications won't work in mixed mode */
 typedef void (__efiapi *efi_event_notify_t)(efi_event_t, void *);

@@ -254,13 +271,17 @@ union efi_boot_services {
 							    efi_handle_t *);
 		efi_status_t (__efiapi *install_configuration_table)(efi_guid_t *,
 								     void *);
-		void *load_image;
-		void *start_image;
+		efi_status_t (__efiapi *load_image)(bool, efi_handle_t,
+						    efi_device_path_protocol_t *,
+						    void *, unsigned long,
+						    efi_handle_t *);
+		efi_status_t (__efiapi *start_image)(efi_handle_t, unsigned long *,
+						     efi_char16_t **);
 		efi_status_t __noreturn (__efiapi *exit)(efi_handle_t,
 							 efi_status_t,
 							 unsigned long,
 							 efi_char16_t *);
-		void *unload_image;
+		efi_status_t (__efiapi *unload_image)(efi_handle_t);
 		efi_status_t (__efiapi *exit_boot_services)(efi_handle_t,
 							    unsigned long);
 		void *get_next_monotonic_count;

@@ -277,8 +298,8 @@ union efi_boot_services {
 		void *locate_handle_buffer;
 		efi_status_t (__efiapi *locate_protocol)(efi_guid_t *, void *,
 							 void **);
-		void *install_multiple_protocol_interfaces;
-		void *uninstall_multiple_protocol_interfaces;
+		efi_status_t (__efiapi *install_multiple_protocol_interfaces)(efi_handle_t *, ...);
+		efi_status_t (__efiapi *uninstall_multiple_protocol_interfaces)(efi_handle_t, ...);
 		void *calculate_crc32;
 		void *copy_mem;
 		void *set_mem;

index d2b84c2fec39..af90f7989f80 100644
@@ -368,6 +368,9 @@ void efi_native_runtime_setup(void);
 #define UV_SYSTEM_TABLE_GUID			EFI_GUID(0x3b13a7d4, 0x633e, 0x11dd,  0x93, 0xec, 0xda, 0x25, 0x56, 0xd8, 0x95, 0x93)
 #define LINUX_EFI_CRASH_GUID			EFI_GUID(0xcfc8fc79, 0xbe2e, 0x4ddc,  0x97, 0xf0, 0x9f, 0x98, 0xbf, 0xe2, 0x98, 0xa0)
 #define LOADED_IMAGE_PROTOCOL_GUID		EFI_GUID(0x5b1b31a1, 0x9562, 0x11d2,  0x8e, 0x3f, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+#define LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID	EFI_GUID(0xbc62157e, 0x3e33, 0x4fec,  0x99, 0x20, 0x2d, 0x3b, 0x36, 0xd7, 0x50, 0xdf)
+#define EFI_DEVICE_PATH_PROTOCOL_GUID		EFI_GUID(0x09576e91, 0x6d3f, 0x11d2,  0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+#define EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID	EFI_GUID(0x8b843e20, 0x8132, 0x4852,  0x90, 0xcc, 0x55, 0x1a, 0x4e, 0x4a, 0x7f, 0x1c)
 #define EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID	EFI_GUID(0x9042a9de, 0x23dc, 0x4a38,  0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
 #define EFI_UGA_PROTOCOL_GUID			EFI_GUID(0x982c298b, 0xf4fa, 0x41cb,  0xb8, 0x38, 0x77, 0xaa, 0x68, 0x8f, 0xb8, 0x39)
 #define EFI_PCI_IO_PROTOCOL_GUID		EFI_GUID(0x4cf5b200, 0x68b8, 0x4ca5,  0x9e, 0xec, 0xb2, 0x3e, 0x3f, 0x50, 0x02, 0x9a)

@@ -952,6 +955,7 @@ extern int efi_status_to_err(efi_status_t status);
 #define   EFI_DEV_MEDIA_VENDOR			 3
 #define   EFI_DEV_MEDIA_FILE			 4
 #define   EFI_DEV_MEDIA_PROTOCOL		 5
+#define   EFI_DEV_MEDIA_REL_OFFSET		 8
 #define EFI_DEV_BIOS_BOOT		0x05
 #define EFI_DEV_END_PATH		0x7F
 #define EFI_DEV_END_PATH2		0xFF

@@ -982,12 +986,20 @@ struct efi_vendor_dev_path {
 	u8				vendordata[];
 } __packed;
 
+struct efi_rel_offset_dev_path {
+	struct efi_generic_dev_path	header;
+	u32				reserved;
+	u64				starting_offset;
+	u64				ending_offset;
+} __packed;
+
 struct efi_dev_path {
 	union {
 		struct efi_generic_dev_path	header;
 		struct efi_acpi_dev_path	acpi;
 		struct efi_pci_dev_path		pci;
 		struct efi_vendor_dev_path	vendor;
+		struct efi_rel_offset_dev_path	rel_offset;
 	};
 } __packed;
 

2.35.1

The stub is used in different execution environments, but on arm64, RISC-V and LoongArch, we still use the core kernel's implementation of memcpy and memset, as they are just a branch instruction away, and can generally be reused even from code such as the EFI stub that runs in a completely different address space.

KAsan complicates this slightly, resulting in the need for some hacks to expose the uninstrumented, __ prefixed versions as the normal ones, as the latter are instrumented to include the KAsan checks, which only work in the core kernel.

Unfortunately, #define'ing memcpy to __memcpy when building C code does not guarantee that no explicit memcpy() calls will be emitted. And with the upcoming zboot support, which consists of a separate binary which therefore needs its own implementation of memcpy/memset anyway, it's better to provide one explicitly instead of linking to the existing one.

Given that EFI exposes implementations of memmove() and memset() via the boot services table, let's wire those up in the appropriate way, and drop the references to the core kernel ones.

---
 arch/arm64/kernel/image-vars.h            | 13 ---------
 arch/loongarch/kernel/image-vars.h        |  3 --
 arch/riscv/kernel/image-vars.h            |  9 ------
 drivers/firmware/efi/libstub/Makefile     |  2 +-
 drivers/firmware/efi/libstub/efistub.h    |  4 +--
 drivers/firmware/efi/libstub/intrinsics.c | 30 ++++++++++++++++++++
 6 files changed, 33 insertions(+), 28 deletions(-)

index afa69e04e75e..11643f4d864d 100644
@@ -24,9 +24,6 @@ PROVIDE(__efistub_primary_entry_offset	= primary_entry - _text);
  */
 PROVIDE(__efistub_memcmp		= __pi_memcmp);
 PROVIDE(__efistub_memchr		= __pi_memchr);
-PROVIDE(__efistub_memcpy		= __pi_memcpy);
-PROVIDE(__efistub_memmove		= __pi_memmove);
-PROVIDE(__efistub_memset		= __pi_memset);
 PROVIDE(__efistub_strlen		= __pi_strlen);
 PROVIDE(__efistub_strnlen		= __pi_strnlen);
 PROVIDE(__efistub_strcmp		= __pi_strcmp);

@@ -40,16 +37,6 @@ PROVIDE(__efistub__edata		= _edata);
 PROVIDE(__efistub_screen_info		= screen_info);
 PROVIDE(__efistub__ctype		= _ctype);
 
-/*
- * The __ prefixed memcpy/memset/memmove symbols are provided by KASAN, which
- * instruments the conventional ones. Therefore, any references from the EFI
- * stub or other position independent, low level C code should be redirected to
- * the non-instrumented versions as well.
- */
-PROVIDE(__efistub___memcpy		= __pi_memcpy);
-PROVIDE(__efistub___memmove		= __pi_memmove);
-PROVIDE(__efistub___memset		= __pi_memset);
-
 PROVIDE(__pi___memcpy			= __pi_memcpy);
 PROVIDE(__pi___memmove			= __pi_memmove);
 PROVIDE(__pi___memset			= __pi_memset);

index c901ebb903f2..88f5d81702df 100644
@@ -9,9 +9,6 @@
 
 __efistub_memcmp		= memcmp;
 __efistub_memchr		= memchr;
-__efistub_memcpy		= memcpy;
-__efistub_memmove		= memmove;
-__efistub_memset		= memset;
 __efistub_strcat		= strcat;
 __efistub_strcmp		= strcmp;
 __efistub_strlen		= strlen;

index 71a76a623257..d6e5f739905e 100644
@@ -25,21 +25,12 @@
  */
 __efistub_memcmp		= memcmp;
 __efistub_memchr		= memchr;
-__efistub_memcpy		= memcpy;
-__efistub_memmove		= memmove;
-__efistub_memset		= memset;
 __efistub_strlen		= strlen;
 __efistub_strnlen		= strnlen;
 __efistub_strcmp		= strcmp;
 __efistub_strncmp		= strncmp;
 __efistub_strrchr		= strrchr;
 
-#ifdef CONFIG_KASAN
-__efistub___memcpy		= memcpy;
-__efistub___memmove		= memmove;
-__efistub___memset		= memset;
-#endif
-
 __efistub__start		= _start;
 __efistub__start_kernel		= _start_kernel;
 __efistub__end			= _end;

index 68c181dcb8cf..498ea6f7a92a 100644
@@ -65,7 +65,7 @@ efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c
 $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
 	$(call if_changed_rule,cc_o_c)
 
-lib-$(CONFIG_EFI_GENERIC_STUB)	+= efi-stub.o fdt.o string.o \
+lib-$(CONFIG_EFI_GENERIC_STUB)	+= efi-stub.o fdt.o string.o intrinsics.o \
 				   $(patsubst %.c,lib-%.o,$(efi-deps-y))
 
 lib-y				+= $(ARCH)-stub.o

index c7efc404e663..54f37e886be7 100644
@@ -301,8 +301,8 @@ union efi_boot_services {
 		efi_status_t (__efiapi *install_multiple_protocol_interfaces)(efi_handle_t *, ...);
 		efi_status_t (__efiapi *uninstall_multiple_protocol_interfaces)(efi_handle_t, ...);
 		void *calculate_crc32;
-		void *copy_mem;
-		void *set_mem;
+		void (__efiapi *copy_mem)(void *, const void *, unsigned long);
+		void (__efiapi *set_mem)(void *, unsigned long, unsigned char);
 		void *create_event_ex;
 	};
 	struct {

new file mode 100644
index 000000000000..a04ab39292b6
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/efi.h>
+#include <asm/efi.h>
+#include <asm/string.h>
+
+#include "efistub.h"
+
+#ifdef CONFIG_KASAN
+#undef memcpy
+#undef memmove
+#undef memset
+void *__memcpy(void *__dest, const void *__src, size_t __n) __alias(memcpy);
+void *__memmove(void *__dest, const void *__src, size_t count) __alias(memmove);
+void *__memset(void *s, int c, size_t count) __alias(memset);
+#endif
+
+void *memcpy(void *dst, const void *src, size_t len)
+{
+	efi_bs_call(copy_mem, dst, src, len);
+	return dst;
+}
+
+extern void *memmove(void *dst, const void *src, size_t len) __alias(memcpy);
+
+void *memset(void *dst, int c, size_t len)
+{
+	efi_bs_call(set_mem, dst, len, c & U8_MAX);
+	return dst;
+}

2.35.1

To avoid pulling in the wrong object when using the libstub static library to build the decompressor, define efi_system_table in a separate compilation unit.

---
 drivers/firmware/efi/libstub/Makefile   | 3 ++-
 drivers/firmware/efi/libstub/efi-stub.c | 2 --
 drivers/firmware/efi/libstub/systable.c | 8 ++++++++
 3 files changed, 10 insertions(+), 3 deletions(-)

index 498ea6f7a92a..fbe1900f47c4 100644
@@ -57,7 +57,8 @@ KCOV_INSTRUMENT			:= n
 lib-y				:= efi-stub-helper.o gop.o secureboot.o tpm.o \
 				   file.o mem.o random.o randomalloc.o pci.o \
 				   skip_spaces.o lib-cmdline.o lib-ctype.o \
-				   alignedmem.o relocate.o vsprintf.o
+				   alignedmem.o relocate.o vsprintf.o \
+				   systable.o
 
 # include the stub's generic dependencies from lib/ when building for ARM/arm64
 efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c

index 4bf751484e8b..57ea04378087 100644
@@ -57,8 +57,6 @@
 static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
 static bool flat_va_mapping = (EFI_RT_VIRTUAL_OFFSET != 0);
 
-const efi_system_table_t *efi_system_table;
-
 static struct screen_info *setup_graphics(void)
 {
 	efi_guid_t gop_proto = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;

new file mode 100644
index 000000000000..91d016b02f8c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/efi.h>
+#include <asm/efi.h>
+
+#include "efistub.h"
+
+const efi_system_table_t *efi_system_table;

2.35.1

Implement a minimal EFI app that decompresses the real kernel image and launches it using the firmware's LoadImage and StartImage boot services. This removes the need for any arch-specific hacks.

Note that on systems that have UEFI secure boot policies enabled, LoadImage/StartImage require images to be signed, or their hashes known a priori, in order to be permitted to boot.

There are various possible strategies to work around this requirement, but they all rely either on overriding internal PI/DXE protocols (which are not part of the EFI spec) or omitting the firmware provided LoadImage() and StartImage() boot services, which is also undesirable, given that they encapsulate platform specific policies related to secure boot and measured boot, but also related to memory permissions (whether or not and which types of heap allocations have both write and execute permissions.)

The only generic and truly portable way around this is to simply sign both the inner and the outer image with the same key/cert pair, so this is what is implemented here.

---
 drivers/firmware/efi/Kconfig                |  29 ++
 drivers/firmware/efi/libstub/Makefile       |   9 +-
 drivers/firmware/efi/libstub/Makefile.zboot |  70 +++++
 drivers/firmware/efi/libstub/file.c         |  17 ++
 drivers/firmware/efi/libstub/zboot-header.S | 139 ++++++++++
 drivers/firmware/efi/libstub/zboot.c        | 289 ++++++++++++++++++++
 drivers/firmware/efi/libstub/zboot.lds      |  41 +++
 include/linux/efi.h                         |   1 +
 8 files changed, 592 insertions(+), 3 deletions(-)

index cbf1c55dc224..5bdf3080e5da 100644
@@ -105,6 +105,35 @@ config EFI_RUNTIME_WRAPPERS
 config EFI_GENERIC_STUB
 	bool
 
+config EFI_ZBOOT
+	def_bool y
+	depends on EFI_GENERIC_STUB && !ARM
+	select HAVE_KERNEL_GZIP
+	select HAVE_KERNEL_LZ4
+	select HAVE_KERNEL_LZMA
+	select HAVE_KERNEL_LZO
+	select HAVE_KERNEL_XZ
+	select HAVE_KERNEL_ZSTD
+
+config EFI_ZBOOT_SIGNED
+	bool "Sign the EFI decompressor for UEFI secure boot"
+	depends on EFI_ZBOOT
+	help
+	  Use the 'sbsign' command line tool (which must exist on the host
+	  path) to sign both the EFI decompressor PE/COFF image, as well as the
+	  encapsulated PE/COFF image, which is subsequently compressed and
+	  wrapped by the former image.
+
+config EFI_ZBOOT_SIGNING_CERT
+	string "Certificate to use for signing the compressed EFI boot image"
+	depends on EFI_ZBOOT_SIGNED
+	default ""
+
+config EFI_ZBOOT_SIGNING_KEY
+	string "Private key to use for signing the compressed EFI boot image"
+	depends on EFI_ZBOOT_SIGNED
+	default ""
+
 config EFI_ARMSTUB_DTB_LOADER
 	bool "Enable the DTB loader"
 	depends on EFI_GENERIC_STUB && !RISCV && !LOONGARCH

index fbe1900f47c4..8931ed24379e 100644
@@ -72,6 +72,12 @@ lib-$(CONFIG_EFI_GENERIC_STUB)	+= efi-stub.o fdt.o string.o intrinsics.o \
 lib-y				+= $(ARCH)-stub.o
 CFLAGS_arm-stub.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 
+zboot-obj-$(CONFIG_RISCV)	:= lib-clz_ctz.o lib-ashldi3.o
+lib-$(CONFIG_EFI_ZBOOT)		+= zboot.o $(zboot-obj-y)
+
+extra-y				:= $(lib-y)
+lib-y				:= $(patsubst %.o,%.stub.o,$(lib-y))
+
 # Even when -mbranch-protection=none is set, Clang will generate a
 # .note.gnu.property for code-less object files (like lib/ctype.c),
 # so work around this by explicitly removing the unwanted section.

@@ -111,9 +117,6 @@ STUBCOPY_RELOC-$(CONFIG_ARM)	:= R_ARM_ABS
 # a verification pass to see if any absolute relocations exist in any of the
 # object files.
 #
-extra-y				:= $(lib-y)
-lib-y				:= $(patsubst %.o,%.stub.o,$(lib-y))
-
 STUBCOPY_FLAGS-$(CONFIG_ARM64)	+= --prefix-alloc-sections=.init \
 				   --prefix-symbols=__efistub_
 STUBCOPY_RELOC-$(CONFIG_ARM64)	:= R_AARCH64_ABS

index dd95f330fe6e..42b3338273aa 100644
@@ -66,10 +66,27 @@ static efi_status_t efi_open_file(efi_file_protocol_t *volume,
 static efi_status_t efi_open_volume(efi_loaded_image_t *image,
 				    efi_file_protocol_t **fh)
 {
+	struct efi_vendor_dev_path *dp = image->file_path;
+	efi_guid_t li_proto = LOADED_IMAGE_PROTOCOL_GUID;
 	efi_guid_t fs_proto = EFI_FILE_SYSTEM_GUID;
 	efi_simple_file_system_protocol_t *io;
 	efi_status_t status;
 
+	// If we are using EFI zboot, we should look for the file system
+	// protocol on the parent image's handle instead
+	if (IS_ENABLED(CONFIG_EFI_ZBOOT) &&
+	    image->parent_handle != NULL &&
+	    dp->header.type == EFI_DEV_MEDIA &&
+	    dp->header.sub_type == EFI_DEV_MEDIA_VENDOR &&
+	    !efi_guidcmp(dp->vendorguid, LINUX_EFI_ZBOOT_MEDIA_GUID)) {
+		status = efi_bs_call(handle_protocol, image->parent_handle,
+				     &li_proto, (void *)&image);
+		if (status != EFI_SUCCESS) {
+			efi_err("Failed to locate parent image handle\n");
+			return status;
+		}
+	}
+
 	status = efi_bs_call(handle_protocol, image->device_handle, &fs_proto,
 			     (void **)&io);
 	if (status != EFI_SUCCESS) {

index af90f7989f80..5efc3105f8e0 100644
@@ -411,6 +411,7 @@ void efi_native_runtime_setup(void);
 #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)
+#define LINUX_EFI_ZBOOT_MEDIA_GUID		EFI_GUID(0xe565a30d, 0x47da, 0x4dbd,  0xb3, 0x54, 0x9b, 0xb5, 0xc8, 0x4f, 0x8b, 0xe2)
 #define LINUX_EFI_MOK_VARIABLE_TABLE_GUID	EFI_GUID(0xc451ed2b, 0x9694, 0x45d3,  0xba, 0xba, 0xed, 0x9f, 0x89, 0x88, 0xa3, 0x89)
 #define LINUX_EFI_COCO_SECRET_AREA_GUID		EFI_GUID(0xadf956ad, 0xe98c, 0x484c,  0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47)
 

2.35.1

Wire up the generic EFI zboot support for arm64.

---
 arch/arm64/Makefile      | 4 ++--
 arch/arm64/boot/Makefile | 6 ++++++
 2 files changed, 8 insertions(+), 2 deletions(-)

index 6d9d4a58b898..92676ccc6363 100644
@@ -153,10 +153,10 @@ libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
 boot		:= arch/arm64/boot
 KBUILD_IMAGE	:= $(boot)/Image.gz
 
-all:	Image.gz
+all:	$(notdir $(KBUILD_IMAGE))
 
 
-Image: vmlinux
+Image vmlinuz.efi: vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
 Image.%: Image

index a0e3dedd2883..c65aee088410 100644
@@ -38,3 +38,9 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
 
 $(obj)/Image.zst: $(obj)/Image FORCE
 	$(call if_changed,zstd)
+
+EFI_ZBOOT_PAYLOAD	:= Image
+EFI_ZBOOT_BFD_TARGET	:= elf64-littleaarch64
+EFI_ZBOOT_MACH_TYPE	:= ARM64
+
+include $(srctree)/drivers/firmware/efi/libstub/Makefile.zboot

2.35.1

Hi,

Thanks for this series, its very helpful when using a boot manager that isn't grub (ex: systemd-boot, ipxe, etc) since those boot managers have the expectation that they are simply executing efi images. Given how large some of the uncompressed images get, and having a half dozen of them on a machine isn't ideal. So this series solves that problem, as well as cleans up some of the less than ideal grubisms that aren't needed on !x86 platforms.

So, I've been testing this series with a clean (as in grub/grubby/etc was never near the system) systemd-boot, which now works given the fixes to the initrd= option. It seems that the resulting boot path is noticeably faster as well. Given I've been testing both gziped and Lz4'ed images it could just be the latter option is faster, or it could be grubs decompressor/load sequence is just slow.

That said, I think there are a couple build tweaks in order. First, I would expect that just a normal 'make' (rather than 'make vmlinuz.efi') would make the resulting image when ZBOOT is enabled . Then I would expect 'make install' (or maybe a new 'make ezinstall?') to pass the new compressed efi to the installkernel utility. The install option would work without changes if the make pass just renames/creates the resulting vmlinuz.efi as Image. So.. there are a bunch of choices here, but my assumption is that the ZBOOT changes the resulting image, and the normal make/make install sequence just does the right thing.

So, now the fun bit. At the moment my shim->grub->efi-stubbed kernel path (which is the default fedora/rhel sequence) appears to be broken if I swap the compressed image (not the .gz version) in for a normal decompressed kernel. That appears to be a grub bug in fedora at the moment, but I've not fully tracked it down.

I was going to test secure boot, but the above problem has temporary stalled that, and I'm still cleaning up a few things on the sd-boot side (there isn't a shim in the path) before that is a workable testing path for anything other than a test signed kernel.

Thanks again for this, its extremely helpful.

GRUB will need to be patched for generic EFI zboot:
https://lists.gnu.org/archive/html/grub-devel/2022-08/msg00113.html

Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University

Wire up the generic EFI zboot support for RISC-V.

---
 arch/riscv/Makefile      | 2 +-
 arch/riscv/boot/Makefile | 6 ++++++
 2 files changed, 7 insertions(+), 1 deletion(-)

index 3fa8ef336822..ee9c24db082c 100644
@@ -139,7 +139,7 @@ else
 KBUILD_IMAGE := $(boot)/Image.gz
 endif
 endif
-BOOT_TARGETS := Image Image.gz loader loader.bin xipImage
+BOOT_TARGETS := Image Image.gz loader loader.bin xipImage vmlinuz.efi
 
 all:	$(notdir $(KBUILD_IMAGE))
 

index becd0621071c..d1a49adcb1d7 100644
@@ -58,3 +58,9 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
 
 $(obj)/loader.bin: $(obj)/loader FORCE
 	$(call if_changed,objcopy)
+
+EFI_ZBOOT_PAYLOAD	:= Image
+EFI_ZBOOT_BFD_TARGET	:= elf$(BITS)-littleriscv
+EFI_ZBOOT_MACH_TYPE	:= RISCV$(BITS)
+
+include $(srctree)/drivers/firmware/efi/libstub/Makefile.zboot

2.35.1

Ensure that all input sections are listed explicitly in the linker script, and issue a warning otherwise. This ensures that the binary image matches the PE/COFF and other image metadata exactly, which is important for things like code signing.

---
 arch/loongarch/Kconfig              | 1 +
 arch/loongarch/kernel/vmlinux.lds.S | 2 ++
 2 files changed, 3 insertions(+)

index fca106a8b8af..407502da4335 100644
@@ -51,6 +51,7 @@ config LOONGARCH
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
+	select ARCH_WANT_LD_ORPHAN_WARN
 	select ARCH_WANTS_NO_INSTR
 	select BUILDTIME_TABLE_SORT
 	select COMMON_CLK

index 36d042739f3c..17d33308dfba 100644
@@ -74,6 +74,8 @@ SECTIONS
 		EXIT_DATA
 	}
 
+	.rela.dyn : { *(.rela.dyn) *(.rela*) }
+
 #ifdef CONFIG_SMP
 	PERCPU_SECTION(1 << CONFIG_L1_CACHE_SHIFT)
 #endif

2.35.1

Hi, Ard,

It seems that this patch is a normal bugfix and has no relation with this series. If so, I prefer to take into loongarch-fixes for 6.0-rc4. Thanks.

Huacai

本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

It does have a relation: the signing tool will complain because the PE/COFF metadata goes out of sync, like so

SBSIGN arch/loongarch/boot/vmlinux.efi.signed
warning: data remaining[20754944 vs 20755016]: gaps between PE/COFF sections?

This is because of the *(.rela.dyn) section created by the linker, which is appended after the .data section, and so the PE/COFF .data section size does not match the file size.

*However*, you explained to me that vmlinux is not a PIC binary, and the link should be non-PIE as well. So this looks like another toolchain issue to me, that you may want to look into.

(The .rela.dyn section typically contains relocations applied by ld.so, either to PIE executables, or to shared libraries. It is probably harmless given that the loongarch kernel runs from its link time address, but it is still odd that this section is being generated)

Anyway, I will drop this patch from the series - I will leave it up to you entirely how you prefer to fix this.

In my builds:

With Binutils 2.39 and GCC 12, vmlinux rela.dyn contains 48 zero bytes (or 3 R_LARCH_NONE relocations, which is defined "do thing" and is ignored by ld, ld.so, and kernel module loader).

With Binutils trunk and GCC trunk, rela.dyn does not exist in vmlinux.(But for using the trunks of Binutils and GCC we'll need to either disable CONFIG_MODULES or apply [1].)

[1]:https://lore.kernel.org/loongarch/[email protected]/T/

Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University

But does the ELF psABI for LoongArch describe L_ARCH_NONE as a dynamic relocation? .rela.dyn typically only contains relocations that are specified as being suitable for runtime relocation.

If this is going to land in v6.1 as well, I suggest to drop the patch entirely. By the time this gets released, you can document which minimal toolchain version is required for UEFI secure boot signed kernels.

In Binutils 2.39 the BFD linker often over-estimate the size of .rela.*. For example if there is only 42 relocations, it may allocate the space for 47 relocations and fill the unused space in the section with zero. Then 5 R_LARCH_NONE will appear.

This has already caused trouble when we reviewed LoongArch glibc port, but at last the reviewers considered using NONE relocations as a "padding" acceptable. So in glibc ld.so will treat R_LARCH_NONE as a "dynamic" relocation with no real effect.

The issue (or "bug", if we want a more serious term) seems fixed in Binutils trunk, but I've not rebuilt the entire system with it so I'm not sure if it's completely fixed.

Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University

OK, I think this is the root cause, but this patch is still worthy to go 6.0-rc4.

Huacai

本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

Wire up the generic EFI zboot support for LoongArch64

---
 arch/loongarch/Makefile      | 2 +-
 arch/loongarch/boot/Makefile | 6 ++++++
 2 files changed, 7 insertions(+), 1 deletion(-)

index 4bc47f47cfd8..7051a95f7f31 100644
@@ -93,7 +93,7 @@ vdso_install:
 
 all:	$(notdir $(KBUILD_IMAGE))
 
-vmlinux.elf vmlinux.efi: vmlinux
+vmlinux.elf vmlinux.efi vmlinuz.efi: vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $(bootvars-y) $(boot)/$@
 
 install:

index fecf34f50e56..4e1c374c5782 100644
@@ -18,3 +18,9 @@ $(obj)/vmlinux.elf: vmlinux FORCE
 targets += vmlinux.efi
 $(obj)/vmlinux.efi: vmlinux FORCE
 	$(call if_changed,objcopy)
+
+EFI_ZBOOT_PAYLOAD      := vmlinux.efi
+EFI_ZBOOT_BFD_TARGET   := elf64-loongarch
+EFI_ZBOOT_MACH_TYPE    := LOONGARCH64
+
+include $(srctree)/drivers/firmware/efi/libstub/Makefile.zboot

2.35.1

Hi Ard,

Should we also add

--

index 063a578bbdaa..6ee3d7826893 100644
@@ -9,10 +9,16 @@ KBUILD_DEFCONFIG := loongson3_defconfig
 
 ifndef CONFIG_EFI_STUB
 KBUILD_IMAGE	:= $(boot)/vmlinux.elf
-else
+else # CONFIG_EFI_STUB
+
+ifndef CONFIG_EFI_ZBOOT
 KBUILD_IMAGE	:= $(boot)/vmlinux.efi
+else
+KBUILD_IMAGE	:= $(boot)/vmlinuz.efi
 endif
 
+endif # CONFIG_EFI_STUB
+
 #
 # Select the object file format to substitute into the linker script.
 #

--

or do we deliberately expect builders to run "make vmlinuz.efi" explicitly?

Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University

Hi, all,

I prefer to add to KBUILD_IMAGE, we can even add to make install.

Huacai

本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.