[PATCH v5 0/3] x86: Capability bits fix and required bits sanity check

[PATCH v5 0/3] x86: Capability bits fix and required bits sanity check

[Maciej Wieczor-Retman]

Series aims to fix the inconsistency between the cpuinfo behavior and
the documentation. Specifically the features that are not compiled are
still present in the cpuinfo bitmasks as enabled. This is not in line
with the documentation which specifies that not-compiled features are
not present in /proc/cpuinfo.

Along adding the disabled feature bitmask initializer array, the
complementary required bitmask initializer is also added. It can be used
to provide a sanity check, after the cpu identification is finished, to
make sure every required bit is set in the final bitmask. A warning with
the cpu number and all required bits that were not set is emitted in
case of the sanity check failure.

Before adding the sanity check a small cleanup can be done. Three places
open code an operation that retrieves either a feature string or, if the
string is not present, the feature number in word:bit format. One of
these places also doesn't check whether the string is actually there or
not. The cleanup patch fixes that and simplifies the other two
instances.

Previous patchset versions:
v4: https://lore.kernel.org/all/20250724125346.2792543-1-maciej.wieczor-retman@intel.com/
v3: https://lore.kernel.org/all/20250724094554.2153919-1-maciej.wieczor-retman@intel.com/
v2: https://lore.kernel.org/all/20250723092250.3411923-1-maciej.wieczor-retman@intel.com/
v1: https://lore.kernel.org/all/20250722074439.4069992-1-maciej.wieczor-retman@intel.com/

Maciej Wieczor-Retman (3):
  x86/cpu: Clear feature bits disabled at compile-time
  x86/cpu: Check if feature string is non-zero
  x86/cpu: Required feature bits sanity check

 arch/x86/kernel/cpu/common.c       | 60 +++++++++++++++++++++++++++---
 arch/x86/kernel/cpu/cpuid-deps.c   | 21 ++---------
 arch/x86/tools/cpufeaturemasks.awk |  6 +++
 include/linux/cpu.h                |  2 +
 4 files changed, 65 insertions(+), 24 deletions(-)

-- 
2.53.0

[PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

If some config options are disabled during compile time, they still are
enumerated in macros that use the x86_capability bitmask - cpu_has() or
this_cpu_has().

The features are also visible in /proc/cpuinfo even though they are not
enabled - which is contrary to what the documentation states about the
file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced,
split_lock_detect, user_shstk, avx_vnni and enqcmd.

Through the cpufeaturemasks.awk script add a DISABLED_MASK_INITIALIZER
macro that creates an initializer list filled with DISABLED_MASKx
bitmasks.

At the same time add a REQUIRED_MASK_INITIALIZER that can be used for a
sanity check of whether all the required feature bits are set at the end
of cpu identification.

Initialize the cpu_caps_cleared array with the autogenerated disabled
bitmask. apply_forced_caps() will clear the corresponding bits in
boot_cpu_data.x86_capability[] and other secondary cpus'
cpu_data.x86_capability[]. Thus features disabled at compile time won't
show up in /proc/cpuinfo.

Reported-by: Farrah Chen <farrah.chen@intel.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220348
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Cc: <stable@vger.kernel.org> # 6.18.x
---
 arch/x86/kernel/cpu/common.c       | 3 ++-
 arch/x86/tools/cpufeaturemasks.awk | 6 ++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e7ab22fce3b5..8d12c5722245 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -732,7 +732,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_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long)) =
+	DISABLED_MASK_INITIALIZER;
 __u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/tools/cpufeaturemasks.awk b/arch/x86/tools/cpufeaturemasks.awk
index 173d5bf2d999..b7f4e775a365 100755
--- a/arch/x86/tools/cpufeaturemasks.awk
+++ b/arch/x86/tools/cpufeaturemasks.awk
@@ -82,6 +82,12 @@ END {
 		}
 		printf " 0\t\\\n";
 		printf "\t) & (1U << ((x) & 31)))\n\n";
+
+		printf "\n#define %s_MASK_INITIALIZER\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";
-- 
2.53.0

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Borislav Petkov]

On Thu, Feb 12, 2026 at 03:34:38PM +0000, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> 
> If some config options are disabled during compile time, they still are
> enumerated in macros that use the x86_capability bitmask - cpu_has() or
> this_cpu_has().
> 
> The features are also visible in /proc/cpuinfo even though they are not
> enabled - which is contrary to what the documentation states about the
> file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced,
> split_lock_detect, user_shstk, avx_vnni and enqcmd.

I'm still unclear as to when did we break this? Did it ever work as
documented?

I wanna say yes, I've seen this turning off a feature removes it from
/proc/cpuinfo but I don't remember any details...

