arm64: simplify restrictions on bootloaders

Currently __turn_mmu_on is aligned to 64 bytes to ensure that it doesn't span any page boundary, which simplifies the idmap and spares us requiring an additional page table to map half of the function. In keeping with other important requirements in architecture code, this fact is undocumented.

Additionally, as the function consists of three instructions totalling 12 bytes with no literal pool data, a smaller alignment of 16 bytes would be sufficient.

This patch reduces the alignment to 16 bytes and documents the underlying reason for the alignment. This reduces the required alignment of the entire .head.text section from 64 bytes to 16 bytes, though it may still be aligned to a larger value depending on TEXT_OFFSET.

Signed-off-by Mark Rutland <[email protected]>

---
 arch/arm64/kernel/head.S | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/arm64/kernel/head.S +1 -0

index 0fd5650..e8e9883 100644
@@ -346,8 +346,13 @@ ENDPROC(__enable_mmu)
  *  x27 = *virtual* address to jump to upon completion
  *
  * other registers depend on the function called upon completion
+ *

Currently __turn_mmu_on is aligned to 64 bytes to ensure that it doesn't span any page boundary, which simplifies the idmap and spares us requiring an additional page table to map half of the function. In keeping with other important requirements in architecture code, this fact is undocumented.

Additionally, as the function consists of three instructions totalling 12 bytes with no literal pool data, a smaller alignment of 16 bytes would be sufficient.

This patch reduces the alignment to 16 bytes and documents the underlying reason for the alignment. This reduces the required alignment of the entire .head.text section from 64 bytes to 16 bytes, though it may still be aligned to a larger value depending on TEXT_OFFSET.

Signed-off-by Mark Rutland <[email protected]>

---
 arch/arm64/kernel/head.S | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/arm64/kernel/head.S +1 -0

index 0fd5650..e8e9883 100644
@@ -346,8 +346,13 @@ ENDPROC(__enable_mmu)
  *  x27 = *virtual* address to jump to upon completion
  *
  * other registers depend on the function called upon completion
+ *

Currently we place swapper_pg_dir and idmap_pg_dir below the kernel image, between PHYS_OFFSET and (PHYS_OFFSET + TEXT_OFFSET). However, bootloaders may use portions of this memory below the kernel and we do not parse the memory reservation list until after the MMU has been enabled. As such we may clobber some memory a bootloader wishes to have preserved.

To enable the use of all of this memory by bootloaders (when the required memory reservations are communicated to the kernel) it is necessary to move our initial page tables elsewhere. As we currently have an effectively unbound requirement for memory at the end of the kernel image for .bss, we can place the page tables here.

This patch moves the initial page table to the end of the kernel image, after the BSS. As they do not consist of any initialised data they will be stripped from the kernel Image as with the BSS. The BSS clearing routine is updated to stop at __bss_stop rather than _end so as to not clobber the page tables, and memory reservations made redundant by the new organisation are removed.

Signed-off-by Mark Rutland <[email protected]>

---
 arch/arm64/include/asm/page.h   |  9 +++++++++
 arch/arm64/kernel/head.S        | 28 ++++++++--------------------
 arch/arm64/kernel/vmlinux.lds.S |  7 +++++++
 arch/arm64/mm/init.c            | 12 ++++--------
 4 files changed, 28 insertions(+), 28 deletions(-)

arch/arm64/include/asm/page.h +9 -0

index 46bf666..a6331e6 100644
@@ -31,6 +31,15 @@
 /* We do define AT_SYSINFO_EHDR but don't use the gate mechanism */
 #define __HAVE_ARCH_GATE_AREA		1
 
+/*
+ * The idmap and swapper page tables need some space reserved in the kernel
+ * image. The idmap only requires a pgd and a next level table to (section) map
+ * the kernel, while the swapper also maps the FDT and requires an additional
+ * table to map an early UART. See __create_page_tables for more information.
+ */
+#define SWAPPER_DIR_SIZE	(3 * PAGE_SIZE)
+#define IDMAP_DIR_SIZE		(2 * PAGE_SIZE)
+
 #ifndef __ASSEMBLY__
 
 #ifdef CONFIG_ARM64_64K_PAGES

