Re: [RFC PATCH] arm64: Bring back linear map randomization using PArange override

[Will Deacon <will@kernel.org>]

On Thu, Dec 11, 2025 at 05:09:36AM +0100, Ard Biesheuvel wrote:
> Commit
> 
>   1db780bafa4ce ("arm64/mm: Remove randomization of the linear map")
> 
> removed linear map randomization from the arm64 port, on the basis that
> a prior change to the logic rendered it non-functional on the majority
> of relevant CPU implementations.
> 
> As has been reported numerous times now, the upshot of this is that the
> virtual addresses of statically allocated kernel data structures are
> highly predictable if the kernel is loaded at a known physical address.
> Any bootloader that still adheres to the original arm64 boot protocol,
> which stipulated that the kernel should be loaded at the lowest
> available physical address, is affected by this.
> 
> So bring back the most recent version of linear map randomization, which
> is based on the CPU's physical address range, but this time, allow this
> PA range to be overridden on the kernel command line.
> 
> E.g., by passing
> 
>   id_aa64mmfr0.parange=1 # 36 bits
>   id_aa64mmfr0.parange=2 # 40 bits
> 
> the CPU's supported physical range can be reduced to the point where
> linear map randomization becomes feasible again. It also means that
> nothing else is permitted to appear in that physical window, i.e.,
> hotplug memory but also non-memory peripherals, or stage-2 mappings on
> behalf of KVM guests.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> Cc: Liz Prucka <lizprucka@google.com>
> Cc: Seth Jenkins <sethjenkins@google.com>
> 
> This is posted as an RFC because there are obvious shortcomings to this
> approach. However, before I spend more time on this, I'd like to gauge
> if there is any consensus that bringing this back is a good idea.

I'm a bit worried about knock-on effects of restricting the parange,
especially for guests, although I admittedly haven't had a chance to
investigate it properly.

If we instead made the cmdline option specific to memory hotplug (e.g.
by providing a ceiling for the maximum physical address of memory that
can appear dynamically), would that give us what we need? For Android,
we could then pass a value of '0' in the default cmdline (effectively
disabling memory hotplug) and the onus would be on the few platforms
that care about hotplug to set the value correctly.

We already have "mem=", so maybe it's just a question of special-casing
0 for that (assuming that memory hotplug respects the memory limit).

Will