linux-kernel - Re: [PATCH] x86/cpufeatures: Free up unused feature bits

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: <ee05e1a2-3844-4648-b9d5-7534de94d85e@intel.com>
Date: Fri, 8 Nov 2024 10:42:55 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, "H. Peter Anvin" <hpa@...or.com>,
	<x86@...nel.org>, Borislav Petkov <bp@...en8.de>, Dave Hansen
	<dave.hansen@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	"Sean Christopherson" <seanjc@...gle.com>, Tony Luck <tony.luck@...el.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/cpufeatures: Free up unused feature bits

On 11/7/2024 5:12 PM, Dave Hansen wrote:
> Let's say
> we had an ooooooooold module that did this:
> 
> #ifdef MODULE
> static const struct x86_cpu_id foo_cpu_id[] = {
>         X86_MATCH_FEATURE(X86_FEATURE_P3, NULL),
>         {}
> };
> MODULE_DEVICE_TABLE(x86cpu, foo_cpu_id);
> #endif
> 
> which generated a modalias like this:
> 
> 	alias:          cpu:type:x86,ven*fam*mod*:feature:*0067*
> 
> and then we recycled number 67:
> 
> -#define X86_FEATURE_P3                  ( 3*32+ 6) /* P3 */
> +#define X86_FEATURE_WHIZZY_NEW_FEATURE  ( 3*32+ 6) /* P3 */
> 

Coretemp (hwmon) seems to follow this pattern exactly.

commit 9b38096fde5f ("HWMON: Convert coretemp to x86 cpuid autoprobing")
adds X86_FEATURE_DTS to MODULE_DEVICE_TABLE(x86cpu, coretemp_ids)

commit 2ccd71f1b278 ("x86/cpufeature: Move some of the scattered feature
bits to x86_capability") frees up X86_FEATURE_DTS(DTHERM).

-#define X86_FEATURE_DTHERM     ( 7*32+ 7) /* Digital Thermal Sensor */

commit 765a0542fdc7 ("x86/virt/tdx: Detect TDX during kernel boot")
reuses that bit.

+#define X86_FEATURE_TDX_HOST_PLATFORM  ( 7*32+ 7) /* Platform supports
being a TDX host */

> udev might try to load the old module on a new CPU with
> X86_FEATURE_WHIZZY_NEW_FEATURE that's not a P3.
> 

So an old coretemp module could get loaded when the above TDX bit is
set. Not sure how likely this scenario is or what can we do to avoid it now?

> I sure hope we haven't been using too many of these synthetic features
> in MODULE_DEVICE_TABLE()s, because we tend to move them around, but I
> guess it's possible.

At least features X86_FEATURE_P3 and X86_FEATURE_P4 seem safe to be
recycled as they haven't been used in MODULE_DEVICE_TABLE().