efi: implement generic compressed boot support

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

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

---
  drivers/firmware/efi/libstub/efistub.h | 12 ++++++++----
  1 file changed, 8 insertions(+), 4 deletions(-)

drivers/firmware/efi/libstub/efistub.h +8 -4

index ab9e990447d3..33215d7bd276 100644
@@ -254,8 +254,12 @@ 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,

@@ -277,8 +281,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;

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

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

---
 arch/riscv/Makefile      |  5 +++++
 arch/riscv/boot/Makefile | 14 ++++++++++++++
 2 files changed, 19 insertions(+)

arch/riscv/Makefile +5 -0

index 81029d40a672..c30ea65ec877 100644
@@ -142,6 +142,11 @@ $(BOOT_TARGETS): vmlinux
 Image.%: Image
 	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
+ifneq ($(CONFIG_EFI_ZBOOT),)
+zImage.efi: Image
+	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
+endif
+
 install: KBUILD_IMAGE := $(boot)/Image
 zinstall: KBUILD_IMAGE := $(boot)/Image.gz
 install zinstall:

arch/riscv/boot/Makefile +4 -0

index becd0621071c..60cd319685ea 100644
@@ -58,3 +58,17 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
 
 $(obj)/loader.bin: $(obj)/loader FORCE
 	$(call if_changed,objcopy)
+
+ZBOOT_PAYLOAD		:= $(obj)/Image
+ZBOOT_BFD_TARGET	:= elf$(BITS)-littleriscv
+ZBOOT_LD_FLAGS		:= --defsym=__efistub_strnlen=strnlen \

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 prefer to avoid the need to sign both the inner and outer PE/COFF images. This series adopts the EFI shim approach, i.e., to override an internal UEFI/PI protocol that is used by the image loader, to allow the inner image to be booted after decompression. This has been

tested to work with Tianocore based EFI implementations on arm64, but u-boot will need some interoperability tweaks as well, ideally just a protocol that exposes a LoadImage/StartImage combo that the decompresor can use directly to circumvent the signature check. (Note that EFI apps have full control over the CPU, page tables, etc. so having code that circumvents authentication checks is not as crazy as it sounds, given that the app can do anything it pleases already.)

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

Cc "James E.J. Bottomley" <[email protected]>

Cc Matthew Garrett <[email protected]>

Cc Peter Jones <[email protected]>

Cc Ilias Apalodimas <[email protected]>

Cc Heinrich Schuchardt <[email protected]>

Cc AKASHI Takahiro <[email protected]>

Cc Palmer Dabbelt <[email protected]>

Cc Atish Patra <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Huacai Chen <[email protected]>

Cc Lennart Poettering <[email protected]>

Ard Biesheuvel (6):
efi: stub: add some missing boot service prototypes
efi: stub: split off printk() routines
efi: stub: move efi_system_table global var into separate object
efi: stub: implement generic EFI zboot
arm64: efi: enable generic EFI compressed boot
riscv: efi: enable generic EFI compressed boot

  arch/arm64/Makefile                            |   5 +
  arch/arm64/boot/Makefile                       |  12 ++
  arch/riscv/Makefile                            |   5 +
  arch/riscv/boot/Makefile                       |  14 ++
  drivers/firmware/efi/Kconfig                   |   9 +
  drivers/firmware/efi/libstub/Makefile          |   7 +-
  drivers/firmware/efi/libstub/Makefile.zboot    |  30 +++
  drivers/firmware/efi/libstub/efi-stub-helper.c | 141 ---------------
  drivers/firmware/efi/libstub/efi-stub.c        |   2 -
  drivers/firmware/efi/libstub/efistub.h         |  12 +-
  drivers/firmware/efi/libstub/printk.c          | 158 ++++++++++++++++
  drivers/firmware/efi/libstub/systable.c        |   8 +
  drivers/firmware/efi/libstub/zboot-header.S    | 144 +++++++++++++++
  drivers/firmware/efi/libstub/zboot.c           | 191 ++++++++++++++++++++
  drivers/firmware/efi/libstub/zboot.lds         |  41 +++++
  include/linux/efi.h                            |   2 +
  16 files changed, 633 insertions(+), 148 deletions(-)

create mode 100644 drivers/firmware/efi/libstub/Makefile.zboot create mode 100644 drivers/firmware/efi/libstub/printk.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

Quoted 15 lines · Ard Biesheuvel

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.

Quoted 6 lines

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 prefer to avoid the need to sign both the inner and outer PE/COFF images. This series adopts the EFI shim approach, i.e., to override an internal UEFI/PI protocol that is used by the image loader, to allow the inner image to be booted after decompression. This has been

We should avoid requiring anything that is not in the UEFI specification. If you have any additional requirements, please, create a change request for the UEFI specification.

Overriding the services of the system table is dangerous and should be avoided.

There is no need for two UEFI binaries one inside the other and we should avoid such overengineering.

Today we append an uncompressed kernel to the EFI stub. The stub relocates it, sets up the memory map and calls it entry point.

Just add decompressor code to the EFI stub and instead of appending an uncompressed kernel append a compressed one. Then sign a binary consisting of the EFI stub and the compressed kernel.

This way you don't need any change to UEFI firmware at all and you don't need to override UEFI services.

Another reasonable approach would be to zip the signed UEFI binary (EFI stub with uncompressed kernel) and let the UEFI firmware unzip it and check the signature of the decompressed UEFI binary. This would not require any patch in Linux at all and would be simple to implement in U-Boot.

