efi/x86: add support for generic EFI mixed mode boot

Currently, mixed mode is closely tied to the EFI handover protocol and relies on intimate knowledge of the bootparams structure, setup header etc, all of which are rather byzantine and entirely specific to x86.

Even though no other EFI supported architectures are currently known that could support something like mixed mode, it makes sense to abstract a bit from this, and make it part of a generic Linux on EFI boot protocol.

To that end, add a .compat section to the mixed mode binary, and populate it with the PE machine type and entry point address, allowing firmware implementations to match it to their native machine type, and invoke non-native binaries using a secondary entry point.

Quoted 10 lines · Ard Biesheuvel

Currently, mixed mode is closely tied to the EFI handover protocol and relies on intimate knowledge of the bootparams structure, setup header etc, all of which are rather byzantine and entirely specific to x86.

Even though no other EFI supported architectures are currently known that could support something like mixed mode, it makes sense to abstract a bit from this, and make it part of a generic Linux on EFI boot protocol.

Quoted 4 lines

To that end, add a .compat section to the mixed mode binary, and populate it with the PE machine type and entry point address, allowing firmware implementations to match it to their native machine type, and invoke non-native binaries using a secondary entry point.

This patch refers to efi32_pe_entry which is only defined in the next one.

Add support for booting 64-bit x86 kernels from 32-bit firmware running on 64-bit capable CPUs without requiring the bootloader to implement the EFI handover protocol, allocate the setup block etc etc, all of which can be done by the stub using code we have already implemented.

Instead, create an ordinary EFI application entrypoint but implemented in 32-bit code, so that it can be invoked by 32-bit firmware, and stash the address of this 32-bit entrypoint in the .compat section where the bootloader can find it.

Note that we use the setup block embedded in the binary to go through startup_32(), but it gets reallocated and copied in efi_pe_entry(), using the same code that runs when the x86 kernel is booted in EFI mode from native firmware. This requires the loaded image protocol to be installed on the kernel image's EFI handle, and point to the kernel image itself and not to its loader. This, in turn, requires the bootloader to use the LoadImage() boot services to load the 64-bit image from 32-bit firmware, which is in fact supported by firmware based on EDK2. (Only StartImage() will fail, and instead, the newly added entrypoint needs to be invoked)

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

---
 arch/x86/boot/compressed/head_64.S | 61 +++++++++++++++++++-
 1 file changed, 59 insertions(+), 2 deletions(-)

arch/x86/boot/compressed/head_64.S +1 -1

index a4f5561c1c0e..7baaf9c97f5a 100644
@@ -207,8 +207,8 @@ SYM_FUNC_START(startup_32)
 	cmp	$0, %edi
 	jz	1f
 	leal	efi64_stub_entry(%ebp), %eax
-	movl	%esi, %edx
 	movl	efi32_boot_args+4(%ebp), %esi
+	movl	efi32_boot_args+8(%ebp), %edx	// saved bootparams pointer
 1:
 #endif
 	pushl	%eax

arch/x86/boot/compressed/head_64.S +33 -0

 	movl	%ecx, efi32_boot_args(%ebp)
 	movl	%edx, efi32_boot_args+4(%ebp)
 	movb	$0, efi_is64(%ebp)

@@ -249,6 +251,49 @@ SYM_FUNC_START(efi32_stub_entry)
 
 	jmp	startup_32
 SYM_FUNC_END(efi32_stub_entry)
