From: Ard Biesheuvel <ardb@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-efi@vger.kernel.org, keescook@chromium.org,
Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Subject: [PATCH v5 6/7] arm64: lds: reduce effective minimum image alignment to 64k
Date: Tue, 8 Nov 2022 19:22:03 +0100 [thread overview]
Message-ID: <20221108182204.2447664-7-ardb@kernel.org> (raw)
In-Reply-To: <20221108182204.2447664-1-ardb@kernel.org>
Our segment alignment is 64k for all configurations, and coincidentally,
this is the largest alignment supported by the PE/COFF executable
format used by EFI. This means that generally, there is no need to move
the image around in memory after it has been loaded by the firmware,
which can be advantageous as it also permits us to rely on the memory
attributes set by the firmware (R-X for [_text, __inittext_end] and RW-
for [__initdata_begin, _end].
However, the minimum alignment of the image is actually 128k on 64k
pages configurations with CONFIG_VMAP_STACK=y, due to the existence of a
single 128k aligned object in the image, which is the stack of the init
task.
Let's work around this by adding some padding before the init stack
allocation, so we can round down the stack pointer to a suitably aligned
value if the image is not aligned to 128k in memory.
Note that this does not affect the boot protocol, which still requires 2
MiB alignment for bare metal boot, but is only part of the internal
contract between the EFI stub and the kernel proper.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/include/asm/efi.h | 9 +--------
arch/arm64/kernel/head.S | 3 +++
arch/arm64/kernel/vmlinux.lds.S | 11 ++++++++++-
include/linux/efi.h | 6 +-----
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 108b115dbf5b7436..7ed7a0e621a5b0b6 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -54,13 +54,6 @@ efi_status_t __efi_rt_asm_wrapper(void *, const char *, ...);
/* arch specific definitions used by the stub code */
-/*
- * In some configurations (e.g. VMAP_STACK && 64K pages), stacks built into the
- * kernel need greater alignment than we require the segments to be padded to.
- */
-#define EFI_KIMG_ALIGN \
- (SEGMENT_ALIGN > THREAD_ALIGN ? SEGMENT_ALIGN : THREAD_ALIGN)
-
/*
* On arm64, we have to ensure that the initrd ends up in the linear region,
* which is a 1 GB aligned region of size '1UL << (VA_BITS_MIN - 1)' that is
@@ -88,7 +81,7 @@ static inline unsigned long efi_get_kimg_min_align(void)
* 2M alignment if KASLR was explicitly disabled, even if it was not
* going to be activated to begin with.
*/
- return efi_nokaslr ? MIN_KIMG_ALIGN : EFI_KIMG_ALIGN;
+ return efi_nokaslr ? MIN_KIMG_ALIGN : SEGMENT_ALIGN;
}
#define EFI_ALLOC_ALIGN SZ_64K
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 825f1d0549661030..8d7c6155da59e215 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -429,6 +429,9 @@ SYM_FUNC_END(create_kernel_mapping)
msr sp_el0, \tsk
ldr \tmp1, [\tsk, #TSK_STACK]
+#if THREAD_ALIGN > SEGMENT_ALIGN
+ bic \tmp1, \tmp1, #THREAD_ALIGN - 1
+#endif
add sp, \tmp1, #THREAD_SIZE
sub sp, sp, #PT_REGS_SIZE
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index c7727a1740ce11f5..5002d869fa7f1767 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -274,7 +274,16 @@ SECTIONS
_data = .;
_sdata = .;
- RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN)
+#if THREAD_ALIGN > SEGMENT_ALIGN
+ /*
+ * Add some padding for the init stack so we can fix up any potential
+ * misalignment at runtime. In practice, this can only occur on 64k
+ * pages configurations with CONFIG_VMAP_STACK=y.
+ */
+ . += THREAD_ALIGN - SEGMENT_ALIGN;
+ ASSERT(. == init_stack, "init_stack not at start of RW_DATA as expected")
+#endif
+ RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, SEGMENT_ALIGN)
/*
* Data written with the MMU off but read with the MMU on requires
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 16b7318957b0709f..19eda0bb4617a4cf 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -421,11 +421,7 @@ void efi_native_runtime_setup(void);
/*
* This GUID may be installed onto the kernel image's handle as a NULL protocol
* to signal to the stub that the placement of the image should be respected,
- * and moving the image in physical memory is undesirable. To ensure
- * compatibility with 64k pages kernels with virtually mapped stacks, and to
- * avoid defeating physical randomization, this protocol should only be
- * installed if the image was placed at a randomized 128k aligned address in
- * memory.
+ * and moving the image in physical memory is undesirable.
*/
#define LINUX_EFI_LOADED_IMAGE_FIXED_GUID EFI_GUID(0xf5a37b6d, 0x3344, 0x42a5, 0xb6, 0xbb, 0x97, 0x86, 0x48, 0xc1, 0x89, 0x0a)
--
2.35.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-11-08 18:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 18:21 [PATCH v5 0/7] arm64: efi: leave MMU and caches on at boot Ard Biesheuvel
2022-11-08 18:21 ` [PATCH v5 1/7] arm64: head: Move all finalise_el2 calls to after __enable_mmu Ard Biesheuvel
2022-11-08 18:21 ` [PATCH v5 2/7] arm64: kernel: move identity map out of .text mapping Ard Biesheuvel
2022-11-08 18:22 ` [PATCH v5 3/7] arm64: head: record the MMU state at primary entry Ard Biesheuvel
2022-11-08 18:22 ` [PATCH v5 4/7] arm64: head: avoid cache invalidation when entering with the MMU on Ard Biesheuvel
2022-11-08 18:22 ` [PATCH v5 5/7] arm64: head: Clean the ID map and the HYP text to the PoC if needed Ard Biesheuvel
2022-11-08 22:11 ` Ard Biesheuvel
2022-11-08 18:22 ` Ard Biesheuvel [this message]
2022-11-08 18:22 ` [PATCH v5 7/7] efi: arm64: enter with MMU and caches enabled Ard Biesheuvel
2022-11-11 17:36 ` [PATCH v5 0/7] arm64: efi: leave MMU and caches on at boot Mark Rutland
2022-11-15 11:17 ` Will Deacon
2022-11-15 11:21 ` Ard Biesheuvel
2022-11-15 11:31 ` Will Deacon
2022-11-26 14:16 ` Ard Biesheuvel
2022-11-26 14:17 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221108182204.2447664-7-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).