Quoted 24 lines · Heinrich Schuchardt

Quoted 15 lines · Ard Biesheuvel

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.

Quoted 6 lines

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 prefer to avoid the need to sign both the inner and outer PE/COFF images. This series adopts the EFI shim approach, i.e., to override an internal UEFI/PI protocol that is used by the image loader, to allow the inner image to be booted after decompression. This has been

Quoted 4 lines

We should avoid requiring anything that is not in the UEFI specification. If you have any additional requirements, please, create a change request for the UEFI specification.

As I have explained numerous times before, the EFI spec was intended to be extensible (hence the 'E'). The ACPI, SMBIOS and TCG specs all augment the EFI specification by defining protocols, GUIDs and other things that are only relevant in a EFI context, but none of those are covered by the EFI spec itself.

Quoted 3 lines

Overriding the services of the system table is dangerous and should be avoided.

Agreed. But this is not what is happening here.

Quoted 3 lines

There is no need for two UEFI binaries one inside the other and we should avoid such overengineering.

I disagree. Using an EFI app to encapsulate another one is the only generic way to go about this, as far as I can tell.

Quoted 4 lines

Today we append an uncompressed kernel to the EFI stub. The stub relocates it, sets up the memory map and calls it entry point.

Not exactly. On arm64 as well as RISC-V, the EFI stub and the kernel proper are essentially the same executable image.

Quoted 5 lines

Just add decompressor code to the EFI stub and instead of appending an uncompressed kernel append a compressed one. Then sign a binary consisting of the EFI stub and the compressed kernel.

Yes, this would be a cleaner approach, although it would require more re-engineering of the EFI stub, in particular, it would require cloning more code, and adding additional build and link steps.

Quoted 10 lines

This way you don't need any change to UEFI firmware at all and you don't need to override UEFI services.

Another reasonable approach would be to zip the signed UEFI binary (EFI stub with uncompressed kernel) and let the UEFI firmware unzip it and check the signature of the decompressed UEFI binary. This would not require any patch in Linux at all and would be simple to implement in U-Boot.

This is how it works today. One problem with this is that the image needs to be decompressed in order to sign it, or verify its signature. In general, having compression at the outside like this is fiddly because it is no longer a PE/COFF image, and the EFI spec only reasons about PE/COFF images as executable images. So we'd need to change the UEFI spec or the PE/COFF spec.

Quoted 47 lines · Ard Biesheuvel

Quoted 24 lines · Heinrich Schuchardt

Quoted 15 lines · Ard Biesheuvel

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.

Quoted 6 lines

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 prefer to avoid the need to sign both the inner and outer PE/COFF images. This series adopts the EFI shim approach, i.e., to override an internal UEFI/PI protocol that is used by the image loader, to allow the inner image to be booted after decompression. This has been

Quoted 4 lines

We should avoid requiring anything that is not in the UEFI specification. If you have any additional requirements, please, create a change request for the UEFI specification.

As I have explained numerous times before, the EFI spec was intended to be extensible (hence the 'E'). The ACPI, SMBIOS and TCG specs all augment the EFI specification by defining protocols, GUIDs and other things that are only relevant in a EFI context, but none of those are covered by the EFI spec itself.

Quoted 3 lines

Overriding the services of the system table is dangerous and should be avoided.

Agreed. But this is not what is happening here.

Quoted 3 lines

There is no need for two UEFI binaries one inside the other and we should avoid such overengineering.

Quoted 2 lines

I disagree. Using an EFI app to encapsulate another one is the only generic way to go about this, as far as I can tell.

Please, elaborate why the inner compressed binary needs to be UEFI to boot into Linux while currently we don't need a an uncompressed inner UEFI binary.

Quoted 7 lines

Quoted 4 lines

Today we append an uncompressed kernel to the EFI stub. The stub relocates it, sets up the memory map and calls it entry point.

Not exactly. On arm64 as well as RISC-V, the EFI stub and the kernel proper are essentially the same executable image.

Currently on ARM and RISC-V you have a file with two entry points:

* EFI stub
* legacy entry point

The EFI stub calls the legacy entry point. In the EFI case some part of the EFI stub lives on at runtime. The same pointers passed to the legacy entry point could also be passed to a decompressed legacy kernel.

The EFI stub and the kernel should be completely separate binaries. Then you just need the cp command to join them.

Quoted 6 lines

Quoted 5 lines

Just add decompressor code to the EFI stub and instead of appending an uncompressed kernel append a compressed one. Then sign a binary consisting of the EFI stub and the compressed kernel.

Quoted 3 lines

Yes, this would be a cleaner approach, although it would require more re-engineering of the EFI stub, in particular, it would require cloning more code, and adding additional build and link steps.

If this is the cleanest approach, we should go for it.

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 prefer to avoid the need to sign both the inner and outer PE/COFF images. This series adopts the EFI shim approach, i.e., to override an internal UEFI/PI protocol that is used by the image loader,

to allow the inner image to be booted after decompression. This has been tested to work with Tianocore based EFI implementations on arm64, but u-boot will need some interoperability tweaks as well, ideally just a protocol that exposes a LoadImage/StartImage combo that the decompresor can use directly to circumvent the signature check. (Note that EFI apps have full control over the CPU, page tables, etc. so having code that circumvents authentication checks is not as crazy as it sounds, given that the app can do anything it pleases already.)