> Through the cpufeaturemasks.awk script add a DISABLED_MASK_INITIALIZER
> macro that creates an initializer list filled with DISABLED_MASKx
> bitmasks.
> 
> At the same time add a REQUIRED_MASK_INITIALIZER that can be used for a
> sanity check of whether all the required feature bits are set at the end
> of cpu identification.
> 
> Initialize the cpu_caps_cleared array with the autogenerated disabled
> bitmask. apply_forced_caps() will clear the corresponding bits in
> boot_cpu_data.x86_capability[] and other secondary cpus'
> cpu_data.x86_capability[]. Thus features disabled at compile time won't
> show up in /proc/cpuinfo.

Can you please stop explaining the diff? I can read the diff. Put in the
commit message non-obvious text which is important. Not what you're doing.

Check all your commit messages pls.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Maciej Wieczor-Retman]

On 2026-02-12 at 16:58:08 +0100, Borislav Petkov wrote:
>On Thu, Feb 12, 2026 at 03:34:38PM +0000, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>>
>> If some config options are disabled during compile time, they still are
>> enumerated in macros that use the x86_capability bitmask - cpu_has() or
>> this_cpu_has().
>>
>> The features are also visible in /proc/cpuinfo even though they are not
>> enabled - which is contrary to what the documentation states about the
>> file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced,
>> split_lock_detect, user_shstk, avx_vnni and enqcmd.
>
>I'm still unclear as to when did we break this? Did it ever work as
>documented?

I went as far back as the stable kernels go, to test separate backports and I'm
pretty sure this behavior was always there. At one point it was just documented
that is should work in a specific way which right now it doesn't.

>I wanna say yes, I've seen this turning off a feature removes it from
>/proc/cpuinfo but I don't remember any details...

I believe, previously, the only affected features were the ones that were
specifically listed with their complementary CONFIG options in the
disabled-features.h. But most of the older ones are locked behind EXPERT config
option if one would want to compile-time disable them. When looking at 5.15.x I
noticed SGX was there when it was not compiled for example. But at 5.10.x there
were no non-EXPERT features (at least none visible on the machine I was using to
test).

>> Through the cpufeaturemasks.awk script add a DISABLED_MASK_INITIALIZER
>> macro that creates an initializer list filled with DISABLED_MASKx
>> bitmasks.
>>
>> At the same time add a REQUIRED_MASK_INITIALIZER that can be used for a
>> sanity check of whether all the required feature bits are set at the end
>> of cpu identification.
>>
>> Initialize the cpu_caps_cleared array with the autogenerated disabled
>> bitmask. apply_forced_caps() will clear the corresponding bits in
>> boot_cpu_data.x86_capability[] and other secondary cpus'
>> cpu_data.x86_capability[]. Thus features disabled at compile time won't
>> show up in /proc/cpuinfo.
>
>Can you please stop explaining the diff? I can read the diff. Put in the
>commit message non-obvious text which is important. Not what you're doing.
>
>Check all your commit messages pls.

Sure, I'll revise these.

>
>Thx.
>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[H. Peter Anvin]

On February 12, 2026 8:23:58 AM PST, Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:
>On 2026-02-12 at 16:58:08 +0100, Borislav Petkov wrote:
>>On Thu, Feb 12, 2026 at 03:34:38PM +0000, Maciej Wieczor-Retman wrote:
>>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>>>
>>> If some config options are disabled during compile time, they still are
>>> enumerated in macros that use the x86_capability bitmask - cpu_has() or
>>> this_cpu_has().
>>>
>>> The features are also visible in /proc/cpuinfo even though they are not
>>> enabled - which is contrary to what the documentation states about the
>>> file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced,
>>> split_lock_detect, user_shstk, avx_vnni and enqcmd.
>>
>>I'm still unclear as to when did we break this? Did it ever work as
>>documented?
>
>I went as far back as the stable kernels go, to test separate backports and I'm
>pretty sure this behavior was always there. At one point it was just documented
>that is should work in a specific way which right now it doesn't.
>
>>I wanna say yes, I've seen this turning off a feature removes it from
>>/proc/cpuinfo but I don't remember any details...
>
>I believe, previously, the only affected features were the ones that were
>specifically listed with their complementary CONFIG options in the
>disabled-features.h. But most of the older ones are locked behind EXPERT config
>option if one would want to compile-time disable them. When looking at 5.15.x I
>noticed SGX was there when it was not compiled for example. But at 5.10.x there
>were no non-EXPERT features (at least none visible on the machine I was using to
>test).
>
>>> Through the cpufeaturemasks.awk script add a DISABLED_MASK_INITIALIZER
>>> macro that creates an initializer list filled with DISABLED_MASKx
>>> bitmasks.
>>>
>>> At the same time add a REQUIRED_MASK_INITIALIZER that can be used for a
>>> sanity check of whether all the required feature bits are set at the end
>>> of cpu identification.
>>>
>>> Initialize the cpu_caps_cleared array with the autogenerated disabled
>>> bitmask. apply_forced_caps() will clear the corresponding bits in
>>> boot_cpu_data.x86_capability[] and other secondary cpus'
>>> cpu_data.x86_capability[]. Thus features disabled at compile time won't
>>> show up in /proc/cpuinfo.
>>
>>Can you please stop explaining the diff? I can read the diff. Put in the
>>commit message non-obvious text which is important. Not what you're doing.
>>
>>Check all your commit messages pls.
>
>Sure, I'll revise these.
>
>>
>>Thx.
>>
>>--
>>Regards/Gruss,
>>    Boris.
>>
>>https://people.kernel.org/tglx/notes-about-netiquette
>

