lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXHXAYt0xLnx4=+qiCbnuF5U+9dzwnds1yd+vhTtpP5v3Q@mail.gmail.com>
Date: Thu, 20 Mar 2025 08:57:47 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Ard Biesheuvel <ardb+git@...gle.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org, Catalin Marinas <catalin.marinas@....com>, 
	Will Deacon <will@...nel.org>, Ryan Roberts <ryan.roberts@....com>, 
	Mark Rutland <mark.rutland@....com>, Anshuman Khandual <anshuman.khandual@....com>, 
	Kees Cook <kees@...nel.org>
Subject: Re: [RFC PATCH] arm64/mm: Remove randomization of the linear map

On Tue, 18 Mar 2025 at 14:50, Ard Biesheuvel <ardb+git@...gle.com> wrote:
>
> From: Ard Biesheuvel <ardb@...nel.org>
>
> Since commit
>
>   97d6786e0669 ("arm64: mm: account for hotplug memory when randomizing the linear region")
>
> the decision whether or not to randomize the placement of the system's
> DRAM inside the linear map is based on the capabilities of the CPU
> rather than how much memory is present at boot time. This change was
> necessary because memory hotplug may result in DRAM appearing in places
> that are not covered by the linear region at all (and therefore
> unusable) if the decision is solely based on the memory map at boot.
>
> In the Android GKI kernel, which requires support for memory hotplug,
> and is built with a reduced virtual address space of only 39 bits wide,
> randomization of the linear map never happens in practice as a result.
> And even on arm64 kernels built with support for 48 bit virtual
> addressing, the wider PArange of recent CPUs means that linear map
> randomization is slowly becoming a feature that only works on systems
> that will soon be obsolete.
>
> So let's just remove this feature. We can always bring it back in an
> improved form if there is a real need for it.
>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: Ryan Roberts <ryan.roberts@....com>
> Cc: Mark Rutland <mark.rutland@....com>
> Cc: Anshuman Khandual <anshuman.khandual@....com>
> Cc: Kees Cook <kees@...nel.org>
> Signed-off-by: Ard Biesheuvel <ardb@...nel.org>

Additional note based on an off-list discussion with Kees and the KSPP team:

Initially, the randomization of the linear map was considered to be a
layer of defense against the abuse of writable linear aliases of
read-only mappings in the vmalloc range, such as module text and
rodata. This has been addressed in the meantime, by mapping the linear
region down to pages by default, and mapping linear aliases read-only
if the vmalloc mapping is read-only.

So considering that, and the fact that randomization of the linear map
occurs rarely if at all on recent CPUs, I think we should go ahead and
remove this feature.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