Re: [PATCH v6 02/41] arm64: mm: Take potential load offset into account when KASLR is off

[Mark Rutland <mark.rutland@arm.com>]

On Wed, Nov 29, 2023 at 12:15:58PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> We enable CONFIG_RELOCATABLE even when CONFIG_RANDOMIZE_BASE is
> disabled, and this permits the loader (i.e., EFI) to place the kernel
> anywhere in physical memory as long as the base address is 64k aligned.

I don't think that case is something we actually intend to permit today:

(a) When CONFIG_RANDOMIZE_BASE=n, the EFI stub will load the kernel at SZ_2M
    alignment. We initialize efi_nokaslr to !IS_ENABLED(CONFIG_RANDOMIZE_BASE),
    and so arm64's efi_get_kimg_min_align() will return SZ_2M.

    ... unless I'm missing something there?

(b) We don't expose anything in the Image header such that an external
    bootloader (i.e. not the EFI stub) can decide that 64K alignment is
    sufficient. It would be unsound for a bootloader to load the kernel at less
    than 2M alignment.

(c) We never documented 64K alignment as being permitted. In booting.txt we say
    "The Image must be placed text_offset bytes from a 2MB aligned base address
    anywhere in usable system RAM and called there.", with no mention of a
    relaxation down to 64K.

... so I don't think this patch is necessary, unless it's going to make
something else simpler later in the series?

Mark.

> This means that the 'KASLR' case described in the header that defines
> the size of the statically allocated page tables could take effect even
> when CONFIG_RANDMIZE_BASE=n. So check for CONFIG_RELOCATABLE instead.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/arm64/include/asm/kernel-pgtable.h | 27 +++++---------------
>  1 file changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
> index 85d26143faa5..83ddb14b95a5 100644
> --- a/arch/arm64/include/asm/kernel-pgtable.h
> +++ b/arch/arm64/include/asm/kernel-pgtable.h
> @@ -37,27 +37,12 @@
>  
>  
>  /*
> - * If KASLR is enabled, then an offset K is added to the kernel address
> - * space. The bottom 21 bits of this offset are zero to guarantee 2MB
> - * alignment for PA and VA.
> - *
> - * For each pagetable level of the swapper, we know that the shift will
> - * be larger than 21 (for the 4KB granule case we use section maps thus
> - * the smallest shift is actually 30) thus there is the possibility that
> - * KASLR can increase the number of pagetable entries by 1, so we make
> - * room for this extra entry.
> - *
> - * Note KASLR cannot increase the number of required entries for a level
> - * by more than one because it increments both the virtual start and end
> - * addresses equally (the extra entry comes from the case where the end
> - * address is just pushed over a boundary and the start address isn't).
> + * A relocatable kernel may execute from an address that differs from the one at
> + * which it was linked. In the worst case, its runtime placement may intersect
> + * with two adjacent PGDIR entries, which means that an additional page table
> + * may be needed at each subordinate level.
>   */
> -
> -#ifdef CONFIG_RANDOMIZE_BASE
> -#define EARLY_KASLR	(1)
> -#else
> -#define EARLY_KASLR	(0)
> -#endif
> +#define EXTRA_PAGE	__is_defined(CONFIG_RELOCATABLE)
>  
>  #define SPAN_NR_ENTRIES(vstart, vend, shift) \
>  	((((vend) - 1) >> (shift)) - ((vstart) >> (shift)) + 1)
> @@ -83,7 +68,7 @@
>  			+ EARLY_PGDS((vstart), (vend), add) 	/* each PGDIR needs a next level page table */	\
>  			+ EARLY_PUDS((vstart), (vend), add)	/* each PUD needs a next level page table */	\
>  			+ EARLY_PMDS((vstart), (vend), add))	/* each PMD needs a next level page table */
> -#define INIT_DIR_SIZE (PAGE_SIZE * EARLY_PAGES(KIMAGE_VADDR, _end, EARLY_KASLR))
> +#define INIT_DIR_SIZE (PAGE_SIZE * EARLY_PAGES(KIMAGE_VADDR, _end, EXTRA_PAGE))
>  
>  /* the initial ID map may need two extra pages if it needs to be extended */
>  #if VA_BITS < 48
> -- 
> 2.43.0.rc1.413.gea7ed67945-goog
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel