Some hypervisors (including QEMU 10.1.5) may report CET_SS support in
CPUID Fn7 but fail to report that CET_USER state is supported in
supervisor xstate.  Linux relies on XSAVES/XRSTORS to swap CET state
during context switch and assumes it is supported when CET_SS is
present.

As a result, if a user process is run with shadow stacks enabled and
then is switched away from, the system may crash because the new process
may be incorrectly run with shadow stacks enabled.

Detect this broken configuration and disable user shadow stacks unless
CET_USER is supported in xstate.

v2:
 - Moved check to later location after fpu_kernel_cfg.max_features is
   finalized.

Signed-off-by: David Kaplan <david.kaplan@amd.com>
---
 arch/x86/kernel/fpu/xstate.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 76153dfb58c9..fb0412224005 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -878,6 +878,17 @@ void __init fpu__init_system_xstate(unsigned int legacy_size)
 		fpu_kernel_cfg.max_features &= XFEATURE_MASK_USER_SUPPORTED |
 					XFEATURE_MASK_SUPERVISOR_SUPPORTED;
 
+	if (boot_cpu_has(X86_FEATURE_USER_SHSTK) &&
+	    !(fpu_kernel_cfg.max_features & XFEATURE_MASK_CET_USER)) {
+		/*
+		 * The kernel relies on XSAVES/XRSTORS to context switch shadow
+		 * stack state.  If this isn't present, disable user shadow
+		 * stacks.
+		 */
+		pr_err("x86/fpu: CET_USER not supported in xstate when CET is supported.  Disabling shadow stacks.\n");
+		setup_clear_cpu_cap(X86_FEATURE_USER_SHSTK);
+	}
+
 	fpu_user_cfg.max_features = fpu_kernel_cfg.max_features;
 	fpu_user_cfg.max_features &= XFEATURE_MASK_USER_SUPPORTED;
 

base-commit: 6c927e5ca9d238f8ae40b453a8382eb9cf4ee855
-- 
2.53.0

On 4/8/26 07:30, David Kaplan wrote:
> +	if (boot_cpu_has(X86_FEATURE_USER_SHSTK) &&
> +	    !(fpu_kernel_cfg.max_features & XFEATURE_MASK_CET_USER)) {
> +		/*
> +		 * The kernel relies on XSAVES/XRSTORS to context switch shadow
> +		 * stack state.  If this isn't present, disable user shadow
> +		 * stacks.
> +		 */
> +		pr_err("x86/fpu: CET_USER not supported in xstate when CET is supported.  Disabling shadow stacks.\n");
> +		setup_clear_cpu_cap(X86_FEATURE_USER_SHSTK);
> +	}

Are there any more of these? I'm wondering if we want a table that's
effectively the reverse of xsave_cpuid_features[].

Maybe X86_FEATURE_ENQCMD at least?

On Thu, Apr 09, 2026 at 01:30:19PM -0700, Dave Hansen wrote:
> On 4/8/26 07:30, David Kaplan wrote:
> > +	if (boot_cpu_has(X86_FEATURE_USER_SHSTK) &&
> > +	    !(fpu_kernel_cfg.max_features & XFEATURE_MASK_CET_USER)) {
> > +		/*
> > +		 * The kernel relies on XSAVES/XRSTORS to context switch shadow
> > +		 * stack state.  If this isn't present, disable user shadow
> > +		 * stacks.
> > +		 */
> > +		pr_err("x86/fpu: CET_USER not supported in xstate when CET is supported.  Disabling shadow stacks.\n");
> > +		setup_clear_cpu_cap(X86_FEATURE_USER_SHSTK);
> > +	}
> 
> Are there any more of these? I'm wondering if we want a table that's
> effectively the reverse of xsave_cpuid_features[].
> 
> Maybe X86_FEATURE_ENQCMD at least?

Frankly, I'd like to not do anything here. If the HV is misconfigured, then it
crashing and burning as early is possible is better than us going out of our
way to try to fix up things...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Tue, May 05, 2026 at 04:05:58PM +0200, Borislav Petkov wrote:
> Frankly, I'd like to not do anything here. If the HV is misconfigured, then it
> crashing and burning as early is possible is better than us going out of our
> way to try to fix up things...

I guess we can do this (after talking to tglx):
	
	pr_err("x86/fpu: CET_USER not supported in xstate when CET is supported.  Disabling shadow stacks.\n");
	setup_clear_cpu_cap(X86_FEATURE_USER_SHSTK);
	add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);

the firmware workaround thing is to mean, *something* - HV or fw or whatever
- has made this nonsensical configuration so we taint.

When more "smart" configurations appear, we can do something like what
validate*xstate*() does to do some more checking.

And looking at the other checks in that code there in
fpu__init_system_xstate() why aren't we simply disabling XSAVE like we do for
XFEATURE_MASK_FPSSE and XFEATURE_MASK_APXX + FEATURE_MASK_BND* ?

This case looks exactly like those...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette