Re: [PATCH v2] x86: Clear feature bits disabled at compile-time

From: H. Peter Anvin
Date: Wed Jul 23 2025 - 10:11:28 EST

On 2025-07-23 02:22, Maciej Wieczor-Retman wrote:
>
> arch/x86/kernel/cpu/common.c | 12 ++++++++++++
> arch/x86/tools/cpufeaturemasks.awk | 8 ++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 77afca95cced..ba8b5fba8552 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1709,6 +1709,16 @@ static void __init cpu_parse_early_param(void)
> }
> }
>
> +static __init void init_cpu_cap(struct cpuinfo_x86 *c)
> +{
> + int i;
> +
> + for (i = 0; i < NCAPINTS; i++) {
> + cpu_caps_set[i] = REQUIRED_MASK(i);
> + cpu_caps_cleared[i] = DISABLED_MASK(i);
> + }
> +}
> +

No... just use an static array initializer for cpu_caps_cleared[]. You
don't even need to add any code at all.

Ironically enough, I actually had those macros generated in the original
awk script version, but they weren't used.

And you MUST NOT initialize cpu_caps_set[]. What we *can* and probably
should do is, at the very end of the process, verify that the final mask
conforms to cpu_caps_set[] and print a nasty message and set the
TAINT_CPU_OUT_OF_SPEC flag:

add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK)

... but that is a separate patch, and doesn't need to be backported.

Xin send me a patch privately (attached) but it needs to have the
REQUIRED_MASK_INIT_VALUES part removed and made into a proper patch.

Xin didn't add an SoB on it, but you can use mine:

Signed-off-by: H. Peter Anvin (Intel) <hpa@xxxxxxxxx>

-hpa
Return-Path: <xin@xxxxxxxxx>
Received: from [192.168.7.202] ([71.202.166.45])
(authenticated bits=0)
by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 56MIMkSj692590
(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO)
for <hpa@xxxxxxxxx>; Tue, 22 Jul 2025 11:22:47 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 56MIMkSj692590
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com;
s=2025062101; t=1753208567;
bh=dyteAFsAJy5+VmQ/vZVASq8c7iaJ+iMBDZ5Nx+HCzmY=;
h=Date:Subject:To:References:From:In-Reply-To:From;
b=nnoRrPuX9IJ+o1R7h9A6G2yU1Z6Z25CzI24+q6sTmlatPY95L9YrzXCzyvXlk0bNl
ofB4oChO8SZeMR7Gda6mAq3onjvLSf4IdVNumFa34T1r3yhjlyQ14HjMUSeNMvsaBa
3sDt5+Lf48MxO1FEcDg/AO7SWl6qGbeCtBtJM2IQSMWIBb31ggqA0BdZcL9JYsNZwl
3mzCevgS0tXB8xztoUjOdP42LbaBGrcdyflSPklVaPH/kDQVx9qWFSKa0zGQVKeg0N
7ItKpH4We2plNju0g6uDwZBQBxyO38VQlCuQy+l/M/i6Hmn56rtFhzgymNsUAF54PV
XPPXWUquDp/Gw==
Message-ID: <9ffd7f0b-f196-41a1-83c2-4a830d1bb035@xxxxxxxxx>
Date: Tue, 22 Jul 2025 11:22:46 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: Clear LAM and FRED feature bits
To: "H. Peter Anvin" <hpa@xxxxxxxxx>
References: <20250722074439.4069992-1-maciej.wieczor-retman@xxxxxxxxx>
<32382f60-79fb-4cfa-87b4-581f92c980da@xxxxxxxxx>
<A4EB1016-8CF7-4609-BBF1-9AEC83B52A4F@xxxxxxxxx>
<5654b3bc-15d4-443b-a7b1-2f9fd1d3e0aa@xxxxxxxxx>
<AA38D754-3189-4905-AA3B-45A56065B68A@xxxxxxxxx>
<91dd8b75-1191-4a3d-9f62-d94c325793fd@xxxxxxxxx>
Content-Language: en-US
From: Xin Li <xin@xxxxxxxxx>
Autocrypt: addr=xin@xxxxxxxxx; keydata=
xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0
2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5
Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy
bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu
raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY
VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH
wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ
6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA
NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID
AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge
tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW
v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa
sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+
QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA
wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ
oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE
vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL
MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy
g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N
cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176
jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp
Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d
m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4
bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA
JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L
/RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj
OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F
dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx
2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ
Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk
PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn
gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4
l75w1xInsg==
In-Reply-To: <91dd8b75-1191-4a3d-9f62-d94c325793fd@xxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 7/22/2025 11:13 AM, H. Peter Anvin wrote:
> On 2025-07-22 11:08, H. Peter Anvin wrote:
>>>
>>> Yes, something like:
>>>
>>> void __init init_cpu_cap(void)
>>> {
>>> for (i = 0; i < NCAPINTS; i++) {
>>> cpu_caps_set[i] = REQUIRED_MASK(i);
>>> cpu_caps_cleared[i] = DISABLED_MASK(i);
>>> }
>>> }
>>>
>>> And it would be better if it could be done at build time (to avoid
>>> changing Xen which has a dedicated startup code path):
>>>
>>> __u32 cpu_caps_{set,cleared}[NCAPINTS + NBUGINTS] = {
>>> {REQUIRED,DISABLED}_MASK(i),
>>> };
>>>
>>> And then apply_forced_caps() will do the rest automatically :)
>>
>> Yeah:
>>
>> u32 __init cpu_caps_cleared = { ... };
>>
>> ... which can come straight out of the awk script.
>>
>
> Heck, I think I even did something like this in the first version, but
> tglx or someone else asked to axe it because it wasn't being used (yet.) ;)
>

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 5809534ecc98..eb075fbf337e 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -703,8 +703,8 @@ static const char *table_lookup_model(struct
cpuinfo_x86 *c)
}

/* Aligned to unsigned long to avoid split lock in atomic bitmap ops */
-__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned
long));
-__u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
+__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned
long)) = DISABLED_MASK_INIT_VALUES;
+__u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned
long)) = REQUIRED_MASK_INIT_VALUES;

#ifdef CONFIG_X86_32
/* The 32-bit entry code needs to find cpu_entry_area. */
diff --git a/arch/x86/tools/cpufeaturemasks.awk
b/arch/x86/tools/cpufeaturemasks.awk
index 173d5bf2d999..6b3583304ee8 100755
--- a/arch/x86/tools/cpufeaturemasks.awk
+++ b/arch/x86/tools/cpufeaturemasks.awk
@@ -81,7 +81,13 @@ END {
printf "\t\\\n\t\t((x) >> 5) == %2d ?
%s_MASK%d :", i, s, i;
}
printf " 0\t\\\n";
- printf "\t) & (1U << ((x) & 31)))\n\n";
+ printf "\t) & (1U << ((x) & 31)))\n";
+
+ printf "\n#define %s_MASK_INIT_VALUES\t\t\t\\", s;
+ printf "\n\t{\t\t\t\t\t\t\\";
+ for (i = 0; i < ncapints; i++)
+ printf "\n\t\t%s_MASK%d,\t\t\t\\", s, i;
+ printf "\n\t}\n\n";
}

printf "#endif /* _ASM_X86_CPUFEATUREMASKS_H */\n";