As the original author of the code I'm pretty sure that bug was always there.

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Borislav Petkov]

On February 12, 2026 9:34:31 PM UTC, "H. Peter Anvin" <hpa@zytor.com> wrote:
>As the original author of the code I'm pretty sure that bug was always there.

So, we don't need to backport it anywhere, we change it now in 7.0 or whatever and so be it. We can backport a documentation patch if someone is really pounding on it beint precisely correct for whatever reason...


-- 
Small device. Typos and formatting crap

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Sohil Mehta]

On 2/12/2026 1:51 PM, Borislav Petkov wrote:
> On February 12, 2026 9:34:31 PM UTC, "H. Peter Anvin" <hpa@zytor.com> wrote:
>> As the original author of the code I'm pretty sure that bug was always there.
> 
> So, we don't need to backport it anywhere, we change it now in 7.0 or whatever and so be it. We can backport a documentation patch if someone is really pounding on it beint precisely correct for whatever reason...
> 
> 

Can we just deprecate the "Flags" bits of /proc/cpuinfo at this point?

No production software can be using this meaningfully. We have always
said that the *absence* of the feature doesn't mean anything. The
feature could be disabled or the kernel doesn't know about it.

And now we've realized that the *presence* of the feature in
/proc/cpuinfo doesn't mean anything either.

Should we come up with a more thought-out mechanism for user space
feature detection?

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Borislav Petkov]

On Thu, Feb 12, 2026 at 03:04:44PM -0800, Sohil Mehta wrote:
> Can we just deprecate the "Flags" bits of /proc/cpuinfo at this point?
> 
> No production software can be using this meaningfully.

Before you do, grep glibc sources.

> We have always said that the *absence* of the feature doesn't mean anything.
> The feature could be disabled or the kernel doesn't know about it.
> 
> And now we've realized that the *presence* of the feature in /proc/cpuinfo
> doesn't mean anything either.

How so? The presence means, the kernel has enabled it. See
Documentation/arch/x86/cpuinfo.rst

> Should we come up with a more thought-out mechanism for user space
> feature detection?

No, because it'll be the same crap as what we have now.

This one works ok-ish.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Sohil Mehta]

On 2/12/2026 3:47 PM, Borislav Petkov wrote:
> On Thu, Feb 12, 2026 at 03:04:44PM -0800, Sohil Mehta wrote:
>> Can we just deprecate the "Flags" bits of /proc/cpuinfo at this point?
>>
>> No production software can be using this meaningfully.
> 
> Before you do, grep glibc sources.
> 

I meant freeze at whatever we have today but stop adding to it. As
described below, it has been buggy for *some* features for a long time.

>> We have always said that the *absence* of the feature doesn't mean anything.
>> The feature could be disabled or the kernel doesn't know about it.
>>
>> And now we've realized that the *presence* of the feature in /proc/cpuinfo
>> doesn't mean anything either.
> 
> How so? The presence means, the kernel has enabled it. See
> Documentation/arch/x86/cpuinfo.rst
> 

The commit message says:

"The features are also visible in /proc/cpuinfo even though they are not
enabled... Examples of such feature flags are lam, fred, sgx,
ibrs_enhanced, split_lock_detect, user_shstk, avx_vnni and enqcmd."

So, as of today, if one of these features shows up, a user can't be sure
whether the kernel has enabled it or not. Right?

My suggestion is that:
Instead of (or maybe along with) fixing this buggy interface, would it
be better to put this information in something like debugfs/sysfs? So,
at least new user software can start using that.

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Sohil Mehta]

On 2/12/2026 4:14 PM, Sohil Mehta wrote:
> On 2/12/2026 3:47 PM, Borislav Petkov wrote:
>> On Thu, Feb 12, 2026 at 03:04:44PM -0800, Sohil Mehta wrote:
>>> Can we just deprecate the "Flags" bits of /proc/cpuinfo at this point?
>>>
>>> No production software can be using this meaningfully.
>>
>> Before you do, grep glibc sources.
>>
> 
> I meant freeze at whatever we have today but stop adding to it. As
> described below, it has been buggy for *some* features for a long time.
> 

