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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260113115412.GFaWYyZI5zDTXXN_qv@fat_crate.local>
Date: Tue, 13 Jan 2026 12:54:12 +0100
From: Borislav Petkov <bp@...en8.de>
To: Michał Cłapiński <mclapinski@...gle.com>
Cc: Dave Hansen <dave.hansen@...el.com>, Ard Biesheuvel <ardb@...nel.org>,
	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, 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.

I'd say...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette