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: <Z8C-xa7WB1kWoxqx@gmail.com>
Date: Thu, 27 Feb 2025 20:36:37 +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
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 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?

I'd absolutely be comfortable if the APX bit was only enabled by newer, 
APX-aware kernels. Older kernels would see a non-MPX CPU and would 
handle it properly.

I really don't see the issue:

> 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.

This is a false trichotomy. ;-)

There's a 4th option:

   4. Reuse XFEATURES 3/4 (MPX) only on APX-aware kernels, keep it 
      disabled for old kernels.

Problem solved.

> Is that what you were asking?

Yeah, thanks!

Thanks,

	Ingo