On further thought, I realized that it would be impractical to implement
such a freeze. And maintaining the two separate interfaces could become
a lot of burden.

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Borislav Petkov]

On Thu, Feb 12, 2026 at 04:14:07PM -0800, Sohil Mehta wrote:
> So, as of today, if one of these features shows up, a user can't be sure
> whether the kernel has enabled it or not. Right?

This is not such a critical bug - judging by how no one noticed it until
now...

> My suggestion is that:
> Instead of (or maybe along with) fixing this buggy interface, would it
> be better to put this information in something like debugfs/sysfs? So,
> at least new user software can start using that.

... to go and make big waves and "fix" everything. We'll address this
inconsistency eventually and go on with our lives.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time

[H. Peter Anvin]

On 2026-02-12 16:58, Borislav Petkov wrote:
> On Thu, Feb 12, 2026 at 04:14:07PM -0800, Sohil Mehta wrote:
>> So, as of today, if one of these features shows up, a user can't be sure
>> whether the kernel has enabled it or not. Right?
> 
> This is not such a critical bug - judging by how no one noticed it until
> now...
> 
>> My suggestion is that:
>> Instead of (or maybe along with) fixing this buggy interface, would it
>> be better to put this information in something like debugfs/sysfs? So,
>> at least new user software can start using that.
> 
> ... to go and make big waves and "fix" everything. We'll address this
> inconsistency eventually and go on with our lives.
> 

Agreed. And more importantly, like it or not, /proc/cpuinfo is what people are
using, if they aren't going straight out and looking at CPUID and XCR0 in user
space directly.

A new more structured interface might be nice -- for one thing, /proc/cpuinfo
is huge on newer machines; it was originally designed for the UP world -- but
we can't get rid of /proc/cpuinfo for many, many years so let's actually fix it.

	-hpa

[PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

In filter_cpuid_features, x86_cap_flags[] is read, but it's not verified
whether the string is non-zero which could lead to unwanted output.

In two more places there are open coded paths that try to retrieve a
feature string, and if there isn't one, the feature word and bit are
returned instead.

Add a helper that verifies the feature string in filter_cpuid_features()
is non-zero, and also cleans up the open coded paths mentioned above.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
 arch/x86/kernel/cpu/common.c     | 25 ++++++++++++++++++++-----
 arch/x86/kernel/cpu/cpuid-deps.c | 21 +++------------------
 include/linux/cpu.h              |  2 ++
 3 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8d12c5722245..7aede0760ebc 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -697,7 +697,7 @@ static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
 			continue;
 
 		pr_warn("CPU: CPU feature %s disabled, no CPUID level 0x%x\n",
-			x86_cap_flags[df->feature], df->level);
+			x86_cap_name(df->feature), df->level);
 	}
 }
 
@@ -1651,10 +1651,7 @@ static inline bool parse_set_clear_cpuid(char *arg, bool set)
 					setup_clear_cpu_cap(bit);
 				}
 				/* empty-string, i.e., ""-defined feature flags */
-				if (!x86_cap_flags[bit])
-					pr_cont(" %d:%d\n", bit >> 5, bit & 31);
-				else
-					pr_cont(" %s\n", x86_cap_flags[bit]);
+				pr_cont(" %s\n", x86_cap_name(bit));
 
 				taint++;
 			}
@@ -1972,6 +1969,24 @@ static void generic_identify(struct cpuinfo_x86 *c)
 #endif
 }
 
+const char *x86_cap_name(unsigned int bit)
+{
+	unsigned int word = bit >> 5;
+	static char undef_buf[16];
+	const char *name = NULL;
+
+	if (likely(word < NCAPINTS))
+		name = x86_cap_flags[bit];
+	else if (likely(word < NCAPINTS + NBUGINTS))
+		name = x86_bug_flags[bit - 32 * NCAPINTS];
+
+	if (name)
+		return name;
+
+	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
+	return undef_buf;
+}
+
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 146f6f8b0650..1106a5476dca 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -2,6 +2,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/module.h>
+#include <linux/cpu.h>
 #include <asm/cpufeature.h>
 
 struct cpuid_dep {
@@ -156,24 +157,8 @@ void setup_clear_cpu_cap(unsigned int feature)
 	do_clear_cpu_cap(NULL, feature);
 }
 
