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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <674db309-e206-4bb4-bf99-b3c39bff7973@intel.com>
Date: Thu, 27 Feb 2025 11:32:31 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Ingo Molnar <mingo@...nel.org>, "Chang S. Bae" <chang.seok.bae@...el.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
 mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com
Subject: Re: [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order table
 and accessor macro

On 2/27/25 11:05, Ingo Molnar wrote:
> So why not just reuse the MPX feature number and have some sort of 
> extended feature bit that tells us and userspace that it's APX? The 
> xsave area is getting reused anyway - causing all this indirection and 
> trouble ...
> 
> Since we don't really do much for MPX in the kernel, and APX is not 
> supposed to be used by the kernel either, it should be pretty much a 
> shoe-in, right?

Theoretically, yes.

In practice, no.

MPX didn't have hardware enabling separate from the XSAVE enabling. So
there is software out there that assumes that if it can see the MPX bits
set in XCR0 that MPX is around. Take a look at kvm_mpx_supported() as an
example. Would you be comfortable having an old kernel which had
kvm_mpx_supported()==1 and X86_FEATURE_MPX==0? What about other VMMs?

There were basically three choices:

 1. Reuse XFEATURES 3/4 (MPX)
 2. Create a new out-of-order XFEATURE 19 that reuses MPX space
 3. Create a n in-order XFEATURE 19 that needs XFD and an opt-in

#1 risks breaking old MPX code in weird ways.

#2 requires teaching OSes about the out-of-order XSAVE offsets.

#3 is really nasty for hardware and software

So, you can blame me for picking (or consenting to) #2. But I do still
think it's the safest option. I'm not looking at this diffstat and
regretting the decision at all.

> What's the scope of MPX support in actual processors out in the wild?

IIRC, it showed up in Skylake, roughly 2015. By 2019, it was deprecated
and was mostly fused off in the "10th gen" CPUs:

> https://www.intel.com/content/www/us/en/support/articles/000059823/processors.html

APX is not out yet. No CPU will ever have APX and MPX, obviously.
There's also a ~5 year gap between CPUs that have one or the other.

Is that what you were asking?