+
+#define ST32_boottime		60 // offsetof(efi_system_table_32_t, boottime)
+#define BS32_handle_protocol	88 // offsetof(efi_boot_services_32_t, handle_protocol)
+#define LI32_image_base		32 // offsetof(efi_loaded_image_32_t, image_base)
+
+	.subsection 1
+	.code32
+SYM_FUNC_START(efi32_pe_entry)
+	pushl	%ebp
+
+	call	3f
+3:	pop	%ebp
+	subl	$3b, %ebp
+
+	/* Get the loaded image protocol pointer from the image handle */
+	subl	$12, %esp			// space for the loaded image pointer
+	pushl	%esp				// pass its address
+	leal	5f(%ebp), %eax
+	pushl	%eax				// pass the GUID address
+	pushl	28(%esp)			// pass the image handle
+
+	movl	36(%esp), %eax			// sys_table
+	movl	ST32_boottime(%eax), %eax	// sys_table->boottime
+	call	*BS32_handle_protocol(%eax)	// sys_table->boottime->handle_protocol
+	cmp	$0, %eax
+	jnz	4f
+
+	movl	32(%esp), %ecx			// image_handle
+	movl	36(%esp), %edx			// sys_table
+	movl	12(%esp), %esi			// loaded_image
+	movl	LI32_image_base(%esi), %esi	// loaded_image->image_base
+	jmp	2b
+

arch/x86/boot/compressed/head_64.S +13 -1

 #endif
 
 	.code64

@@ -465,11 +510,23 @@ SYM_CODE_END(startup_64)
 SYM_FUNC_START(efi64_stub_entry)
 SYM_FUNC_START_ALIAS(efi_stub_entry)
 	and	$~0xf, %rsp			/* realign the stack */
+#ifdef CONFIG_EFI_MIXED
+	cmpl	$0, %edx
+	jz	0f
+#endif
 	call	efi_main
 	movq	%rax,%rsi
 	movl	BP_code32_start(%esi), %eax
 	leaq	startup_64(%rax), %rax
 	jmp	*%rax
+
+#ifdef CONFIG_EFI_MIXED
+0:	movl	%edi, %ecx		// MS calling convention
+	movl	%esi, %edx
+	call	efi_pe_entry
+1:	hlt
+	jmp	1b
+#endif
 SYM_FUNC_END(efi64_stub_entry)
 SYM_FUNC_END_ALIAS(efi_stub_entry)
 #endif

@@ -641,7 +698,7 @@ SYM_DATA_START_LOCAL(gdt)
 SYM_DATA_END_LABEL(gdt, SYM_L_LOCAL, gdt_end)
 
 #ifdef CONFIG_EFI_MIXED
-SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0)
+SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0, 0)
 SYM_DATA(efi_is64, .byte 1)
 #endif
 

Signature · 1 line

2.17.1

Quoted 44 lines · Ard Biesheuvel

Add support for booting 64-bit x86 kernels from 32-bit firmware running on 64-bit capable CPUs without requiring the bootloader to implement the EFI handover protocol, allocate the setup block etc etc, all of which can be done by the stub using code we have already implemented.

Instead, create an ordinary EFI application entrypoint but implemented in 32-bit code, so that it can be invoked by 32-bit firmware, and stash the address of this 32-bit entrypoint in the .compat section where the bootloader can find it.

Note that we use the setup block embedded in the binary to go through startup_32(), but it gets reallocated and copied in efi_pe_entry(), using the same code that runs when the x86 kernel is booted in EFI mode from native firmware. This requires the loaded image protocol to be installed on the kernel image's EFI handle, and point to the kernel image itself and not to its loader. This, in turn, requires the bootloader to use the LoadImage() boot services to load the 64-bit image from 32-bit firmware, which is in fact supported by firmware based on EDK2. (Only StartImage() will fail, and instead, the newly added entrypoint needs to be invoked)

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

---
 arch/x86/boot/compressed/head_64.S | 61 +++++++++++++++++++-
 1 file changed, 59 insertions(+), 2 deletions(-)

arch/x86/boot/compressed/head_64.S +1 -1

index a4f5561c1c0e..7baaf9c97f5a 100644
@@ -207,8 +207,8 @@ SYM_FUNC_START(startup_32)
      cmp     $0, %edi
      jz      1f
      leal    efi64_stub_entry(%ebp), %eax
-     movl    %esi, %edx
      movl    efi32_boot_args+4(%ebp), %esi
