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

In commit

c7fb93ec51d462ec ("x86/efi: Include a .bss section within the PE/COFF headers")

we added a separate .bss section to the PE/COFF header of the compressed kernel describing the static memory footprint of the decompressor, to ensure that it has enough headroom to decompress itself.

We can achieve the exact same result by increasing the virtual size of the .text section, without changing the raw size, which, as per the PE/COFF specification, requires the loader to zero initialize the delta.

Doing so frees up a slot in the section table, which we will use later to describe the mixed mode entrypoint.

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

---
 arch/x86/boot/header.S      | 21 +-----------
 arch/x86/boot/tools/build.c | 35 ++++++++------------
 2 files changed, 14 insertions(+), 42 deletions(-)

arch/x86/boot/tools/build.c +3 -8

index 55e669d29e54..0c8c5a52f1f0 100644
@@ -203,10 +203,12 @@ static void update_pecoff_setup_and_reloc(unsigned int size)
 	put_unaligned_le32(10, &buf[reloc_offset + 4]);
 }
 
-static void update_pecoff_text(unsigned int text_start, unsigned int file_sz)
+static void update_pecoff_text(unsigned int text_start, unsigned int file_sz,
+			       unsigned int init_sz)
 {
 	unsigned int pe_header;
 	unsigned int text_sz = file_sz - text_start;
+	unsigned int bss_sz = init_sz - file_sz;
 
 	pe_header = get_unaligned_le32(&buf[0x3c]);
 

@@ -216,28 +218,19 @@ static void update_pecoff_text(unsigned int text_start, unsigned int file_sz)
 	 */
 	put_unaligned_le32(file_sz - 512, &buf[pe_header + 0x1c]);
 
-	/*
-	 * Address of entry point for PE/COFF executable
-	 */
-	put_unaligned_le32(text_start + efi_pe_entry, &buf[pe_header + 0x28]);
-
-	update_pecoff_section_header(".text", text_start, text_sz);
-}

Quoted 55 lines · Ard Biesheuvel

In commit

c7fb93ec51d462ec ("x86/efi: Include a .bss section within the PE/COFF headers")

we added a separate .bss section to the PE/COFF header of the compressed kernel describing the static memory footprint of the decompressor, to ensure that it has enough headroom to decompress itself.

We can achieve the exact same result by increasing the virtual size of the .text section, without changing the raw size, which, as per the PE/COFF specification, requires the loader to zero initialize the delta.

Doing so frees up a slot in the section table, which we will use later to describe the mixed mode entrypoint.

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

---
 arch/x86/boot/header.S      | 21 +-----------
 arch/x86/boot/tools/build.c | 35 ++++++++------------
 2 files changed, 14 insertions(+), 42 deletions(-)

arch/x86/boot/tools/build.c +3 -13

index 55e669d29e54..0c8c5a52f1f0 100644
@@ -203,10 +203,12 @@ static void update_pecoff_setup_and_reloc(unsigned int size)
      put_unaligned_le32(10, &buf[reloc_offset + 4]);
 }
 
-static void update_pecoff_text(unsigned int text_start, unsigned int file_sz)
+static void update_pecoff_text(unsigned int text_start, unsigned int file_sz,
+                            unsigned int init_sz)
 {
      unsigned int pe_header;
      unsigned int text_sz = file_sz - text_start;
+     unsigned int bss_sz = init_sz - file_sz;
 
      pe_header = get_unaligned_le32(&buf[0x3c]);
 

@@ -216,28 +218,19 @@ static void update_pecoff_text(unsigned int text_start, unsigned int file_sz)
       */
      put_unaligned_le32(file_sz - 512, &buf[pe_header + 0x1c]);
 
-     /*
-      * Address of entry point for PE/COFF executable
-      */
-     put_unaligned_le32(text_start + efi_pe_entry, &buf[pe_header + 0x28]);
-
-     update_pecoff_section_header(".text", text_start, text_sz);
-}
-
-static void update_pecoff_bss(unsigned int file_sz, unsigned int init_sz)
-{
-     unsigned int pe_header;
-     unsigned int bss_sz = init_sz - file_sz;

arch/x86/boot/tools/build.c static void update_pecoff_text(unsigned int text_start, unsigned int file_sz) · line 222

Quoted 5 lines

arch/x86/boot/tools/build.c +0 -3

-
-     pe_header = get_unaligned_le32(&buf[0x3c]);
-
      /* Size of uninitialized data */
      put_unaligned_le32(bss_sz, &buf[pe_header + 0x24]);

Should this still be populated given that there's no .bss section any more?

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 or allocate the setup block, etc etc, all of which can be done by the stub itself, using code that already exists.

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 service 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]>

