linux-kernel - [PATCH v1 1/1] x86/cpu: Fix boot on Intel Quark X1000

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-next>] [day] [month] [year] [list]

Message-ID: <20240516173928.3960193-1-andriy.shevchenko@linux.intel.com>
Date: Thu, 16 May 2024 20:39:27 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Cc: Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Adam Dunlap <acdunlap@...gle.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	stable@...r.kernel.org
Subject: [PATCH v1 1/1] x86/cpu: Fix boot on Intel Quark X1000

The initial change to set x86_virt_bits to the correct value straight
away broke boot on Intel Quark X1000 CPUs (which are family 5, model 9,
stepping 0)

With deeper investigation it appears that the Quark doesn't have
the bit 19 set in 0x01 CPUID leaf, which means it doesn't provide
any clflush instructions and hence the cache alignment is set to 0.
The actual cache line size is 16 bytes, hence we may set the alignment
accordingly. At the same time the physical and virtual address bits
are retrieved via 0x80000008 CPUID leaf.

Note, we don't really care about the value of x86_clflush_size as it
is either used with a proper check for the instruction to be present,
or, like in PCI case, it assumes 32 bytes for all supported 32-bit CPUs
that have actually smaller cache line sizes and don't advertise it.

The commit fbf6449f84bf ("x86/sev-es: Set x86_virt_bits to the correct
value straight away, instead of a two-phase approach") basically
revealed the issue that has been present from day 1 of introducing
the Quark support.

Fixes: aece118e487a ("x86: Add cpu_detect_cache_sizes to init_intel() add Quark legacy_cache()")
Cc: stable@...r.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
---
 arch/x86/kernel/cpu/intel.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index be30d7fa2e66..2bffae158dd5 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -321,6 +321,15 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
 	set_cpu_cap(c, X86_FEATURE_SYSENTER32);
 #else
+	/*
+	 * The Quark doesn't have bit 19 set in 0x01 CPUID leaf, which means
+	 * it doesn't provide any clflush instructions and hence the cache
+	 * alignment is set to 0. The actual cache line size is 16 bytes,
+	 * hence set the alignment accordingly. At the same time the physical
+	 * and virtual address bits are retrieved via 0x80000008 CPUID leaf.
+	 */
+	if (c->x86 == 5 && c->x86_model == 9)
+		c->x86_cache_alignment = 16;
 	/* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */
 	if (c->x86 == 15 && c->x86_cache_alignment == 64)
 		c->x86_cache_alignment = 128;
-- 
2.43.0.rc1.1336.g36b5255a03ac