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

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc4w3nbkjzyrwmcjodrrwg7klgg532gre5v6fiwe3jvrww5egp@zezyxzny3ux4>
Date: Thu, 24 Jul 2025 12:59:47 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	"Dave Hansen" <dave.hansen@...ux.intel.com>, <x86@...nel.org>, "H. Peter
 Anvin" <hpa@...or.com>, Kyung Min Park <kyung.min.park@...el.com>, Ricardo
 Neri <ricardo.neri-calderon@...ux.intel.com>, Tony Luck
	<tony.luck@...el.com>, <xin3.li@...el.com>, Farrah Chen
	<farrah.chen@...el.com>, <stable@...r.kernel.org>, Borislav Petkov
	<bp@...e.de>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] x86: Clear feature bits disabled at compile-time

On 2025-07-24 at 13:12:33 +0300, Borislav Petkov wrote:
>On July 24, 2025 12:45:51 PM GMT+03:00, Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com> 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
>
>Where?

Oh sorry, must've forgotten to save the changes after I renamed it. Anyway I
just sent the corrected version as RESEND to this message.

>
>>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@...el.com>
>>Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
>>Cc: <stable@...r.kernel.org>
>>---
>>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.
>
>The behavior was there before. Why do you keep pointing at the patch which documents it?

Is my assumption incorrect, that before it was documented, the rules for feature
flags were more loose and afterwards they were more strict? So before that
documentation was written it could be classified under "undefined behavior".

As I wrote in the v2 thread, based on what's in the documentation added at the
commit I pointed out, the behavior is a bug. Features that are disabled -
due to not being compiled - are showing up in /proc/cpuinfo [1].

[1] https://github.com/torvalds/linux/blob/master/Documentation/arch/x86/cpuinfo.rst#the-kernel-disabled-support-for-it-at-compile-time

>
>-- 
>Sent from a small device: formatting sucks and brevity is inevitable.

-- 
Kind regards
Maciej Wieczór-Retman