linux-kernel - Re: [RFC][PATCH 06/34] x86/boot: Use consistent value for iomem

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: <195ad815f14b71c46de94281f0af57027b4e3fff.camel@intel.com>
Date: Tue, 27 Feb 2024 10:59:55 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de"
	<bp@...en8.de>
Subject: Re: [RFC][PATCH 06/34] x86/boot: Use consistent value for
 iomem_resource.end

On Thu, 2024-02-22 at 10:39 -0800, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@...ux.intel.com>
> 
> The 'struct cpuinfo_x86' values (including 'boot_cpu_info') get
> written and overwritten rather randomly.  They are not stable
> during early boot and readers end up getting a random mishmash
> of hard-coded defaults or CPUID-provided values based on when
> the values are read.
> 
> iomem_resource.end is one of these users.  Because of where it
> is called, it ended up seeing .x86_phys_bits==MAX_PHYSMEM_BITS
> which is (mostly) a compile-time default.  But
> iomem_resource.end is never updated if the runtime CPUID
> x86_phys_bits is lower.
> 
> Set iomem_resource.end to the compile-time value explicitly.
> It does not need to be precise as this is mostly to ensure
> that insane values can't be reserved in 'iomem_resource'.
> 
> Make MAX_PHYSMEM_BITS available outside of sparsemem
> configurations by removing the #ifdef CONFIG_SPARSEMEM in the
> header.
> 
> Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
> ---
> 
>  b/arch/x86/include/asm/sparsemem.h |    3 ---
>  b/arch/x86/kernel/setup.c          |   10 +++++++++-
>  2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff -puN arch/x86/kernel/setup.c~iomem_resource_end arch/x86/kernel/setup.c
> --- a/arch/x86/kernel/setup.c~iomem_resource_end	2024-02-22 10:08:51.048554948 -0800
> +++ b/arch/x86/kernel/setup.c	2024-02-22 10:21:04.485531464 -0800
> @@ -51,6 +51,7 @@
>  #include <asm/pci-direct.h>
>  #include <asm/prom.h>
>  #include <asm/proto.h>
> +#include <asm/sparsemem.h>
>  #include <asm/thermal.h>
>  #include <asm/unwind.h>
>  #include <asm/vsyscall.h>
> @@ -813,7 +814,14 @@ void __init setup_arch(char **cmdline_p)
>  	 */
>  	early_reserve_memory();
>  
> -	iomem_resource.end = (1ULL << x86_phys_bits()) - 1;
> +	/*
> +	 * This was too big before.  It ended up getting MAX_PHYSMEM_BITS
> +	 * even if .x86_phys_bits was eventually lowered below that.
> +	 * But that was evidently harmless, so leave it too big, but
> +	 * set it explicitly to MAX_PHYSMEM_BITS instead of taking a
> +	 * trip through .x86_phys_bits.
> +	 */
> +	iomem_resource.end = (1ULL << MAX_PHYSMEM_BITS) - 1;

Paolo's patchset to move MKTME keyid bits detection to early_cpu_init() was
merged to tip:x86/urgent, so looks it will land to Linus's tree before this
series:

https://lore.kernel.org/lkml/eff34df2-fdc1-4ee0-bb8d-90da386b7cb6@intel.com/T/

Paplo's series actually moves the reduction of x86_phys_bits before setting the
iomem_resource.end here, so after rebasing the changelog/comment seems don't
apply anymore.

Perhaps we can get rid of this patch and just set iomem_resource.end based on
x86_phys_bits()?