-/*
- * Return the feature "name" if available, otherwise return
- * the X86_FEATURE_* numerals to make it easier to identify
- * the feature.
- */
-static const char *x86_feature_name(unsigned int feature, char *buf)
-{
-	if (x86_cap_flags[feature])
-		return x86_cap_flags[feature];
-
-	snprintf(buf, 16, "%d*32+%2d", feature / 32, feature % 32);
-
-	return buf;
-}
-
 void check_cpufeature_deps(struct cpuinfo_x86 *c)
 {
-	char feature_buf[16], depends_buf[16];
 	const struct cpuid_dep *d;
 
 	for (d = cpuid_deps; d->feature; d++) {
@@ -185,8 +170,8 @@ void check_cpufeature_deps(struct cpuinfo_x86 *c)
 			 */
 			pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n",
 				     smp_processor_id(),
-				     x86_feature_name(d->feature, feature_buf),
-				     x86_feature_name(d->depends, depends_buf));
+				     x86_cap_name(d->feature),
+				     x86_cap_name(d->depends));
 		}
 	}
 }
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 487b3bf2e1ea..8b2176561f29 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -229,4 +229,6 @@ static inline bool cpu_attack_vector_mitigated(enum cpu_attack_vectors v)
 #define smt_mitigations SMT_MITIGATIONS_OFF
 #endif
 
+const char *x86_cap_name(unsigned int bit);
+
 #endif /* _LINUX_CPU_H_ */
-- 
2.53.0

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Sohil Mehta]

On 2/12/2026 7:35 AM, Maciej Wieczor-Retman wrote:

>  
> +const char *x86_cap_name(unsigned int bit)
> +{
> +	unsigned int word = bit >> 5;
> +	static char undef_buf[16];
> +	const char *name = NULL;
> +
> +	if (likely(word < NCAPINTS))
> +		name = x86_cap_flags[bit];
> +	else if (likely(word < NCAPINTS + NBUGINTS))
> +		name = x86_bug_flags[bit - 32 * NCAPINTS];
> +
> +	if (name)
> +		return name;
> +
> +	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
> +	return undef_buf;
> +}
> +

Isn't it unsafe to return undef_buf because the pointer is local to this
function even though it is marked static?

For example, the consecutive calls below would overwrite the value
stored at that address.

>  			pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n",
>  				     smp_processor_id(),
> -				     x86_feature_name(d->feature, feature_buf),
> -				     x86_feature_name(d->depends, depends_buf));
> +				     x86_cap_name(d->feature),
> +				     x86_cap_name(d->depends));
>  		}
>  	}
>  }

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

On 2026-02-12 at 16:28:10 -0800, Sohil Mehta wrote:
>On 2/12/2026 7:35 AM, Maciej Wieczor-Retman wrote:
>
>>
>> +const char *x86_cap_name(unsigned int bit)
>> +{
>> +	unsigned int word = bit >> 5;
>> +	static char undef_buf[16];
>> +	const char *name = NULL;
>> +
>> +	if (likely(word < NCAPINTS))
>> +		name = x86_cap_flags[bit];
>> +	else if (likely(word < NCAPINTS + NBUGINTS))
>> +		name = x86_bug_flags[bit - 32 * NCAPINTS];
>> +
>> +	if (name)
>> +		return name;
>> +
>> +	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
>> +	return undef_buf;
>> +}
>> +
>
>Isn't it unsafe to return undef_buf because the pointer is local to this
>function even though it is marked static?
>
>For example, the consecutive calls below would overwrite the value
>stored at that address.

I just rechecked and after I caused that pr_warn_once() to be executed the
strings are printed correctly.

Looking a bit further down, the pointers of the returned const char* are two
distinct values. So I assume because there are two calls to x86_cap_name() in
the pr_warn_once() the two static undef_buf char arrays are statically allocated
and there is no overwriting, but please correct me if that assumption is wrong.

>>  			pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n",
>>  				     smp_processor_id(),
>> -				     x86_feature_name(d->feature, feature_buf),
>> -				     x86_feature_name(d->depends, depends_buf));
>> +				     x86_cap_name(d->feature),
>> +				     x86_cap_name(d->depends));
>>  		}
>>  	}
>>  }

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Sohil Mehta]

On 2/13/2026 2:02 AM, Maciej Wieczor-Retman wrote:
> On 2026-02-12 at 16:28:10 -0800, Sohil Mehta wrote:
>> On 2/12/2026 7:35 AM, Maciej Wieczor-Retman wrote:
>>
>>>
>>> +const char *x86_cap_name(unsigned int bit)
>>> +{
>>> +	unsigned int word = bit >> 5;
>>> +	static char undef_buf[16];
>>> +	const char *name = NULL;
>>> +
>>> +	if (likely(word < NCAPINTS))
>>> +		name = x86_cap_flags[bit];
>>> +	else if (likely(word < NCAPINTS + NBUGINTS))
>>> +		name = x86_bug_flags[bit - 32 * NCAPINTS];
>>> +
>>> +	if (name)
>>> +		return name;
>>> +
>>> +	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
>>> +	return undef_buf;
>>> +}
>>> +
>>
>> Isn't it unsafe to return undef_buf because the pointer is local to this
>> function even though it is marked static?
>>
>> For example, the consecutive calls below would overwrite the value
>> stored at that address.
> 
> I just rechecked and after I caused that pr_warn_once() to be executed the
> strings are printed correctly.
> 