+     movl    efi32_boot_args+8(%ebp), %edx   // saved bootparams pointer
 1:
 #endif
      pushl   %eax

@@ -233,6 +233,8 @@ SYM_FUNC_START(efi32_stub_entry)
 1:   pop     %ebp
      subl    $1b, %ebp
 

arch/x86/boot/compressed/head_64.S SYM_FUNC_START(efi32_stub_entry) · line 237

Quoted 2 lines

arch/x86/boot/compressed/head_64.S +2 -0

+     movl    %esi, efi32_boot_args+8(%ebp)
+2:

I think it would be easier to read if this were turned into a proper SYM_INNER_LABEL. You could then also just put efi32_pe_entry into the .text section instead of moving it to the end of .head.text with .subsection. Another option is to use a separate flag in .data to indicate that we entered via efi32_pe_entry, then you could just jump to efi32_stub_entry.

Quoted 44 lines

arch/x86/boot/compressed/head_64.S +37 -0

      movl    %ecx, efi32_boot_args(%ebp)
      movl    %edx, efi32_boot_args+4(%ebp)
      movb    $0, efi_is64(%ebp)

@@ -249,6 +251,49 @@ SYM_FUNC_START(efi32_stub_entry)
 
      jmp     startup_32
 SYM_FUNC_END(efi32_stub_entry)
+
+#define ST32_boottime                60 // offsetof(efi_system_table_32_t, boottime)
+#define BS32_handle_protocol 88 // offsetof(efi_boot_services_32_t, handle_protocol)
+#define LI32_image_base              32 // offsetof(efi_loaded_image_32_t, image_base)
+
+     .subsection 1
+     .code32
+SYM_FUNC_START(efi32_pe_entry)
+     pushl   %ebp
+
+     call    3f
+3:   pop     %ebp
+     subl    $3b, %ebp
+
+     /* Get the loaded image protocol pointer from the image handle */
+     subl    $12, %esp                       // space for the loaded image pointer
+     pushl   %esp                            // pass its address
+     leal    5f(%ebp), %eax
+     pushl   %eax                            // pass the GUID address
+     pushl   28(%esp)                        // pass the image handle
+
+     movl    36(%esp), %eax                  // sys_table
+     movl    ST32_boottime(%eax), %eax       // sys_table->boottime
+     call    *BS32_handle_protocol(%eax)     // sys_table->boottime->handle_protocol
+     cmp     $0, %eax
+     jnz     4f
+
+     movl    32(%esp), %ecx                  // image_handle
+     movl    36(%esp), %edx                  // sys_table
+     movl    12(%esp), %esi                  // loaded_image
+     movl    LI32_image_base(%esi), %esi     // loaded_image->image_base
+     jmp     2b
+
+4:   addl    $24, %esp
+     popl    %ebp
+     ret
+SYM_FUNC_END(efi32_pe_entry)

arch/x86/boot/compressed/head_64.S SYM_FUNC_START(efi32_stub_entry) · line 296

Quoted 6 lines

arch/x86/boot/compressed/head_64.S +6 -0

+
+     /* EFI loaded image protocol GUID */
+5:   .long   0x5B1B31A1
+     .word   0x9562, 0x11d2
+     .byte   0x8E, 0x3F, 0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B
+     .previous

Any reason for this not to live in .data (or .rodata)?

Quoted 39 lines

arch/x86/boot/compressed/head_64.S +13 -2

 #endif
 
      .code64

@@ -465,11 +510,23 @@ SYM_CODE_END(startup_64)
 SYM_FUNC_START(efi64_stub_entry)
 SYM_FUNC_START_ALIAS(efi_stub_entry)
      and     $~0xf, %rsp                     /* realign the stack */
+#ifdef CONFIG_EFI_MIXED
+     cmpl    $0, %edx
+     jz      0f
+#endif
      call    efi_main
      movq    %rax,%rsi
      movl    BP_code32_start(%esi), %eax
      leaq    startup_64(%rax), %rax
      jmp     *%rax