arch/arm64/kernel/head.S +8 -20

index e8e9883..5dd8127 100644
@@ -35,29 +35,17 @@
 #include <asm/page.h>
 #include <asm/virt.h>
 
-/*
- * swapper_pg_dir is the virtual address of the initial page table. We place
- * the page tables 3 * PAGE_SIZE below KERNEL_RAM_VADDR. The idmap_pg_dir has
- * 2 pages and is placed below swapper_pg_dir.
- */
 #define KERNEL_RAM_VADDR	(PAGE_OFFSET + TEXT_OFFSET)
 
 #if (KERNEL_RAM_VADDR & 0xfffff) != 0x80000
 #error KERNEL_RAM_VADDR must start at 0xXXX80000
 #endif
 
-#define SWAPPER_DIR_SIZE	(3 * PAGE_SIZE)
-#define IDMAP_DIR_SIZE		(2 * PAGE_SIZE)
-
-	.globl	swapper_pg_dir
-	.equ	swapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE
-
-	.globl	idmap_pg_dir
-	.equ	idmap_pg_dir, swapper_pg_dir - IDMAP_DIR_SIZE
-
-	.macro	pgtbl, ttb0, ttb1, phys
-	add	\ttb1, \phys, #TEXT_OFFSET - SWAPPER_DIR_SIZE
-	sub	\ttb0, \ttb1, #IDMAP_DIR_SIZE
+	.macro	pgtbl, ttb0, ttb1, virt_to_phys
+	ldr	\ttb1, =swapper_pg_dir
+	ldr	\ttb0, =idmap_pg_dir
+	add	\ttb1, \ttb1, \virt_to_phys
+	add	\ttb0, \ttb0, \virt_to_phys
 	.endm
 
 #ifdef CONFIG_ARM64_64K_PAGES

@@ -304,7 +292,7 @@ ENTRY(secondary_startup)
 	mov	x23, x0				// x23=current cpu_table
 	cbz	x23, __error_p			// invalid processor (x23=0)?
 
