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: <Z8HUK9bliN1sZYdL@google.com>
Date: Fri, 28 Feb 2025 07:20:11 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Ingo Molnar <mingo@...nel.org>, "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>, Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order table
 and accessor macro

On Thu, Feb 27, 2025, Dave Hansen wrote:
> On 2/27/25 13:37, Ingo Molnar wrote:
> ...
> >> 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.
> 
> Yeah, so with your proposal, we could toss out most of this series, so
> roughly 100 lines of code.
> 
> The downsides are:
> 
>  1. It can still confuse userspace, arguably in an architecture
>     violating manner because the SDM says: "If XCR0[4:3] is 11b, the
>     XSAVE feature set can be used to manage MPX state and software can
>     execute Intel MPX instructions." (this would be for userspace)
>    1a. Userspace like GDB still needs code to disambiguate XCR0[3:4]
>  2. It would add complexity in the XSAVE enumeration microcode. CPUID
>     data that comes right out of a ROM today would need to check some
>     CPU enabling state and change the enumeration.
>  3. Linux would still need to go fix up KVM in the kernel, like:
>     https://hansen.beer/~dave/intel/mpxapx.patch . Every APX-enabling
>     VMM would need something similar.
> 
> KVM folks, would you have any issues if XCR0[3:4] (the old MPX bits) got
> used for this new APX feature?

Yes.  I could live with complexity in KVM code, but I agree 100% with Andrew's
take:

  : XGETBV(0) & 0x18 in userspace has a very well defined meaning that is
  : MPX and not "MPX now but something unrelated in the future".

The risk of breaking guest kernels and guest userspace is decidedly non-zero.