+
+#ifdef CONFIG_EFI_MIXED
+0:   movl    %edi, %ecx              // MS calling convention
+     movl    %esi, %edx
+     call    efi_pe_entry
+1:   hlt
+     jmp     1b
+#endif
 SYM_FUNC_END(efi64_stub_entry)
 SYM_FUNC_END_ALIAS(efi_stub_entry)
 #endif

@@ -641,7 +698,7 @@ SYM_DATA_START_LOCAL(gdt)
 SYM_DATA_END_LABEL(gdt, SYM_L_LOCAL, gdt_end)
 
 #ifdef CONFIG_EFI_MIXED
-SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0)
+SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0, 0)
 SYM_DATA(efi_is64, .byte 1)
 #endif
 
--

2.17.1

This series is another part of my effort to reduce the level of knowledge on the part of the bootloader or firmware of internal per-architecture details regarding where/how the kernel is loaded and where its initrd and other context data are passed.

The x86 architecture has a so-called 'EFI handover protocol', which defines how the bootparams struct should be populated, and how it should be interpreted to figure out where to load the kernel, and at which offset in the binary the entrypoint is located. This scheme allows the initrd to be loaded beforehand, and allows 32-bit firmware to invoke a 64-bit kernel via a special entrypoint that manages the state transitions between the two execution modes.

Due to this, x86 loaders currently do not rely on LoadImage and StartImage, and therefore, are forced to re-implement things like image authentication for secure boot and taking the measurements for measured boot in their open coded clones of these routines.

My previous series on this topic [0] implements a generic way to load the initrd from any source supported by the loader without relying on something like device trees or bootparams structures, and so native boot should not need the EFI handover protocol anymore after those change are merged.

What remains is mixed mode boot, which also needs the EFI handover protocol regardless of whether an initrd is loaded or not. So let's get rid of that requirement, and take advantage of the fact that EDK2 based firmware does support LoadImage() for X64 binaries on IA32 firmware, which means we can rely on the secure boot and measured boot checks being performed by the firmware. The only thing we need to put on top is a way to discover the non-native entrypoint into the binary in a way that does not rely on x86 specific headers and data structures.

So let's introduce a new .compat header in the PE/COFF metadata of the bzImage, and populate it with a <machine type, entrypoint> tuple, allowing a generic EFI loader to decide whether the entrypoint supports its native machine type, and invoke it as an ordinary EFI application entrypoint. Since we will not be passing a bootparams structure, we need to discover the base of the image (which contains the setup header) via the loaded image protocol before we can enter the kernel in 32-bit mode at startup_32()

A loader implementation for OVMF can be found at [1]. Note that this loader code is fully generic, and could be used without modifications if other architectures ever emerge that support kernels that can be invoked from a non-native (but cross-type supported) loader.

[0] https://lore.kernel.org/linux-arm-kernel/[email protected]/
[1] https://github.com/ardbiesheuvel/edk2/commits/linux-efi-generic

Quoted 40 lines · Ard Biesheuvel

This series is another part of my effort to reduce the level of knowledge on the part of the bootloader or firmware of internal per-architecture details regarding where/how the kernel is loaded and where its initrd and other context data are passed.

The x86 architecture has a so-called 'EFI handover protocol', which defines how the bootparams struct should be populated, and how it should be interpreted to figure out where to load the kernel, and at which offset in the binary the entrypoint is located. This scheme allows the initrd to be loaded beforehand, and allows 32-bit firmware to invoke a 64-bit kernel via a special entrypoint that manages the state transitions between the two execution modes.

Due to this, x86 loaders currently do not rely on LoadImage and StartImage, and therefore, are forced to re-implement things like image authentication for secure boot and taking the measurements for measured boot in their open coded clones of these routines.

My previous series on this topic [0] implements a generic way to load the initrd from any source supported by the loader without relying on something like device trees or bootparams structures, and so native boot should not need the EFI handover protocol anymore after those change are merged.

