linux-kernel - Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header

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: <54745fd4-d139-4162-82b5-a10c1993e77a@intel.com>
Date: Tue, 10 Feb 2026 15:03:18 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>
CC: <zhao1.liu@...el.com>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"
	<hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Jon Kohler
	<jon@...anix.com>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, "Peter
 Zijlstra (Intel)" <peterz@...radead.org>, Thomas Gleixner <tglx@...nel.org>,
	Tony Luck <tony.luck@...el.com>, <x86@...nel.org>, Iwona Winiarska
	<iwona.winiarska@...el.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into
 separate header

On 2/10/2026 2:17 PM, Dave Hansen wrote:

> The reality is that we have non-x86 code using an x86 header. That's
> crazy and it's very very unusual and we're probably going to keep
> accidentally breaking it.
> 
> Our only hope is to just move all that gunk to generic code for _real_.

I agree all VFM stuff needs to be moved to resolve this cleanly.

However, I feel, the partial fix makes the situation worse in the short
term. The new header x86-vfm.h isn't directly used by any generic code.
It is only included from arch/x86 headers.

arch/x86/include/asm/cpu_device_id.h:
  5: #include <asm-generic/x86-vfm.h>

arch/x86/include/asm/intel-family.h:
  10: #include <asm-generic/x86-vfm.h>

With the new changes, the PECI driver still relies on some copied code
and includes an explicit x86 header (which then includes an x86-vfm
header from asm-generic). intel-family.h *still* implicitly relies on
asm/processor.h.

Instead, would it be better to avoid the first two patches in the series
(until we have a cleaner solution) and do this?

diff --git a/arch/x86/include/asm/microcode.h
b/arch/x86/include/asm/microcode.h
index 3e1987642ecc..92fa64904ee5 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -3,6 +3,7 @@
 #define _ASM_X86_MICROCODE_H

 #include <asm/cpu.h>
+#include <asm/cpu_device_id.h>
 #include <asm/intel-family.h>
 #include <asm/msr.h>

I verified that this compiles cleanly. Though it's your call in the end.
I wouldn't push for it further.