Quoted 21 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 or allocate the setup block, etc etc, all of which can be done by the stub itself, using code that already exists.

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

Quoted 1 line

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

I think there's one issue with this. startup_32 is 14KiB from the start of the image because of .setup. This means the code in startup_32 that rounds the load address up to kernel_alignment will likely calculate it as 2MiB from the image address (if the image address was 2MiB-aligned), and the page tables constructed by the 32-bit code will be beyond the space allocated for the image.

I think the simplest fix would be to increase SizeOfImage by kernel_alignment to allow enough slop space for the alignment.

We should
also increase it by text_start, since we need init_size beginning from startup_32, not from the image address.

Quoted 23 lines · Arvind Sankar

Quoted 21 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 or allocate the setup block, etc etc, all of which can be done by the stub itself, using code that already exists.

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

Quoted 9 lines

Quoted 1 line

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

I think there's one issue with this. startup_32 is 14KiB from the start of the image because of .setup. This means the code in startup_32 that rounds the load address up to kernel_alignment will likely calculate it as 2MiB from the image address (if the image address was 2MiB-aligned), and the page tables constructed by the 32-bit code will be beyond the space allocated for the image.

Right. Image address could be any multiple of 4 KB so we'll have to deal with that.

Quoted 2 lines

I think the simplest fix would be to increase SizeOfImage by kernel_alignment to allow enough slop space for the alignment.

So we basically need at least 2 MB - 14 KB slack at the top, right? That's easily done.

Quoted 3 lines

We should
also increase it by text_start, since we need init_size beginning from startup_32, not from the image address.

So something like the below?

arch/x86/boot/tools/build.c +11 -2

@@ -236,14 +236,23 @@
 
        pe_header = get_unaligned_le32(&buf[0x3c]);
 
+#ifdef CONFIG_EFI_MIXED
+       /*
+        * In order for startup_32 to safely execute in place, we need to give
+        * it a bit of headroom to create its page tables.
+        */
+       bss_sz += text_start + CONFIG_PHYSICAL_ALIGN;
+       init_sz += text_start + CONFIG_PHYSICAL_ALIGN;
+#endif
+
        /*
         * Size of code: Subtract the size of the first sector (512 bytes)
         * which includes the header.
         */
-       put_unaligned_le32(file_sz - 512, &buf[pe_header + 0x1c]);
+       put_unaligned_le32(file_sz + bss_sz- 512, &buf[pe_header + 0x1c]);
 
        /* Size of uninitialized data */
-       put_unaligned_le32(bss_sz, &buf[pe_header + 0x24]);
+       put_unaligned_le32(0, &buf[pe_header + 0x24]);
 
        /* Size of image */
        put_unaligned_le32(init_sz, &buf[pe_header + 0x50]);

Quoted 47 lines · Ard Biesheuvel

Quoted 23 lines · Arvind Sankar

Quoted 21 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 or allocate the setup block, etc etc, all of which can be done by the stub itself, using code that already exists.

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

Quoted 9 lines

Quoted 1 line

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

I think there's one issue with this. startup_32 is 14KiB from the start of the image because of .setup. This means the code in startup_32 that rounds the load address up to kernel_alignment will likely calculate it as 2MiB from the image address (if the image address was 2MiB-aligned), and the page tables constructed by the 32-bit code will be beyond the space allocated for the image.

Right. Image address could be any multiple of 4 KB so we'll have to deal with that.

Quoted 2 lines

I think the simplest fix would be to increase SizeOfImage by kernel_alignment to allow enough slop space for the alignment.

So we basically need at least 2 MB - 14 KB slack at the top, right? That's easily done.

Quoted 3 lines

We should
also increase it by text_start, since we need init_size beginning from startup_32, not from the image address.

Quoted 1 line

So something like the below?

Yup.

You might as well do the text_start bit unconditionally I think? If by some blind stroke of luck startup_32 ends up at pref_address and so we don't call efi_relocate_kernel, we'll need the room.