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

[Ard Biesheuvel]

On Mon, 4 Dec 2023 at 15:12, Mark Rutland <mark.rutland at arm.com> wrote:
>
> On Wed, Nov 29, 2023 at 12:15:58PM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at 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?
>

Your analysis is correct afaict, and I got things confused as to
whether/how EFI will relocate the image.

However, we do have a quirk that permits loading with a hard coded
TEXT_OFFSET of 512k even if the TEXT_OFFSET in the header is 0x0. This
is the reason why we enabled CONFIG_RELOCATABLE without
CONFIG_RANDOMIZE_BASE by default.

I think that ultimately, the fact that CONFIG_RELOCATABLE can be
enabled without CONFIG_RANDOMIZE_BASE is sufficient grounds to add
this extra space.