The issue would only happen if both d->feature and d->depends don't have
anything in x86_cap_flags[]. Was that true for your test?

> Looking a bit further down, the pointers of the returned const char* are two
> distinct values. So I assume because there are two calls to x86_cap_name() in
> the pr_warn_once() the two static undef_buf char arrays are statically allocated
> and there is no overwriting, but please correct me if that assumption is wrong.
> 

I don't think it works that way. As the variable is defined as "static",
only a single undef_buf is allocated. So the same pointer should be
returned after every call. I added the below dependency and it prints
the same feature twice.

"x86 CPU feature dependency check failure: CPU0 has '12:19' enabled but
'12:19' disabled. Kernel..."

diff --git a/arch/x86/kernel/cpu/cpuid-deps.c
b/arch/x86/kernel/cpu/cpuid-deps.c
index 1106a5476dca..51c482c18a2c 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -93,6 +93,7 @@ static const struct cpuid_dep cpuid_deps[] = {
        { X86_FEATURE_FRED,                     X86_FEATURE_LKGS      },
        { X86_FEATURE_SPEC_CTRL_SSBD,           X86_FEATURE_SPEC_CTRL },
        { X86_FEATURE_LASS,                     X86_FEATURE_SMAP      },
+       { X86_FEATURE_WRMSRNS,                  X86_FEATURE_FZRM},
        {}
 };


>>>  			pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n",
>>>  				     smp_processor_id(),
>>> -				     x86_feature_name(d->feature, feature_buf),
>>> -				     x86_feature_name(d->depends, depends_buf));
>>> +				     x86_cap_name(d->feature),
>>> +				     x86_cap_name(d->depends));
>>>  		}
>>>  	}
>>>  }
> 

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

On 2026-02-13 at 10:22:31 -0800, Sohil Mehta wrote:
>On 2/13/2026 2:02 AM, Maciej Wieczor-Retman wrote:
>> On 2026-02-12 at 16:28:10 -0800, Sohil Mehta wrote:
>>> On 2/12/2026 7:35 AM, Maciej Wieczor-Retman wrote:
>>>
>>>>
>>>> +const char *x86_cap_name(unsigned int bit)
>>>> +{
>>>> +	unsigned int word = bit >> 5;
>>>> +	static char undef_buf[16];
>>>> +	const char *name = NULL;
>>>> +
>>>> +	if (likely(word < NCAPINTS))
>>>> +		name = x86_cap_flags[bit];
>>>> +	else if (likely(word < NCAPINTS + NBUGINTS))
>>>> +		name = x86_bug_flags[bit - 32 * NCAPINTS];
>>>> +
>>>> +	if (name)
>>>> +		return name;
>>>> +
>>>> +	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
>>>> +	return undef_buf;
>>>> +}
>>>> +
>>>
>>> Isn't it unsafe to return undef_buf because the pointer is local to this
>>> function even though it is marked static?
>>>
>>> For example, the consecutive calls below would overwrite the value
>>> stored at that address.
>>
>> I just rechecked and after I caused that pr_warn_once() to be executed the
>> strings are printed correctly.
>>
>
>The issue would only happen if both d->feature and d->depends don't have
>anything in x86_cap_flags[]. Was that true for your test?

Ah, my bad, you're right, my test just returned the proper name not the word:bit
part.

>
>> Looking a bit further down, the pointers of the returned const char* are two
>> distinct values. So I assume because there are two calls to x86_cap_name() in
>> the pr_warn_once() the two static undef_buf char arrays are statically allocated
>> and there is no overwriting, but please correct me if that assumption is wrong.
>>
>
>I don't think it works that way. As the variable is defined as "static",
>only a single undef_buf is allocated. So the same pointer should be
>returned after every call. I added the below dependency and it prints
>the same feature twice.
>
>"x86 CPU feature dependency check failure: CPU0 has '12:19' enabled but
>'12:19' disabled. Kernel..."
>
>diff --git a/arch/x86/kernel/cpu/cpuid-deps.c
>b/arch/x86/kernel/cpu/cpuid-deps.c
>index 1106a5476dca..51c482c18a2c 100644
>--- a/arch/x86/kernel/cpu/cpuid-deps.c
>+++ b/arch/x86/kernel/cpu/cpuid-deps.c
>@@ -93,6 +93,7 @@ static const struct cpuid_dep cpuid_deps[] = {
>        { X86_FEATURE_FRED,                     X86_FEATURE_LKGS      },
>        { X86_FEATURE_SPEC_CTRL_SSBD,           X86_FEATURE_SPEC_CTRL },
>        { X86_FEATURE_LASS,                     X86_FEATURE_SMAP      },
>+       { X86_FEATURE_WRMSRNS,                  X86_FEATURE_FZRM},
>        {}
> };

