linux-kernel - Re: [tip: x86/urgent] x86/e820: Discard high memory that can't be addressed by 32-bit systems

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: <a641e123-be70-41ab-b0ce-6710d7fd0c2d@intel.com>
Date: Mon, 14 Apr 2025 07:19:02 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org
Cc: Arnd Bergmann <arnd@...nel.org>,
 "Mike Rapoport (Microsoft)" <rppt@...nel.org>, Ingo Molnar
 <mingo@...nel.org>, Andy Shevchenko <andy@...nel.org>,
 Arnd Bergmann <arnd@...db.de>, Davide Ciminaghi <ciminaghi@...dd.com>,
 "H. Peter Anvin" <hpa@...or.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Matthew Wilcox <willy@...radead.org>, Paolo Bonzini <pbonzini@...hat.com>,
 Sean Christopherson <seanjc@...gle.com>, kvm@...r.kernel.org, x86@...nel.org
Subject: Re: [tip: x86/urgent] x86/e820: Discard high memory that can't be
 addressed by 32-bit systems

On 4/13/25 02:23, tip-bot2 for Mike Rapoport (Microsoft) wrote:
> +	/*
> +	 * 32-bit systems are limited to 4BG of memory even with HIGHMEM and
> +	 * to even less without it.
> +	 * Discard memory after max_pfn - the actual limit detected at runtime.
> +	 */
> +	if (IS_ENABLED(CONFIG_X86_32))
> +		memblock_remove(PFN_PHYS(max_pfn), -1);

Mike, thanks for the quick fix! I did verify that this gets my silly
test VM booting again.

The patch obviously _works_. But in the case I was hitting max_pfn was
set MAX_NONPAE_PFN. The unfortunate part about this hunk is that it's
far away from the related warning:

>         if (max_pfn > MAX_NONPAE_PFN) {
>                 max_pfn = MAX_NONPAE_PFN;
>                 printk(KERN_WARNING MSG_HIGHMEM_TRIMMED);
>         }

and it's logically doing the same thing: truncating memory at
MAX_NONPAE_PFN.

How about we reuse 'MAX_NONPAE_PFN' like this:

	if (IS_ENABLED(CONFIG_X86_32))
		memblock_remove(PFN_PHYS(MAX_NONPAE_PFN), -1);

Would that make the connection more obvious?