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: <Z8DLKj8qdLb7MllO@gmail.com>
Date: Thu, 27 Feb 2025 21:29:30 +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:02, Ingo Molnar wrote:
> >>> 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();
> > New, APX-aware kernels wouldn't be doing this, why would they?
> 
> New, updated software is rarely the problem. It would not be a problem
> in this case either.
> 
> The problem is with old OSes/VMMs and even old userspace on new kernels.

So this is the 3rd time I have to repeat that if the MPX/AVX bit is 
disabled in the CPU by default on bootup, these old kernels will work 
fine just like they do today, so I think we might be talking past each 
other.

Let's try again:

> So I'm not _quite_ sure what you meant when you said:
> 
> > Old kernels would *never* see this bit enabled if it's disabled by
> > default on bootup ...
> 
> Because old kernel very much do see the MPX bits in CPUID and very 
> much do enable them by default via XSETBV.

My '#4' suggestion:

 - On bootup the CPU would not have the MPX/AVX bit enabled. So old 
   host kernels are fine as-is.

 - On new, AVX-aware host kernels, the AVX boot code enables the APX 
   bit (via a ususal CPUID discovery mechanism), which is the same as 
   the old MPX bit.

 - Likewise, the APX init code in APX-aware guest kernels would be able 
   to enable the APX bit as well. Old guest kernels will have the 
   APX/MPX bit disabled and will continue to work fine.

 - [ With this approach there's no out-of-order feature bit problem, 
     the APX feature bit lines up with the APX xsave area. Enabling AVX 
     would require very little code - only the CPUID discovery and MSR 
     twiddling to enable it in the FPU init path, plus similar KVM 
     code. ]

Thanks,

	Ingo