What remains is mixed mode boot, which also needs the EFI handover protocol regardless of whether an initrd is loaded or not. So let's get rid of that requirement, and take advantage of the fact that EDK2 based firmware does support LoadImage() for X64 binaries on IA32 firmware, which means we can rely on the secure boot and measured boot checks being performed by the firmware. The only thing we need to put on top is a way to discover the non-native entrypoint into the binary in a way that does not rely on x86 specific headers and data structures.

So let's introduce a new .compat header in the PE/COFF metadata of the bzImage, and populate it with a <machine type, entrypoint> tuple, allowing a generic EFI loader to decide whether the entrypoint supports its native machine type, and invoke it as an ordinary EFI application entrypoint. Since we will not be passing a bootparams structure, we need to discover the base of the image (which contains the setup header) via the loaded image protocol before we can enter the kernel in 32-bit mode at startup_32()

Quoted 8 lines

A loader implementation for OVMF can be found at [1]. Note that this loader code is fully generic, and could be used without modifications if other architectures ever emerge that support kernels that can be invoked from a non-native (but cross-type supported) loader.

[0] https://lore.kernel.org/linux-arm-kernel/[email protected]/
[1] https://github.com/ardbiesheuvel/edk2/commits/linux-efi-generic

As an alternative to the new section, how about having a CONFIG option to emit the 64-bit kernel with a 32-bit PE header instead, which would point to efi32_pe_entry? In that case it could be directly loaded by existing firmware already. You could even have a tool that can mangle an existing bzImage's header from 64-bit to 32-bit, say using the newly added kernel_info structure to record the existence and location of efi32_pe_entry.

Also, the PE header can live anywhere inside the image, right? Is there any reason to struggle to shoehorn it into the "boot sector"?

Quoted 8 lines · Arvind Sankar

As an alternative to the new section, how about having a CONFIG option to emit the 64-bit kernel with a 32-bit PE header instead, which would point to efi32_pe_entry? In that case it could be directly loaded by existing firmware already. You could even have a tool that can mangle an existing bzImage's header from 64-bit to 32-bit, say using the newly added kernel_info structure to record the existence and location of efi32_pe_entry.

That wouldn't work with, say, signed distro kernels.

Quoted 3 lines

Also, the PE header can live anywhere inside the image, right? Is there any reason to struggle to shoehorn it into the "boot sector"?

It cannot. It must live outside a region described by the section headers.

Quoted 10 lines · Ard Biesheuvel

Quoted 8 lines · Arvind Sankar

As an alternative to the new section, how about having a CONFIG option to emit the 64-bit kernel with a 32-bit PE header instead, which would point to efi32_pe_entry? In that case it could be directly loaded by existing firmware already. You could even have a tool that can mangle an existing bzImage's header from 64-bit to 32-bit, say using the newly added kernel_info structure to record the existence and location of efi32_pe_entry.

Quoted 1 line

That wouldn't work with, say, signed distro kernels.

No, the idea would be that the distro would distribute two signed images, one 32-bit and one 64-bit, which are identical except for the header. At install time, the installer chooses based on the system's firmware bit-ness.

Quoted 5 lines

Quoted 3 lines

Also, the PE header can live anywhere inside the image, right? Is there any reason to struggle to shoehorn it into the "boot sector"?

It cannot. It must live outside a region described by the section headers.

It could still be inserted after .setup, or at the very end of the file, no?

Quoted 12 lines · Arvind Sankar

Quoted 10 lines · Ard Biesheuvel

Quoted 8 lines · Arvind Sankar

As an alternative to the new section, how about having a CONFIG option to emit the 64-bit kernel with a 32-bit PE header instead, which would point to efi32_pe_entry? In that case it could be directly loaded by existing firmware already. You could even have a tool that can mangle an existing bzImage's header from 64-bit to 32-bit, say using the newly added kernel_info structure to record the existence and location of efi32_pe_entry.