So I'd think pr_cont() would work here best? Just tested it on your example and
it does work. Of course that quirk would have to be documented above the
function definition. Not sure if there is a better way while still keeping the
convenience of not having to pass any char pointers to the x86_cap_name():

pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled ", smp_processor_id(),
	     x86_cap_name(d->feature));
pr_cont("but '%s' disabled. Kernel might be fine, but no guarantees.\n", x86_cap_name(d->depends));

 x86 CPU feature dependency check failure: CPU0 has '12:19'
 	enabled but '12:10' disabled. Kernel might be fine, but no guarantees.


>
>>>>  			pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n",
>>>>  				     smp_processor_id(),
>>>> -				     x86_feature_name(d->feature, feature_buf),
>>>> -				     x86_feature_name(d->depends, depends_buf));
>>>> +				     x86_cap_name(d->feature),
>>>> +				     x86_cap_name(d->depends));
>>>>  		}
>>>>  	}
>>>>  }
>>
>

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Sohil Mehta]

On 2/13/2026 11:10 AM, Maciej Wieczor-Retman wrote:
> So I'd think pr_cont() would work here best? 

What about multi-threading? Would x86_cap_name() be called at the same
time from multiple CPUs?

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

On 2026-02-13 at 12:00:16 -0800, Sohil Mehta wrote:
>On 2/13/2026 11:10 AM, Maciej Wieczor-Retman wrote:
>> So I'd think pr_cont() would work here best?
>
>What about multi-threading? Would x86_cap_name() be called at the same
>time from multiple CPUs?

I guess you're right, there are too many ways this can backfire. I'll do what
Peter suggested and just try with passing a pointer from the calling function.

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[H. Peter Anvin]

On 2026-02-13 02:02, Maciej Wieczor-Retman wrote:
> On 2026-02-12 at 16:28:10 -0800, Sohil Mehta wrote:
>> On 2/12/2026 7:35 AM, Maciej Wieczor-Retman wrote:
>>
>>>
>>> +const char *x86_cap_name(unsigned int bit)
>>> +{
>>> +	unsigned int word = bit >> 5;
>>> +	static char undef_buf[16];
>>> +	const char *name = NULL;
>>> +
>>> +	if (likely(word < NCAPINTS))
>>> +		name = x86_cap_flags[bit];
>>> +	else if (likely(word < NCAPINTS + NBUGINTS))
>>> +		name = x86_bug_flags[bit - 32 * NCAPINTS];
>>> +
>>> +	if (name)
>>> +		return name;
>>> +
>>> +	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
>>> +	return undef_buf;
>>> +}
>>> +
>>
>> Isn't it unsafe to return undef_buf because the pointer is local to this
>> function even though it is marked static?
>>
>> For example, the consecutive calls below would overwrite the value
>> stored at that address.
> 
> I just rechecked and after I caused that pr_warn_once() to be executed the
> strings are printed correctly.
> 
> Looking a bit further down, the pointers of the returned const char* are two
> distinct values. So I assume because there are two calls to x86_cap_name() in
> the pr_warn_once() the two static undef_buf char arrays are statically allocated
> and there is no overwriting, but please correct me if that assumption is wrong.
> 

At the very least the buffer would need to be percpu for it to be safe. On the
other hand, there aren't a whole lot of places that uses this and the buffer
needed isn't that big, so the best way is probably to have the caller pass in
a buffer pointer on the stack. The callers are typically going to be large
functions which require a stack frame anyway.

	-hpa

