arm64: head: pad Image header to 64 KB and unmap it

In a previous patch, we increased the size of the EFI PE/COFF header to 64 KB, which resulted in the _stext symbol to appear at a fixed offset of 64 KB into the image.

Since 64 KB is also the largest page size we support, this completely removes the need to map the first 64 KB of the kernel image, given that it only contains the arm64 Image header and the EFI header, none of which we ever access again after booting the kernel. More importantly, we should avoid an executable mapping of non-executable and not entirely predictable data, in the unlikely event that we emitted something that looks like an opcode that could be used as a gadget for speculative execution.

So let's limit the kernel mapping of .text to the [_stext, _etext) region, which matches the view of generic code (such as kallsyms) when it reasons about the boundaries of the kernel's .text section.

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

---
 arch/arm64/kernel/efi-header.S  |  7 -------
 arch/arm64/kernel/setup.c       |  4 ++--
 arch/arm64/kernel/vmlinux.lds.S |  2 +-
 arch/arm64/mm/init.c            |  2 +-
 arch/arm64/mm/mmu.c             | 10 +++++-----
 5 files changed, 9 insertions(+), 16 deletions(-)

We no longer map the first 64 KB of the kernel image, as there is nothing there that we ever need to refer back to once the kernel has booted. Even though facilities like kallsyms are very careful to only refer to the region that starts at _stext when mapping virtual addresses to symbol names, let's avoid any confusion by switching to local .L prefixed symbol names for the EFI header, as none of them have any significance to the rest of the kernel.

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

---
 arch/arm64/kernel/efi-header.S | 46 ++++++++++----------
 1 file changed, 22 insertions(+), 24 deletions(-)

Even though support for EFI boot remains entirely optional for arm64, it is unlikely that we will ever be able to repurpose the image header fields that the EFI loader relies on, i.e., the magic NOP at offset 0x0 and the PE header address at offset 0x3c.

So let's factor out the differences into a 'magic_nop' macro and a local symbol representing the PE header address, and move the conditional definitions into efi-header.S, taking into account whether CONFIG_EFI is enabled or not.

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

---
 arch/arm64/kernel/efi-header.S | 43 +++++++++++++++-----
 arch/arm64/kernel/head.S       | 19 +--------
 2 files changed, 35 insertions(+), 27 deletions(-)

arch/arm64/kernel/efi-header.S +0 -0

index ddaf57d825b5..7b7ac4316d95 100644
@@ -7,7 +7,27 @@
 #include <linux/pe.h>

Quoted 5 lines · Ard Biesheuvel

Even though support for EFI boot remains entirely optional for arm64, it is unlikely that we will ever be able to repurpose the image header fields that the EFI loader relies on, i.e., the magic NOP at offset 0x0 and the PE header address at offset 0x3c.

Quoted 4 lines

So let's factor out the differences into a 'magic_nop' macro and a local symbol representing the PE header address, and move the conditional definitions into efi-header.S, taking into account whether CONFIG_EFI is enabled or not.

How many architectures can claim to have both a "magic nop" and a "mysterious nop", hey?

Quoted 12 lines

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

---
  arch/arm64/kernel/efi-header.S | 43 +++++++++++++++-----
  arch/arm64/kernel/head.S       | 19 +--------
  2 files changed, 35 insertions(+), 27 deletions(-)

arch/arm64/kernel/efi-header.S +0 -0

index ddaf57d825b5..7b7ac4316d95 100644
@@ -7,7 +7,27 @@
  #include <linux/pe.h>

arch/arm64/kernel/efi-header.S line 17

Quoted 10 lines

arch/arm64/kernel/efi-header.S +8 -0

  #include <linux/sizes.h>
 
+	.macro	magic_nop
+#ifdef CONFIG_EFI
+.L_head:
+	/*
+	 * This add instruction has no meaningful effect except that
+	 * its opcode forms the magic "MZ" signature required by UEFI.
+	 */
+	add	x13, x18, #0x16

It's probably faster too ;)

arch/arm64/kernel/efi-header.S line 24

Quoted 7 lines

arch/arm64/kernel/efi-header.S +7 -0

+#else
+	/*
+	 * Bootloaders may inspect the opcode at the start of the kernel
+	 * image to decide if the kernel is capable of booting via UEFI.
+	 * So put an ordinary NOP here, not the "MZ.." pseudo-nop above.
+	 */
+	nop

Let's just hope nobody was decoding the branch instruction...

Acked-by Will Deacon >[email protected]>

Will

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 6 lines · Will Deacon