-	pgtbl	x25, x26, x24			// x25=TTBR0, x26=TTBR1
+	pgtbl	x25, x26, x28			// x25=TTBR0, x26=TTBR1
 	ldr	x12, [x23, #CPU_INFO_SETUP]
 	add	x12, x12, x28			// __virt_to_phys
 	blr	x12				// initialise processor

@@ -418,7 +406,7 @@ ENDPROC(__calc_phys_offset)
  *   - pgd entry for fixed mappings (TTBR1)
  */
 __create_page_tables:
-	pgtbl	x25, x26, x24			// idmap_pg_dir and swapper_pg_dir addresses
+	pgtbl	x25, x26, x28			// idmap_pg_dir and swapper_pg_dir addresses
 	mov	x27, lr
 
 	/*

@@ -507,7 +495,7 @@ ENDPROC(__create_page_tables)
 __switch_data:
 	.quad	__mmap_switched
 	.quad	__bss_start			// x6
-	.quad	_end				// x7
+	.quad	__bss_stop			// x7
 	.quad	processor_id			// x4
 	.quad	__fdt_pointer			// x5
 	.quad	memstart_addr			// x6

arch/arm64/kernel/vmlinux.lds.S +7 -0

index 4ba7a55..51258bc 100644
@@ -104,6 +104,13 @@ SECTIONS
 	_edata = .;
 
 	BSS_SECTION(0, 0, 0)
+
+	. = ALIGN(PAGE_SIZE);
+	idmap_pg_dir = .;
+	. += IDMAP_DIR_SIZE;
+	swapper_pg_dir = .;
+	. += SWAPPER_DIR_SIZE;
+
 	_end = .;
 
 	STABS_DEBUG

arch/arm64/mm/init.c +4 -1

index 51d5352..cc3339d 100644
@@ -128,20 +128,16 @@ void __init arm64_memblock_init(void)
 {
 	u64 *reserve_map, base, size;
 
-	/* Register the kernel text, kernel data and initrd with memblock */
+	/*
+	 * Register the kernel text, kernel data, initrd, and initial
+	 * pagetables with memblock.
+	 */
 	memblock_reserve(__pa(_text), _end - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
 	if (initrd_start)
 		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
 #endif
 

Currently the kernel Image is stripped of everything past the initial stack, and at runtime the memory is initialised and used by the kernel. This makes the effective minimum memory footprint of the kernel larger than the size of the loaded binary, though bootloaders have no mechanism to identify how large this minimum memory footprint is. This makes it difficult to choose safe locations to place both the kernel and other binaries required at boot (DTB, initrd, etc), such that the kernel won't clobber said binaries or other reserved memory during initialisation.

Additionally when big endian support was added the image load offset was overlooked, and is currently of an arbitrary endianness, which makes it difficult for bootloaders to make use of it. It seems that bootloaders aren't respecting the image load offset at present anyway, and are assuming that offset 0x80000 will always be correct.

This patch adds an effective image size to the kernel header which describes the amount of memory from the start of the kernel Image binary which the kernel expects to use before detecting memory and handling any memory reservations. This can be used by bootloaders to choose suitable locations to load the kernel and/or other binaries such that the kernel will not clobber any memory unexpectedly. As before, memory reservations are required to prevent the kernel from clobbering these locations later.

Both the image load offset and the effective image size are forced to be little-endian regardless of the native endianness of the kernel to enable bootloaders to load a kernel of arbitrary endianness. Bootloaders which wish to make use of the load offset can inspect the effective image size field for a non-zero value to determine if the offset is of a known endianness.

The documentation is updated to clarify these details. To discourage future assumptions regarding the value of text_offset, the value at this point in time is removed from the main flow of the documentation (though kept as a compatibility note).

Signed-off-by Mark Rutland <[email protected]>

Currently the kernel Image is stripped of everything past the initial stack, and at runtime the memory is initialised and used by the kernel. This makes the effective minimum memory footprint of the kernel larger than the size of the loaded binary, though bootloaders have no mechanism to identify how large this minimum memory footprint is. This makes it difficult to choose safe locations to place both the kernel and other binaries required at boot (DTB, initrd, etc), such that the kernel won't clobber said binaries or other reserved memory during initialisation.

Additionally when big endian support was added the image load offset was overlooked, and is currently of an arbitrary endianness, which makes it difficult for bootloaders to make use of it. It seems that bootloaders aren't respecting the image load offset at present anyway, and are assuming that offset 0x80000 will always be correct.

This patch adds an effective image size to the kernel header which describes the amount of memory from the start of the kernel Image binary which the kernel expects to use before detecting memory and handling any memory reservations. This can be used by bootloaders to choose suitable locations to load the kernel and/or other binaries such that the kernel will not clobber any memory unexpectedly. As before, memory reservations are required to prevent the kernel from clobbering these locations later.

Both the image load offset and the effective image size are forced to be little-endian regardless of the native endianness of the kernel to enable bootloaders to load a kernel of arbitrary endianness. Bootloaders which wish to make use of the load offset can inspect the effective image size field for a non-zero value to determine if the offset is of a known endianness.

The documentation is updated to clarify these details. To discourage future assumptions regarding the value of text_offset, the value at this point in time is removed from the main flow of the documentation (though kept as a compatibility note).

Signed-off-by Mark Rutland <[email protected]>

---
 Documentation/arm64/booting.txt | 28 +++++++++++++++++++++++-----
 arch/arm64/kernel/head.S        |  4 ++--
 arch/arm64/kernel/vmlinux.lds.S | 28 ++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+), 7 deletions(-)

Documentation/arm64/booting.txt +23 -5

index beb754e..0d8201c 100644
@@ -72,8 +72,8 @@ The decompressed kernel image contains a 64-byte header as follows:
 
   u32 code0;			/* Executable code */
   u32 code1;			/* Executable code */
-  u64 text_offset;		/* Image load offset */
-  u64 res0	= 0;		/* reserved */
+  u64 text_offset;		/* Image load offset, little endian */
+  u64 image_size;		/* Effective Image size, little endian */
   u64 res1	= 0;		/* reserved */
   u64 res2	= 0;		/* reserved */
   u64 res3	= 0;		/* reserved */

@@ -86,9 +86,27 @@ Header notes:
 
 - code0/code1 are responsible for branching to stext.
 
-The image must be placed at the specified offset (currently 0x80000)
-from the start of the system RAM and called there. The start of the
-system RAM must be aligned to 2MB.
+- Older kernel versions did not define the endianness of text_offset.
+  In these cases image_size is zero and text_offset is 0x80000 in the
+  endianness of the kernel. Where image_size is non-zero image_size is
+  little-endian and must be respected.
+
+- When image_size is zero, a bootloader should attempt to keep as much
+  memory as possible free for use by the kernel immediately after the
+  end of the kernel image. Typically 1MB should be sufficient for this
+  case.
+
+The Image must be placed text_offset bytes from a 2MB aligned base
+address near the start of usable system RAM and called there. Memory
+below that base address is currently unusable by Linux, and therefore it
+is strongly recommended that this location is the start of system RAM.
+At least image_size bytes from the start of the image must be free for
+use by the kernel.
+
+Any memory described to the kernel (even that below the 2MB aligned base
+address) which is not marked as reserved from the kernel e.g. with a
+memreserve region in the device tree) will be considered as available to
+the kernel.
 
 Before jumping into the kernel, the following conditions must be met:
 

