linux-kernel - Re: [PATCH v3 1/1] x86/boot/compressed: Fix avoiding memmap in physical KASLR

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: <CAMj1kXEmDvCt5jnKOyW6U2eQ0SD9+HYgxbv7VjRaYSOAaOYOcg@mail.gmail.com>
Date: Tue, 13 Jan 2026 13:18:16 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Michał Cłapiński <mclapinski@...gle.com>, 
	Dave Hansen <dave.hansen@...el.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, 
	Chris Li <chrisl@...nel.org>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, 
	Dan Williams <dan.j.williams@...el.com>, Pasha Tatashin <pasha.tatashin@...een.com>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] x86/boot/compressed: Fix avoiding memmap in
 physical KASLR

On Tue, 13 Jan 2026 at 12:54, Borislav Petkov <bp@...en8.de> wrote:
>
> On Tue, Jan 13, 2026 at 12:39:01PM +0100, Michał Cłapiński wrote:
> > I expect most people who use memmaps use 4 or fewer, which was the
> > reason given when this code was originally written.
> >
> > But generally I agree. I expected my change to be merged quickly and I
> > wanted to propose a new change on top of that that would increase that
> > number (either to a very high number or just fully remove the
> > restriction).
>
> Yes, and as you notice yourself, the question of how high that number should
> be is hard to answer. Perhaps even non-sensical.
>
> Why would one want to specify memmap *and* expect KASLR to be functioning
> optimally after it has limitations imposed on the range?
>
> Or, to put it differently, under which memmap= setting can KASLR still
> function optimally and where does it get impaired? That could be one criterion
> to use IMHO...
>
> But ofc, if the memmap thing is only an "expectation", then simply zap it and
> be done with it.
>
> As Ard said, you could write a detailed commit message explaining the
> rationale and then we can queue it and see who complains.
>

Lack of physical KASLR is not a big deal unless a) the physical
placement is predictable, and b) the linear map is not randomized
either, because that will result in linear aliases of kernel data
structures being predictable as well.

Note that since v6.6 (backported to v6.1), EFI boot via the stub no
longer calls into this code - instead, it performs a randomized
allocation using the EFI boot services, and places the kernel there,
unless it encounters any of mem=, memmap= or hugepages= on the command
line [0], in which case it allocates at the base of system RAM.

This is why I suggested to do the same here.


[0] 15aa8fb852f9 x86/efistub: Omit physical KASLR when memory reservations exist