Quoted 5 lines · Ard Biesheuvel

Even though support for EFI boot remains entirely optional for arm64, it is unlikely that we will ever be able to repurpose the image header fields that the EFI loader relies on, i.e., the magic NOP at offset 0x0 and the PE header address at offset 0x3c.

Quoted 7 lines

Quoted 4 lines

So let's factor out the differences into a 'magic_nop' macro and a local symbol representing the PE header address, and move the conditional definitions into efi-header.S, taking into account whether CONFIG_EFI is enabled or not.

How many architectures can claim to have both a "magic nop" and a "mysterious nop", hey?

It's fun 'n'all, but putting my serious hat on for a moment, if the name still requires a comment to explain it at point of use, it's not a very good name :(

At worst magic_nop is even potentially misleading, since it's not necessarily a nop; there's no mention of the implicit dependency on a context where the side-effect of executing it wouldn't affect anything important.

Could we call the macro itself something clear and self-explanatory like efi_signature_insn please? I'm happy for it to be *commented* as "Magic NOP" if you want parity with the VDSO :D

Quoted 37 lines

Quoted 12 lines

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

---
  arch/arm64/kernel/efi-header.S | 43 +++++++++++++++-----
  arch/arm64/kernel/head.S       | 19 +--------
  2 files changed, 35 insertions(+), 27 deletions(-)

arch/arm64/kernel/efi-header.S +0 -0

index ddaf57d825b5..7b7ac4316d95 100644
@@ -7,7 +7,27 @@
  #include <linux/pe.h>

arch/arm64/kernel/efi-header.S line 17

Quoted 10 lines

arch/arm64/kernel/efi-header.S +8 -0

  #include <linux/sizes.h>
 
+    .macro  magic_nop
+#ifdef CONFIG_EFI
+.L_head:
+    /*
+     * This add instruction has no meaningful effect except that
+     * its opcode forms the magic "MZ" signature required by UEFI.
+     */
+    add     x13, x18, #0x16

It's probably faster too ;)

arch/arm64/kernel/efi-header.S line 24

Quoted 7 lines

arch/arm64/kernel/efi-header.S +7 -0

+#else
+    /*
+     * Bootloaders may inspect the opcode at the start of the kernel
+     * image to decide if the kernel is capable of booting via UEFI.
+     * So put an ordinary NOP here, not the "MZ.." pseudo-nop above.
+     */
+    nop

Let's just hope nobody was decoding the branch instruction...

Acked-by Will Deacon >[email protected]>

Quoted 7 lines

Will

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 25 lines · Robin Murphy

Quoted 6 lines · Will Deacon

Quoted 5 lines · Ard Biesheuvel

Even though support for EFI boot remains entirely optional for arm64, it is unlikely that we will ever be able to repurpose the image header fields that the EFI loader relies on, i.e., the magic NOP at offset 0x0 and the PE header address at offset 0x3c.

Quoted 7 lines

Quoted 4 lines

So let's factor out the differences into a 'magic_nop' macro and a local symbol representing the PE header address, and move the conditional definitions into efi-header.S, taking into account whether CONFIG_EFI is enabled or not.

How many architectures can claim to have both a "magic nop" and a "mysterious nop", hey?

It's fun 'n'all, but putting my serious hat on for a moment, if the name still requires a comment to explain it at point of use, it's not a very good name :(

At worst magic_nop is even potentially misleading, since it's not necessarily a nop; there's no mention of the implicit dependency on a context where the side-effect of executing it wouldn't affect anything important.

Quoted 4 lines

Could we call the macro itself something clear and self-explanatory like efi_signature_insn please? I'm happy for it to be *commented* as "Magic NOP" if you want parity with the VDSO :D

Will efi_pseudo_nop do?

Also, do you think it would be better to use an opcode here that has no architectural side effects, such as a PRFM (literal) instruction? It is obviously not going to make a difference in practice, but it always annoyed me that the pseudo NOP is not a NOP.

Quoted 37 lines

Quoted 37 lines

Quoted 12 lines

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

---
   arch/arm64/kernel/efi-header.S | 43 +++++++++++++++-----
   arch/arm64/kernel/head.S       | 19 +--------
   2 files changed, 35 insertions(+), 27 deletions(-)

arch/arm64/kernel/efi-header.S +0 -0

index ddaf57d825b5..7b7ac4316d95 100644
@@ -7,7 +7,27 @@
   #include <linux/pe.h>

arch/arm64/kernel/efi-header.S line 17

Quoted 10 lines

arch/arm64/kernel/efi-header.S +8 -0

   #include <linux/sizes.h>
 
+    .macro  magic_nop
+#ifdef CONFIG_EFI
+.L_head:
+    /*
+     * This add instruction has no meaningful effect except that
+     * its opcode forms the magic "MZ" signature required by UEFI.
+     */
+    add     x13, x18, #0x16

It's probably faster too ;)

arch/arm64/kernel/efi-header.S line 24

Quoted 7 lines

arch/arm64/kernel/efi-header.S +7 -0

+#else
+    /*
+     * Bootloaders may inspect the opcode at the start of the kernel
+     * image to decide if the kernel is capable of booting via UEFI.
+     * So put an ordinary NOP here, not the "MZ.." pseudo-nop above.
+     */
+    nop

Let's just hope nobody was decoding the branch instruction...

Acked-by Will Deacon >[email protected]>

Quoted 7 lines

Quoted 7 lines

Will

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 31 lines · Ard Biesheuvel

Quoted 29 lines · Robin Murphy

Quoted 6 lines · Will Deacon

Quoted 5 lines · Ard Biesheuvel

Even though support for EFI boot remains entirely optional for arm64, it is unlikely that we will ever be able to repurpose the image header fields that the EFI loader relies on, i.e., the magic NOP at offset 0x0 and the PE header address at offset 0x3c.

Quoted 7 lines

Quoted 4 lines

So let's factor out the differences into a 'magic_nop' macro and a local symbol representing the PE header address, and move the conditional definitions into efi-header.S, taking into account whether CONFIG_EFI is enabled or not.

How many architectures can claim to have both a "magic nop" and a "mysterious nop", hey?

It's fun 'n'all, but putting my serious hat on for a moment, if the name still requires a comment to explain it at point of use, it's not a very good name :(

At worst magic_nop is even potentially misleading, since it's not necessarily a nop; there's no mention of the implicit dependency on a context where the side-effect of executing it wouldn't affect anything important.

Could we call the macro itself something clear and self-explanatory like efi_signature_insn please? I'm happy for it to be *commented* as "Magic NOP" if you want parity with the VDSO :D

Quoted 1 line

Will efi_pseudo_nop do?

Again, what's the defining significance of the instruction that this macro stands for - that it does nothing; that it does pseudo-nothing; or that it has a specific signature encoding? I know this probably sounds like bikeshedding to most, but I firmly believe that good, accurate names really do matter :)

Quoted 4 lines

Also, do you think it would be better to use an opcode here that has no architectural side effects, such as a PRFM (literal) instruction? It is obviously not going to make a difference in practice, but it always annoyed me that the pseudo NOP is not a NOP.

Yeah, it's a shame there's no way to get a guaranteed non-taken conditional branch in A64, and nearly every good candidate for a non-destructive operation with an arbitrary immediate seems to rely on an rt=31 encoding... 'prfm PLIL3STRM, . + 2888' is utterly impenetrable, but should indeed work; 'ccmp x18, #0, #0xd, pl' is probably the least destructive ALU option (only a chance of changing the flags).

Quoted 38 lines

Quoted 38 lines

Quoted 38 lines

Quoted 13 lines

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

---
   arch/arm64/kernel/efi-header.S | 43 +++++++++++++++-----
   arch/arm64/kernel/head.S       | 19 +--------
   2 files changed, 35 insertions(+), 27 deletions(-)

arch/arm64/kernel/efi-header.S +0 -0

index ddaf57d825b5..7b7ac4316d95 100644
@@ -7,7 +7,27 @@
   #include <linux/pe.h>

arch/arm64/kernel/efi-header.S line 17

Quoted 10 lines

arch/arm64/kernel/efi-header.S +8 -0

   #include <linux/sizes.h>
 
+    .macro  magic_nop
+#ifdef CONFIG_EFI
+.L_head:
+    /*
+     * This add instruction has no meaningful effect except that
+     * its opcode forms the magic "MZ" signature required by UEFI.
+     */
+    add     x13, x18, #0x16

It's probably faster too ;)

arch/arm64/kernel/efi-header.S line 24

Quoted 7 lines

arch/arm64/kernel/efi-header.S +7 -0

+#else
+    /*
+     * Bootloaders may inspect the opcode at the start of the kernel
+     * image to decide if the kernel is capable of booting via UEFI.
+     * So put an ordinary NOP here, not the "MZ.." pseudo-nop above.
+     */
+    nop

Let's just hope nobody was decoding the branch instruction...

Acked-by Will Deacon >[email protected]>

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Will

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 33 lines · Robin Murphy

Quoted 31 lines · Ard Biesheuvel

Quoted 29 lines · Robin Murphy

Quoted 6 lines · Will Deacon

Quoted 5 lines · Ard Biesheuvel

Even though support for EFI boot remains entirely optional for arm64, it is unlikely that we will ever be able to repurpose the image header fields that the EFI loader relies on, i.e., the magic NOP at offset 0x0 and the PE header address at offset 0x3c.

Quoted 7 lines

Quoted 4 lines

So let's factor out the differences into a 'magic_nop' macro and a local symbol representing the PE header address, and move the conditional definitions into efi-header.S, taking into account whether CONFIG_EFI is enabled or not.

How many architectures can claim to have both a "magic nop" and a "mysterious nop", hey?

It's fun 'n'all, but putting my serious hat on for a moment, if the name still requires a comment to explain it at point of use, it's not a very good name :(

At worst magic_nop is even potentially misleading, since it's not necessarily a nop; there's no mention of the implicit dependency on a context where the side-effect of executing it wouldn't affect anything important.

Could we call the macro itself something clear and self-explanatory like efi_signature_insn please? I'm happy for it to be *commented* as "Magic NOP" if you want parity with the VDSO :D

Quoted 8 lines

Quoted 1 line

Will efi_pseudo_nop do?

Again, what's the defining significance of the instruction that this macro stands for - that it does nothing; that it does pseudo-nothing; or that it has a specific signature encoding? I know this probably sounds like bikeshedding to most, but I firmly believe that good, accurate names really do matter :)

Fair enough. But by that reasoning, putting NOP in the name is important, given that efi_signature_insn does not explain what the instruction does.

So, efi_signature_nop then?

Quoted 5 lines

Quoted 4 lines

Also, do you think it would be better to use an opcode here that has no architectural side effects, such as a PRFM (literal) instruction? It is obviously not going to make a difference in practice, but it always annoyed me that the pseudo NOP is not a NOP.

Quoted 7 lines

Yeah, it's a shame there's no way to get a guaranteed non-taken conditional branch in A64, and nearly every good candidate for a non-destructive operation with an arbitrary immediate seems to rely on an rt=31 encoding... 'prfm PLIL3STRM, . + 2888' is utterly impenetrable, but should indeed work; 'ccmp x18, #0, #0xd, pl' is probably the least destructive ALU option (only a chance of changing the flags).

I think ccmp is probably a better choice, given that PRFM PLI instructions issued with the MMU off are more likely to trigger something unexpected.

Quoted 37 lines

Quoted 37 lines

Quoted 37 lines

Quoted 37 lines

Quoted 12 lines

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

---
    arch/arm64/kernel/efi-header.S | 43 +++++++++++++++-----
    arch/arm64/kernel/head.S       | 19 +--------
    2 files changed, 35 insertions(+), 27 deletions(-)

arch/arm64/kernel/efi-header.S +0 -0

index ddaf57d825b5..7b7ac4316d95 100644
@@ -7,7 +7,27 @@
    #include <linux/pe.h>

arch/arm64/kernel/efi-header.S line 17

Quoted 10 lines

arch/arm64/kernel/efi-header.S +8 -0

    #include <linux/sizes.h>
 
+    .macro  magic_nop
+#ifdef CONFIG_EFI
+.L_head:
+    /*
+     * This add instruction has no meaningful effect except that
+     * its opcode forms the magic "MZ" signature required by UEFI.
+     */
+    add     x13, x18, #0x16

It's probably faster too ;)

arch/arm64/kernel/efi-header.S line 24

Quoted 7 lines

arch/arm64/kernel/efi-header.S +7 -0

+#else
+    /*
+     * Bootloaders may inspect the opcode at the start of the kernel
+     * image to decide if the kernel is capable of booting via UEFI.
+     * So put an ordinary NOP here, not the "MZ.." pseudo-nop above.
+     */
+    nop

Let's just hope nobody was decoding the branch instruction...

Acked-by Will Deacon >[email protected]>

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Will

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

The EFI header definition was updated recently to increase the section alignment to 64 KB, which causes the EFI loader to put the kernel Image at an offset that is guaranteed to be compatible with the kernel's image placement policy when CONFIG_RELOCATABLE=y, removing the need to move it around in DRAM before boot.

This change failed to take into account that the first section in the PE/COFF description should start at a 64 KB aligned boundary as well, and so even though EFI loaders don't seem to care, the current PE/COFF layout is not 100% compliant.

[...]