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: <4c01a30a-67d9-4918-8781-240b78944c42@intel.com>
Date: Thu, 7 Nov 2024 17:12:51 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "H. Peter Anvin" <hpa@...or.com>, Sohil Mehta <sohil.mehta@...el.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/24 15:49, H. Peter Anvin wrote:
> Be careful - these bits are used in module strings and so modutils need to understand them.

Yeah, very true.  But I didn't ever see these features get used in a
MODULE_DEVICE_TABLE().  Do you still have concerns if there was never an
in-tree user that used X86_FEATURE_P3/P4 in a MODULE_DEVICE_TABLE()?$

Sohil, go look at:

# cat /sys/devices/system/cpu/modalias
cpu:type:x86,ven0000fam0006mod008C:feature:,0000,0001,0002,0003,0004,0005,0006,...

and, for instance:

# modinfo /lib/modules/5.17.0-rc4/kernel/arch/x86/kvm/kvm-intel.ko
filename:       /lib/modules/5.17.0-rc4/kernel/arch/x86/kvm/kvm-intel.ko
license:        GPL
author:         Qumranet
srcversion:     ED99EA15FCA9B58172BAEB4
alias:          cpu:type:x86,ven*fam*mod*:feature:*0085*

Those magic strings get matched up by udev (I think) to auto-load
modules when the CPU 'modalias' matches the module 'alias'.  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 */

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

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.