1. Patchew
  2. linux
  3. [PATCH v5 0/3] x86: Capability bits fix and required bits sanity check
  4. View patch

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

Maciej Wieczor-Retman posted 3 patches 1 month, 2 weeks ago
There is a newer version of this series
[PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time
Posted by Maciej Wieczor-Retman 1 month, 2 weeks ago 
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
Posted by Borislav Petkov 1 month, 2 weeks ago 
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
Posted by Maciej Wieczor-Retman 1 month, 2 weeks ago 
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
Posted by H. Peter Anvin 1 month, 2 weeks ago 
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
Posted by Borislav Petkov 1 month, 2 weeks ago 
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
Posted by Sohil Mehta 1 month, 2 weeks ago 
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
Posted by Borislav Petkov 1 month, 2 weeks ago 
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
Posted by Sohil Mehta 1 month, 2 weeks ago 
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
Posted by Borislav Petkov 1 month, 2 weeks ago 
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
Posted by H. Peter Anvin 1 month, 2 weeks ago 
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
Re: [PATCH v5 1/3] x86/cpu: Clear feature bits disabled at compile-time
Posted by Sohil Mehta 1 month, 2 weeks ago 
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.

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.