Re: [PATCH v5 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

On 2026-02-13 at 12:15:24 -0800, H. Peter Anvin wrote:
>On 2026-02-13 02:02, Maciej Wieczor-Retman wrote:
>> On 2026-02-12 at 16:28:10 -0800, Sohil Mehta wrote:
>>> On 2/12/2026 7:35 AM, Maciej Wieczor-Retman wrote:
>>>
>>>>
>>>> +const char *x86_cap_name(unsigned int bit)
>>>> +{
>>>> +	unsigned int word = bit >> 5;
>>>> +	static char undef_buf[16];
>>>> +	const char *name = NULL;
>>>> +
>>>> +	if (likely(word < NCAPINTS))
>>>> +		name = x86_cap_flags[bit];
>>>> +	else if (likely(word < NCAPINTS + NBUGINTS))
>>>> +		name = x86_bug_flags[bit - 32 * NCAPINTS];
>>>> +
>>>> +	if (name)
>>>> +		return name;
>>>> +
>>>> +	snprintf(undef_buf, sizeof(undef_buf), "%u:%u", word, bit & 31);
>>>> +	return undef_buf;
>>>> +}
>>>> +
>>>
>>> Isn't it unsafe to return undef_buf because the pointer is local to this
>>> function even though it is marked static?
>>>
>>> For example, the consecutive calls below would overwrite the value
>>> stored at that address.
>>
>> I just rechecked and after I caused that pr_warn_once() to be executed the
>> strings are printed correctly.
>>
>> Looking a bit further down, the pointers of the returned const char* are two
>> distinct values. So I assume because there are two calls to x86_cap_name() in
>> the pr_warn_once() the two static undef_buf char arrays are statically allocated
>> and there is no overwriting, but please correct me if that assumption is wrong.
>>
>
>At the very least the buffer would need to be percpu for it to be safe. On the
>other hand, there aren't a whole lot of places that uses this and the buffer
>needed isn't that big, so the best way is probably to have the caller pass in
>a buffer pointer on the stack. The callers are typically going to be large
>functions which require a stack frame anyway.
>
>	-hpa
>

Sure, I'll change it to pass a pointer.

-- 
Kind regards
Maciej Wieczór-Retman

[PATCH v5 3/3] x86/cpu: Required feature bits sanity check

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

After cpu identification concludes, do a sanity check by comparing the
final x86_capability bitmask with the pre-defined required feature bits.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
 arch/x86/kernel/cpu/common.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 7aede0760ebc..5cf4f7174be8 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1987,6 +1987,36 @@ const char *x86_cap_name(unsigned int bit)
 	return undef_buf;
 }
 
+/*
+ * As a sanity check compare the final x86_capability bitmask with the initial
+ * predefined required feature bits. In case of a mismatch emit a warning with
+ * the faulty bitmask value.
+ */
+static void verify_required_features(const struct cpuinfo_x86 *c)
+{
+	u32 missing[NCAPINTS] = REQUIRED_MASK_INITIALIZER;
+	u32 error = 0;
+	unsigned int i;
+
+	for (i = 0; i < NCAPINTS; i++) {
+		missing[i] &= ~c->x86_capability[i];
+		error |= missing[i];
+	}
+
+	if (!error)
+		return;		/* All good */
+
+	/*
+	 * At least one required feature is missing. Print a warning,
+	 * and taint the kernel.
+	 */
+	pr_warn("cpu %d: missing required feature(s):", c->cpu_index);
+	for_each_set_bit(i, (void *)missing, NCAPINTS << 5)
+		pr_cont(" %s", x86_cap_name(i));
+	pr_cont("\n");
+	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+}
+
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
@@ -2116,6 +2146,8 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 	mcheck_cpu_init(c);
 
 	numa_add_cpu(smp_processor_id());
+
+	verify_required_features(c);
 }
 
 /*
-- 
2.53.0

Re: [PATCH v5 3/3] x86/cpu: Required feature bits sanity check

[H. Peter Anvin]

On 2026-02-12 07:35, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> 
> After cpu identification concludes, do a sanity check by comparing the
> final x86_capability bitmask with the pre-defined required feature bits.
> 
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

For as much as it matters (since I originally requested Maciej implemented this):

Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>

We really, really need this. We have this check in the BIOS boot stub, but
none of the modern stubs have included the equivalent code.

	-hpa

Re: [PATCH v5 0/3] x86: Capability bits fix and required bits sanity check

[H. Peter Anvin]

On 2026-02-12 07:33, Maciej Wieczor-Retman wrote:
> Series aims to fix the inconsistency between the cpuinfo behavior and
> the documentation. Specifically the features that are not compiled are
> still present in the cpuinfo bitmasks as enabled. This is not in line
> with the documentation which specifies that not-compiled features are
> not present in /proc/cpuinfo.
> 
> Along adding the disabled feature bitmask initializer array, the
> complementary required bitmask initializer is also added. It can be used
> to provide a sanity check, after the cpu identification is finished, to
> make sure every required bit is set in the final bitmask. A warning with
> the cpu number and all required bits that were not set is emitted in
> case of the sanity check failure.
> 
> Before adding the sanity check a small cleanup can be done. Three places
> open code an operation that retrieves either a feature string or, if the
> string is not present, the feature number in word:bit format. One of
> these places also doesn't check whether the string is actually there or
> not. The cleanup patch fixes that and simplifies the other two
> instances.

I am explicitly NOT suggesting this for this patchset, but in the future, I
would also like to see even the CPUID flags NOT included in /proc/cpuinfo to
be in the table, for the purpose of displaying kernel messages. I fully agree
that including them in /proc/cpuinfo is an unnecessary burden, but it would
still be good to be able to print them in messages in cleartext, *especially*
for when bits get reassigned or recycled.

I would also like to see the module ID strings for CPU features change from
using the numeric representation to the string representation for the same
reasons.

However, let me also say this: I don't think it makes any sense whatsoever to
aggressively compact those CPUID leaves that are likely to grow more bits in
the future (which aren't everyone, of course). It isn't like these words are
particularly expensive.

	-hpa