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] [day] [month] [year] [list]

Message-ID: <CALxfFW4nn3RMWfQHZ8yExhznTZyCAMm1Xj7J7ZALooan2eUNfQ@mail.gmail.com>
Date: Thu, 8 Jan 2026 12:59:31 -0500
From: Seth Jenkins <sethjenkins@...gle.com>
To: Ard Biesheuvel <ardb@...nel.org>
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

> Any thoughts on the desirability of this feature wrt randomization of
the placement of vmlinux in physical memory?
Even with vmlinux randomization in physical memory, dynamically
allocated memory ALSO ends up getting predictably placed. If I
allocate basically all physical memory, e.g. with mmap, I can predict
with >90% accuracy a PFN that was allocated by that mmap with the
caveat that my testing was soon after boot so that reliability may go
down over time in a real world scenario.

So I think linear map randomization is still relevant in making
real-world exploitation more difficult even if vmlinux is randomized
in physical memory.


On Thu, Jan 8, 2026 at 8:33 AM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> 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.