arch/arm64/kernel/head.S +2 -2

index 5dd8127..542ca97 100644
@@ -98,8 +98,8 @@
 	 */
 	b	stext				// branch to kernel start, magic
 	.long	0				// reserved
-	.quad	TEXT_OFFSET			// Image load offset from start of RAM
-	.quad	0				// reserved
+	.quad	_kernel_offset_le		// Image load offset from start of RAM, little-endian
+	.quad	_kernel_size_le			// Effective size of kernel image, little-endian
 	.quad	0				// reserved
 	.quad	0				// reserved
 	.quad	0				// reserved

arch/arm64/kernel/vmlinux.lds.S +21 -0

index 51258bc..21a8ad1 100644
@@ -30,6 +30,25 @@ jiffies = jiffies_64;
 	*(.hyp.text)					\
 	VMLINUX_SYMBOL(__hyp_text_end) = .;
 
+/*
+ * There aren't any ELF relocations we can use to endian-swap values known only
+ * at link time (e.g. the subtraction of two symbol addresses), so we must get
+ * the linker to endian-swap certain values before emitting them.
+ */
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define DATA_LE64(data)					\
+	((((data) & 0x00000000000000ff) << 56) |	\
+	 (((data) & 0x000000000000ff00) << 40) |	\
+	 (((data) & 0x0000000000ff0000) << 24) |	\
+	 (((data) & 0x00000000ff000000) << 8)  |	\
+	 (((data) & 0x000000ff00000000) >> 8)  |	\
+	 (((data) & 0x0000ff0000000000) >> 24) |	\
+	 (((data) & 0x00ff000000000000) >> 40) |	\
+	 (((data) & 0xff00000000000000) >> 56))
+#else
+#define DATA_LE64(data) ((data) & 0xffffffffffffffff)
+#endif
+
 SECTIONS
 {
 	/*

@@ -114,6 +133,15 @@ SECTIONS
 	_end = .;
 
 	STABS_DEBUG
+
+	/*

Both the image load offset and the effective image size are forced to be little-endian regardless of the native endianness of the kernel to enable bootloaders to load a kernel of arbitrary endianness. Bootloaders which wish to make use of the load offset can inspect the effective image size field for a non-zero value to determine if the offset is of a known endianness.

Documentation/arm64/booting.txt +0 -0

   u64 res1	= 0;		/* reserved */
   u64 res2	= 0;		/* reserved */
   u64 res3	= 0;		/* reserved */

@@ -86,9 +86,27 @@ Header notes:
 
 

From a63dd2f24105c55734238efaacdac5048bbedf39 Mon Sep 17 00:00:00 2001

Hi Mark,

Sorry for such a delay in my reply.

Quoted 6 lines · Mark Rutland

Both the image load offset and the effective image size are forced to be little-endian regardless of the native endianness of the kernel to enable bootloaders to load a kernel of arbitrary endianness. Bootloaders which wish to make use of the load offset can inspect the effective image size field for a non-zero value to determine if the offset is of a known endianness.

Doing this conversion in the linker script seems complicated. My thought was to just have an image header field that specifies the byte order, in the same way that the EI_DATA part of the ELF e_ident field does.

Another advantage of having the byte order in the header is that tools other than a boot loader that need to know the byte order can get that info from the header, otherwise they would need to guess the order with some kind of inspection.

Quoted 1 line · Geoff Levand

Hi Mark,

Hi Geoff,

Quoted 10 lines

Sorry for such a delay in my reply.

Quoted 6 lines · Mark Rutland

Both the image load offset and the effective image size are forced to be little-endian regardless of the native endianness of the kernel to enable bootloaders to load a kernel of arbitrary endianness. Bootloaders which wish to make use of the load offset can inspect the effective image size field for a non-zero value to determine if the offset is of a known endianness.

Quoted 4 lines

Doing this conversion in the linker script seems complicated. My thought was to just have an image header field that specifies the byte order, in the same way that the EI_DATA part of the ELF e_ident field does.

While the conversion in the linker script is a little ugly, it does work, and that complexity is hidden behind the macro I added.

While I initially considered having a field to specify byte order, it's incredibly likely that bootloaders will not use it. Maintaining a fixed endianness everywhere makes it simpler for bootloaders to do the right thing, and matches what existing bootloaders are already doing. That's less pain for loaders and less pain for the kernel, as things are less likely to go wrong.

To me it makes more sense to ensure these fields have a consistent endianness, rather than adding more room for possible mistakes.

Quoted 4 lines

Another advantage of having the byte order in the header is that tools other than a boot loader that need to know the byte order can get that info from the header, otherwise they would need to guess the order with some kind of inspection.

What kind of tools do you envision which would need to know the endianness of the kernel but would be looking at the Image rather than the vmlinux?

On Mon, Jun 16, 2014 at 09:27:12PM +0100, Geoff Levand wrote:
While I initially considered having a field to specify byte order, it's incredibly likely that bootloaders will not use it. Maintaining a fixed endianness everywhere makes it simpler for bootloaders to do the right thing, and matches what existing bootloaders are already doing. That's less pain for loaders and less pain for the kernel, as things are less likely to go wrong.

To me it makes more sense to ensure these fields have a consistent endianness, rather than adding more room for possible mistakes.

Quoted 4 lines

Another advantage of having the byte order in the header is that tools other than a boot loader that need to know the byte order can get that info from the header, otherwise they would need to guess the order with some kind of inspection.

What kind of tools do you envision which would need to know the endianness of the kernel but would be looking at the Image rather than the vmlinux?

Hi Mark,

Quoted 8 lines · Geoff Levand

While I initially considered having a field to specify byte order, it's incredibly likely that bootloaders will not use it. Maintaining a fixed endianness everywhere makes it simpler for bootloaders to do the right thing, and matches what existing bootloaders are already doing. That's less pain for loaders and less pain for the kernel, as things are less likely to go wrong.

Quoted 2 lines

To me it makes more sense to ensure these fields have a consistent endianness, rather than adding more room for possible mistakes.

I guess my view is that any software expected to support arm64 in both big and little endian configurations should be tested with such, and with this it is pretty simple to test and fix, so we shouldn't over engineer it, but I don't really care how we fix it.

I disagree that the bootloader _must_ have to deal with the endianness of the kernel. If the user knows the endianness of the kernel and provides a filesystem of the appropriate endianness, I don't see why the bootloader should have to do anything differently. In most cases the bootloader has no need to care.

Hi Mark,

Quoted 5 lines · Mark Rutland

I disagree that the bootloader _must_ have to deal with the endianness of the kernel. If the user knows the endianness of the kernel and provides a filesystem of the appropriate endianness, I don't see why the bootloader should have to do anything differently. In most cases the bootloader has no need to care.

As I mentioned, I don't really care how this is fixed, but there will be bootloaders built as both big and little endian (kexec based ones for example), and so no matter what, bootloaders will need to deal with converting values.

What kind of tools do you envision which would need to know the endianness of the kernel but would be looking at the Image rather than the vmlinux?

Quoted 6 lines · Mark Rutland

arch/arm64/Kconfig.debug +0 -0

@@ -37,4 +37,35 @@ config PID_IN_CONTEXTIDR
 	  instructions during context switch. Say Y here only if you are
 	  planning to use hardware trace tools with this kernel.
 

arch/arm64/Kconfig.debug config PID_IN_CONTEXTIDR · line 42

Quoted 3 lines

arch/arm64/Kconfig.debug +3 -0

+config ARM64_RANDOMIZE_TEXT_OFFSET
+	bool "Randomize TEXT_OFFSET at build time (EXPERIMENTAL)"
+	default N

(nitpick: no need for default n)

I think that's good for testing. It would have been nice to be able to set some limits for the random offset but I can't figure out an easy way to do this via Kconfig (maybe with additional options).

arch/arm64/Kconfig.debug config PID_IN_CONTEXTIDR · line 59

Quoted 4 lines

arch/arm64/Kconfig.debug +4 -0

+config ARM64_TEXT_OFFSET
+	hex "Required image load offset"
+	depends on !ARM64_RANDOMIZE_TEXT_OFFSET
+	default "0x0000000000080000"

I don't think we should include this. It encourages people to set specific offsets for their SoCs.

Quoted 7 lines · Catalin Marinas

Quoted 6 lines · Mark Rutland

arch/arm64/Kconfig.debug +0 -0

@@ -37,4 +37,35 @@ config PID_IN_CONTEXTIDR
 	  instructions during context switch. Say Y here only if you are
 	  planning to use hardware trace tools with this kernel.
 

Quoted 5 lines

arch/arm64/Kconfig.debug config PID_IN_CONTEXTIDR · line 42

Quoted 3 lines

arch/arm64/Kconfig.debug +3 -0

+config ARM64_RANDOMIZE_TEXT_OFFSET
+	bool "Randomize TEXT_OFFSET at build time (EXPERIMENTAL)"
+	default N

(nitpick: no need for default n)

Thanks for pointing that out, I'll remove it :)

Quoted 3 lines

I think that's good for testing. It would have been nice to be able to set some limits for the random offset but I can't figure out an easy way to do this via Kconfig (maybe with additional options).

There are hard-coded limits implicit in the randomization -- between 0B and 2MB in 16B increments:

TEXT_OFFSET := $(shell awk 'BEGIN {srand(); printf "0x%05x\n", and(int(0xfffff * rand()), 0xffff0)}')

The 16B increment is required due to some code in head.S (__turn_mmu_on) requiring a minimum 16B alignment for the object.

The 2MB maximum comes from the fact we rely on the start of memory being 2MB aligned. I'm not sure there's a compelling reason to limit the randomization if enabled at all -- either you can handle it or you can't. Are we ever likely to want an offset larger than the memory alignment?

Quoted 20 lines · Mark Rutland

Quoted 7 lines · Catalin Marinas

Quoted 6 lines · Mark Rutland

arch/arm64/Kconfig.debug +0 -0

@@ -37,4 +37,35 @@ config PID_IN_CONTEXTIDR
 	  instructions during context switch. Say Y here only if you are
 	  planning to use hardware trace tools with this kernel.
 

Quoted 5 lines

arch/arm64/Kconfig.debug config PID_IN_CONTEXTIDR · line 42

Quoted 3 lines

arch/arm64/Kconfig.debug +3 -0

+config ARM64_RANDOMIZE_TEXT_OFFSET
+	bool "Randomize TEXT_OFFSET at build time (EXPERIMENTAL)"
+	default N

(nitpick: no need for default n)

Thanks for pointing that out, I'll remove it :)

Quoted 3 lines

I think that's good for testing. It would have been nice to be able to set some limits for the random offset but I can't figure out an easy way to do this via Kconfig (maybe with additional options).

Quoted 4 lines

There are hard-coded limits implicit in the randomization -- between 0B and 2MB in 16B increments:

TEXT_OFFSET := $(shell awk 'BEGIN {srand(); printf "0x%05x\n", and(int(0xfffff * rand()), 0xffff0)}')

Note, is mawk expected to be able to be used for kernel building? It doesn't have 'and' as a function.

Quoted 9 lines

The 16B increment is required due to some code in head.S (__turn_mmu_on) requiring a minimum 16B alignment for the object.

The 2MB maximum comes from the fact we rely on the start of memory being 2MB aligned. I'm not sure there's a compelling reason to limit the randomization if enabled at all -- either you can handle it or you can't. Are we ever likely to want an offset larger than the memory alignment?

A reason to limit the randomization is to make it easier on the bootloaders to be able to rule of thumb initial loads. It's not a big deal with Image if it gets loaded lower than the offset, we can start shifting data at the end. But when we start looking at Image.gz (or xz or ...), in some cases we'll get the whole image read into memory (network booting for example), uncompress the first block so we can confirm a good Image header and see about text_offset/image_size. If we know that text_offset is somewhere random inside of 2MB (or some other documented max), we can then go with saying an initial load should be at say +32MB (to mirror Documentation/arm/Booting). If it can be anywhere, then things get hard, or at least annoying (error out and tell the user to re-load things because of a random value? I can see testing frameworks being annoyed about that).

And we should document the range of the offset in
Documentation/arm64/booting.txt as well.

Quoted 9 lines

Quoted 8 lines

The 16B increment is required due to some code in head.S (__turn_mmu_on) requiring a minimum 16B alignment for the object.

The 2MB maximum comes from the fact we rely on the start of memory being 2MB aligned. I'm not sure there's a compelling reason to limit the randomization if enabled at all -- either you can handle it or you can't. Are we ever likely to want an offset larger than the memory alignment?

Quoted 13 lines

A reason to limit the randomization is to make it easier on the bootloaders to be able to rule of thumb initial loads. It's not a big deal with Image if it gets loaded lower than the offset, we can start shifting data at the end. But when we start looking at Image.gz (or xz or ...), in some cases we'll get the whole image read into memory (network booting for example), uncompress the first block so we can confirm a good Image header and see about text_offset/image_size. If we know that text_offset is somewhere random inside of 2MB (or some other documented max), we can then go with saying an initial load should be at say +32MB (to mirror Documentation/arm/Booting). If it can be anywhere, then things get hard, or at least annoying (error out and tell the user to re-load things because of a random value? I can see testing frameworks being annoyed about that).

Ouch, that is somewhat painful.

I don't think we expect to see a text_offset larger than 2MB, and I can't immediately see why we'd care about any particular text offset assuming the page tables are at the end of the runtime image. That said, I'm not completely clear on the history of the text_offset.

Quoted 2 lines

And we should document the range of the offset in
Documentation/arm64/booting.txt as well.

As far as I am aware, we have a 64-bit field specifically to allow for an arbitrarily large value, so placing limitations on that may be a little difficult.

As stated above, I don't think there'd be a reason for having a text_offset larger than our memory alignment restriction (2MB), but there may be something I've missed. If others are reasonably confident with an upper limit, I'd be happy to go with it.

Currently bootloaders have an extremely difficult time protecting memory from the kernel, as the kernel may clobber memory below TEXT_OFFSET with pagetables, and above the end of the kernel binary with the BSS.