[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAi7L5cJB7Nk4JRsoKsGMmy07Yp1-bGXU9-gb7FZsFGYAYiXoA@mail.gmail.com>
Date: Tue, 13 Jan 2026 12:39:01 +0100
From: Michał Cłapiński <mclapinski@...gle.com>
To: Borislav Petkov <bp@...en8.de>
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:27 PM Borislav Petkov <bp@...en8.de> wrote:
>
> On Tue, Jan 13, 2026 at 12:21:25PM +0100, Michał Cłapiński wrote:
> > Currently, if you have 4 or fewer memmaps, KASLR correctly avoids
> > putting the kernel there. That just works now and Ard's change would
> > disable that.
>
> And why do we care about 4 or fewer memmaps? Is that a valid use case which we
> have to support? 4 is magic but 5 is a no-no?
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).
Powered by blists - more mailing lists