linux-kernel - Re: [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order table and accessor macro

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: <Z8DbEqXaxEB_4wmI@gmail.com>
Date: Thu, 27 Feb 2025 22:37:22 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: "Chang S. Bae" <chang.seok.bae@...el.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order
 table and accessor macro


* Dave Hansen <dave.hansen@...el.com> wrote:

> On 2/27/25 12:29, Ingo Molnar wrote:
> > My '#4' suggestion:
> > 
> >  - On bootup the CPU would not have the MPX/AVX bit enabled. So old 
> >    host kernels are fine as-is.
> 
> Could you be specific about "the MPX bit"? Because, first of all, there
> are a lot more than one bit in play here:
> 	
>  * The MPX state enumeration in CPUID.0DH:EAX[3:4]
>  * The MPX state enabling in XCR0[3:4]
>  * The MPX ISA enumeration CPUID.07H:EBX[14]
> 
> As far as the architecture goes, those XSAVE enabling/enumeration bits
> are rather independent from the _additional_ X86_FEATURE_MPX ISA CPUID bit.
> 
> Like I showed in my earlier example, the CPU enumerates which XSAVE
> features are available. These enumeration bits in CPUID leaf 0xd *ARE*
> set at boot independent of any other enabling or enumeration. In this
> regard, XSAVE enumeration is quite independent of the other parts of the
> ISA. This could, in theory, be changed to become dependent on some kind
> of APX enabling. But that would be novel for an XSAVE feature.

Yeah. That would be novel for an XSAVE feature - but so is the change 
in ordering. With my proposal we'd avoid the 
xfeature_noncompact_order[] indirection table AFAICS.

> Right now, the entirety of CPUID.0DH:EAX/EDX is static. It does not 
> change based on enumeration or other enabling. It can literally come 
> out of the microcode ROM.
> 
> So are you proposing that CPUID.0DH:EAX[3:4] would be 0x0 or 0x3 at 
> CPU reset? Or, that CPUID.0DH:EAX[3:4] would default to 0x0 at reset 
> and then flip to 0x3 based on some other kind of novel APX opt-in?

Yeah, I was thinking of a novel APX opt-in in the CPUID space, 
triggered via an MSR write or so, only triggered by APX-aware
host and guest kernels.

Old kernels would see 0 in all the legacy MPX state bits.

( Assuming this actually works for APX. )

Thanks,

	Ingo