Quoted 7 lines

Quoted 1 line

That wouldn't work with, say, signed distro kernels.

No, the idea would be that the distro would distribute two signed images, one 32-bit and one 64-bit, which are identical except for the header. At install time, the installer chooses based on the system's firmware bit-ness.

I guess it would be possible, but then we'd need two different images while today, we can run the same image on both kinds of firmwares. The only thing I am trying to do is remove all the quirky bootparams stuff from the loader so that we can switch to LoadImage

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Also, the PE header can live anywhere inside the image, right? Is there any reason to struggle to shoehorn it into the "boot sector"?

Quoted 3 lines

Quoted 1 line

It cannot. It must live outside a region described by the section headers.

It could still be inserted after .setup, or at the very end of the file, no?

The PE/COFF spec mentions that the COFF header needs to follow the signature. Also, the SizeOfHeaders field would become somewhat ambiguous if the header is split up like that.

Quoted 21 lines · Ard Biesheuvel

Quoted 12 lines · Arvind Sankar

Quoted 10 lines · Ard Biesheuvel

Quoted 8 lines · Arvind Sankar

As an alternative to the new section, how about having a CONFIG option to emit the 64-bit kernel with a 32-bit PE header instead, which would point to efi32_pe_entry? In that case it could be directly loaded by existing firmware already. You could even have a tool that can mangle an existing bzImage's header from 64-bit to 32-bit, say using the newly added kernel_info structure to record the existence and location of efi32_pe_entry.

Quoted 7 lines

Quoted 1 line

That wouldn't work with, say, signed distro kernels.

No, the idea would be that the distro would distribute two signed images, one 32-bit and one 64-bit, which are identical except for the header. At install time, the installer chooses based on the system's firmware bit-ness.

Quoted 4 lines

I guess it would be possible, but then we'd need two different images while today, we can run the same image on both kinds of firmwares. The only thing I am trying to do is remove all the quirky bootparams stuff from the loader so that we can switch to LoadImage

Yeah, but doing that will allow you to boot directly from firmware on existing machines, and only one image needs to be chosen at install time, so it just adds a few MiB to the package. I guess most people will still use a boot manager or loader that can be easily enhanced to use LoadImage and the new section, but it would be nice to have the option to avoid that.

Quoted 27 lines · Arvind Sankar

Quoted 25 lines · Ard Biesheuvel

Quoted 12 lines · Arvind Sankar

Quoted 10 lines · Ard Biesheuvel

Quoted 8 lines · Arvind Sankar

As an alternative to the new section, how about having a CONFIG option to emit the 64-bit kernel with a 32-bit PE header instead, which would point to efi32_pe_entry? In that case it could be directly loaded by existing firmware already. You could even have a tool that can mangle an existing bzImage's header from 64-bit to 32-bit, say using the newly added kernel_info structure to record the existence and location of efi32_pe_entry.

Quoted 7 lines

Quoted 1 line

That wouldn't work with, say, signed distro kernels.

No, the idea would be that the distro would distribute two signed images, one 32-bit and one 64-bit, which are identical except for the header. At install time, the installer chooses based on the system's firmware bit-ness.

I guess it would be possible, but then we'd need two different images while today, we can run the same image on both kinds of firmwares. The only thing I am trying to do is remove all the quirky bootparams stuff from the loader so that we can switch to LoadImage

Quoted 6 lines

Yeah, but doing that will allow you to boot directly from firmware on existing machines, and only one image needs to be chosen at install time, so it just adds a few MiB to the package. I guess most people will still use a boot manager or loader that can be easily enhanced to use LoadImage and the new section, but it would be nice to have the option to avoid that.

Also not quite today, right? You still need this patchset and the modifications to bootloaders to get away with one image.

I see the value of having a 64-bit image that can boot natively on 32-bit firmware, but I am not expecting any buy in from the distros for this scheme.