linux-kernel - Re: [PATCH v2] 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: <2025072346-snowfall-graph-81ba@gregkh>
Date: Wed, 23 Jul 2025 15:37:24 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	"Kirill A. Shutemov" <kas@...nel.org>,
	Alexander Potapenko <glider@...gle.com>,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	Xin Li <xin3.li@...el.com>,
	Sai Praneeth <sai.praneeth.prakhya@...el.com>,
	Jethro Beekman <jethro@...tanix.com>,
	Jarkko Sakkinen <jarkko@...nel.org>,
	Sean Christopherson <seanjc@...gle.com>,
	Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghua.yu@...el.com>,
	"Mike Rapoport (IBM)" <rppt@...nel.org>,
	Kees Cook <kees@...nel.org>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Yu-cheng Yu <yu-cheng.yu@...el.com>, stable@...r.kernel.org,
	Borislav Petkov <bp@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] x86: Clear feature bits disabled at compile-time

On Wed, Jul 23, 2025 at 03:03:27PM +0200, Maciej Wieczor-Retman wrote:
> On 2025-07-23 at 13:57:34 +0200, Greg KH wrote:
> >On Wed, Jul 23, 2025 at 01:46:44PM +0200, Maciej Wieczor-Retman wrote:
> >> On 2025-07-23 at 11:45:22 +0200, Greg KH wrote:
> >> >On Wed, Jul 23, 2025 at 11:22:49AM +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() macro that returns 32 bit chunks of the disabled
> >> >> feature bits bitmask.
> >> >> 
> >> >> Initialize the cpu_caps_cleared and cpu_caps_set arrays with the
> >> >> contents of the disabled and required bitmasks respectively. Then let
> >> >> apply_forced_caps() clear/set these feature bits in the x86_capability.
> >> >> 
> >> >> Fixes: 6449dcb0cac7 ("x86: CPUID and CR3/CR4 flags for Linear Address Masking")
> >> >> Fixes: 51c158f7aacc ("x86/cpufeatures: Add the CPU feature bit for FRED")
> >> >> Fixes: 706d51681d63 ("x86/speculation: Support Enhanced IBRS on future CPUs")
> >> >> Fixes: e7b6385b01d8 ("x86/cpufeatures: Add Intel SGX hardware bits")
> >> >> Fixes: 6650cdd9a8cc ("x86/split_lock: Enable split lock detection by kernel")
> >> >> Fixes: 701fb66d576e ("x86/cpufeatures: Add CPU feature flags for shadow stacks")
> >> >> Fixes: ff4f82816dff ("x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions")
> >> >
> >> >That is fricken insane.
> >> >
> >> >You are saying to people who backport stuff:
> >> >	This fixes a commit found in the following kernel releases:
> >> >		6.4
> >> >		6.9
> >> >		3.16.68 4.4.180 4.9.137 4.14.81 4.18.19 4.19
> >> >		5.11
> >> >		5.7
> >> >		6.6
> >> >		5.10
> >> >
> >> >You didn't even sort this in any sane order, how was it generated?
> >> >
> >> >What in the world is anyone supposed to do with this?
> >> >
> >> >If you were sent a patch with this in it, what would you think?  What
> >> >could you do with it?
> >> >
> >> >Please be reasonable and consider us overworked stable maintainers and
> >> >give us a chance to get things right.  As it is, this just makes things
> >> >worse...
> >> >
> >> >greg k-h
> >> 
> >> Sorry, I certainly didn't want to add you more work.
> >> 
> >> I noted down which features are present in the x86_capability bitmask while
> >> they're not compiled into the kernel. Then I noted down which commits added
> >> these feature flags. So I suppose the order is from least to most significant
> >> feature bit, which now I realize doesn't help much in backporting, again sorry.
> >> 
> >> Would a more fitting Fixes: commit be the one that changed how the feature flags
> >> are used? At some point docs started stating to have them set only when features
> >> are COMPILED & HARDWARE-SUPPORTED.
> >
> >What would you want to see if you had to do something with a "Fixes:"
> >line?
> 
> I suppose I'd want to see a Fixes:commit in a place that hasn't seen too many
> changes. So the backport process doesn't hit too many infrastructure changes
> since that makes things more tricky.
> 
> And I guess it would be great if the Fixes:commit pointed at some obvious error
> that happened - like a place that could dereference a NULL pointer for example.
> 
> But I thought Fixes: was supposed to mark the origin point of some error the
> patch is fixing?
> 
> In this case a documentation patch [1] changed how feature flags are supposed to
> behave. But these flags were added in various points in the past. So what should
> Fixes: point at then?
> 
> But anyway writing this now I get the feeling that [1] would be a better point
> to mark for the "Fixes:" line.
> 
> [1] ea4e3bef4c94 ("Documentation/x86: Add documentation for /proc/cpuinfo feature flags")

If you feel that this patch should be backported to only 5.10 and newer,
great, that's the correct marking place.  If not, you might want to
reconsider it :)

thanks,

greg k-h