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

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: <CAMj1kXG+6CYVSV-2ZSqrEm+B=az+54=fNwHpC_6qQZ-z2=3Zgw@mail.gmail.com>
Date: Thu, 8 Jan 2026 14:33:25 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Seth Jenkins <sethjenkins@...gle.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-hardening@...r.kernel.org, 
	mark.rutland@....com, catalin.marinas@....com, will@...nel.org, 
	kees@...nel.org, Liz Prucka <lizprucka@...gle.com>
Subject: Re: [RFC PATCH] arm64: Bring back linear map randomization using
 PArange override

On Tue, 16 Dec 2025 at 19:14, Seth Jenkins <sethjenkins@...gle.com> wrote:
>
> > 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 may be a minority, but I do think bringing this back is a good idea.
> It has now been 9+ years since hardware side channels for bypassing
> KASLR were discovered, and it still appears that real-world attackers
> overwhelmingly prefer alternative strategies - such as this one.
>
> I'm under no illusion that if we just do this one thing KASLR will be
> secure again, but I think this patch would still have a meaningful
> real-world impact in terms of making exploits significantly harder to
> write.
>

Thanks for the feedback.

I was hoping to get some other views on this matter, but sending the
patch during plumbers and right before the holidays probably didn't
help in that regard, I'm afraid.

Any thoughts on the desirability of this feature wrt randomization of
the placement of vmlinux in physical memory? AIUI, the main issue
being addressed here is predictable placement of statically allocated
kernel objects in the virtual address space, which could be solved in
either way. Or are there other concerns here?

Just trying to elicit as much input as possible on the list, so the
maintainers can make an informed decision.

Thanks,
Ard.