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: <af4ec757-22fd-4438-91fc-d8778998bf07@intel.com>
Date: Thu, 27 Feb 2025 11:56:43 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Ingo Molnar <mingo@...nel.org>
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

On 2/27/25 11:36, Ingo Molnar wrote:
> 
>> 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.

The worry boils down to code in the kernel or userspace doing this:

	if (XGETBV(0) & 0x11)
		do_mpx_gunk();

So, sure, we could try to make sure that new kernels don't have any
do_mpx_gunk() in them, but that doesn't help old kernels or other OSes/VMMs.

The only thing that would help them would be to hide the XFEATURES 3/4
enumeration and require some kind of opt-in for it so that it can't be
enabled except with APX-aware software. That's totally possible, of
course. But it doesn't fix the userspace problem.

If folks really look at the diffstat:

>  10 files changed, 108 insertions(+), 57 deletions(-)

and hate it with _so_ much of a passion that we should go back and re
architect this thing, just say the word. I don't know how far along the
hardware is, but this kind of stuff is usually fixable in microcode. We
can totally go back to the drawing board and try to reuse XFEATURES 3/4
and see if there are any showstoppers (like with "other" OSes).

Let's just make sure that we've got a strong consensus amongst the
maintainer team, and I'm happy to oblige!