[v3] x86: Clear feature bits disabled at compile-time

[RESEND PATCH v3] x86: Clear feature bits disabled at compile-time

Posted by Maciej Wieczor-Retman 2 months, 1 week ago

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.

Add a DISABLED_MASK_INITIALIZER macro that creates an initializer list
filled with DISABLED_MASKx bitmasks.

Initialize the cpu_caps_cleared array with the autogenerated disabled
bitmask.

Fixes: ea4e3bef4c94 ("Documentation/x86: Add documentation for /proc/cpuinfo feature flags")
Reported-by: Farrah Chen <farrah.chen@intel.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Cc: <stable@vger.kernel.org>
---
Resend:
- Fix macro name to match with the patch message.
- Add Peter's SoB.

Changelog v3:
- Remove Fixes: tags, keep only one at the point where the documentation
  changed and promised feature bits wouldn't show up if they're not
  enabled.
- Don't use a helper to initialize cpu_caps_cleared, just statically
  initialize it.
- Remove changes to cpu_caps_set.
- Rewrite patch message to account for changes.

Changelog v2:
- Redo the patch to utilize a more generic solution, not just fix the
  LAM and FRED feature bits.
- Note more feature flags that shouldn't be present.
- Add fixes and cc tags.

 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 77afca95cced..a9040038ad9d 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -704,7 +704,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..1eabbc69f50d 100755
--- a/arch/x86/tools/cpufeaturemasks.awk
+++ b/arch/x86/tools/cpufeaturemasks.awk
@@ -84,5 +84,11 @@ END {
 		printf "\t) & (1U << ((x) & 31)))\n\n";
 	}
 
+		printf "\n#define DISABLED_MASK_INITIALIZER\t\t\t\\";
+		printf "\n\t{\t\t\t\t\t\t\\";
+		for (i = 0; i < ncapints; i++)
+			printf "\n\t\tDISABLED_MASK%d,\t\t\t\\", i;
+		printf "\n\t}\n\n";
+
 	printf "#endif /* _ASM_X86_CPUFEATUREMASKS_H */\n";
 }
-- 
2.49.0

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

Posted by Greg KH 2 months, 1 week ago

Your reply-to is messed up :(

On Thu, Jul 24, 2025 at 12:45:35PM +0200, Maciej Wieczor-Retman wrote:
> 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.
> 
> Add a DISABLED_MASK_INITIALIZER macro that creates an initializer list
> filled with DISABLED_MASKx bitmasks.
> 
> Initialize the cpu_caps_cleared array with the autogenerated disabled
> bitmask.
> 
> Fixes: ea4e3bef4c94 ("Documentation/x86: Add documentation for /proc/cpuinfo feature flags")
> Reported-by: Farrah Chen <farrah.chen@intel.com>
> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> Cc: <stable@vger.kernel.org>
> ---
> Resend:
> - Fix macro name to match with the patch message.

That's a v4, not a RESEND.

Doesn't Intel have a "Here is how to submit a patch to the kernel"
training program you have to go through?

confused,

greg k-h

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

Posted by Maciej Wieczor-Retman 2 months, 1 week ago

On 2025-07-24 at 13:34:44 +0200, Greg KH wrote:
>Your reply-to is messed up :(
>
>On Thu, Jul 24, 2025 at 12:45:35PM +0200, Maciej Wieczor-Retman wrote:
>> 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.
>> 
>> Add a DISABLED_MASK_INITIALIZER macro that creates an initializer list
>> filled with DISABLED_MASKx bitmasks.
>> 
>> Initialize the cpu_caps_cleared array with the autogenerated disabled
>> bitmask.
>> 
>> Fixes: ea4e3bef4c94 ("Documentation/x86: Add documentation for /proc/cpuinfo feature flags")
>> Reported-by: Farrah Chen <farrah.chen@intel.com>
>> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> Cc: <stable@vger.kernel.org>
>> ---
>> Resend:
>> - Fix macro name to match with the patch message.
>
>That's a v4, not a RESEND.
>
>Doesn't Intel have a "Here is how to submit a patch to the kernel"
>training program you have to go through?
>
>confused,
>
>greg k-h

The way I did it used to work for me previously, I'm not sure why it didn't this
time.

-- 
Kind regards
Maciej Wieczór-Retman

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

Posted by Maciej Wieczor-Retman 2 months, 1 week ago

On 2025-07-24 at 14:41:27 +0200, Maciej Wieczor-Retman wrote:
>On 2025-07-24 at 13:34:44 +0200, Greg KH wrote:
>>Your reply-to is messed up :(
>>
>>On Thu, Jul 24, 2025 at 12:45:35PM +0200, Maciej Wieczor-Retman wrote:
>>> 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.
>>> 
>>> Add a DISABLED_MASK_INITIALIZER macro that creates an initializer list
>>> filled with DISABLED_MASKx bitmasks.
>>> 
>>> Initialize the cpu_caps_cleared array with the autogenerated disabled
>>> bitmask.
>>> 
>>> Fixes: ea4e3bef4c94 ("Documentation/x86: Add documentation for /proc/cpuinfo feature flags")
>>> Reported-by: Farrah Chen <farrah.chen@intel.com>
>>> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
>>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>>> Cc: <stable@vger.kernel.org>
>>> ---
>>> Resend:
>>> - Fix macro name to match with the patch message.
>>
>>That's a v4, not a RESEND.
>>
>>Doesn't Intel have a "Here is how to submit a patch to the kernel"
>>training program you have to go through?
>>
>>confused,
>>
>>greg k-h
>
>The way I did it used to work for me previously, I'm not sure why it didn't this
>time.

I meant the reply-to being messed up used to work, this indeed should have been
v4, I'll submit it properly.

-- 
Kind regards
Maciej Wieczór-Retman