[PATCH] x86/fpu: Disable shstk if no CET_USER state

[PATCH] x86/fpu: Disable shstk if no CET_USER state

[David Kaplan]

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.

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..188323442b4d 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -855,6 +855,17 @@ void __init fpu__init_system_xstate(unsigned int legacy_size)
 		goto out_disable;
 	}
 
+	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_kernel_cfg.independent_features = fpu_kernel_cfg.max_features &
 					      XFEATURE_MASK_INDEPENDENT;
 

base-commit: d998c62f267213aeb815cf654908608eb7c00db2
-- 
2.53.0

Re: [PATCH] x86/fpu: Disable shstk if no CET_USER state

[Sean Christopherson]

On Fri, Apr 03, 2026, David Kaplan wrote:
> 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.

It's not actually broken though, is it?  Just "odd".  AFAICT, neither the SDM
nor the APM _requires_ CET_{U,S} to be supported in XSS if shadow stacks are
suppported.

> 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..188323442b4d 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -855,6 +855,17 @@ void __init fpu__init_system_xstate(unsigned int legacy_size)
>  		goto out_disable;
>  	}
>  
> +	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);

Doesn't this apply to IBT as well?  This code is also misplaced, as it needs to
live after at least this code:

	if (!cpu_feature_enabled(X86_FEATURE_XSAVES))
		fpu_kernel_cfg.max_features &= XFEATURE_MASK_USER_SUPPORTED;
	else
		fpu_kernel_cfg.max_features &= XFEATURE_MASK_USER_SUPPORTED |
					XFEATURE_MASK_SUPERVISOR_SUPPORTED;

and should probably play nice with the "out_disable" path too.

All in all, setup_cet() seems like a much better fit, but unfortunately that
runs before fpu__init_system() :-(

> +	}
> +
>  	fpu_kernel_cfg.independent_features = fpu_kernel_cfg.max_features &
>  					      XFEATURE_MASK_INDEPENDENT;
>  
> 
> base-commit: d998c62f267213aeb815cf654908608eb7c00db2
> -- 
> 2.53.0
> 

RE: [PATCH] x86/fpu: Disable shstk if no CET_USER state

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Sean Christopherson <seanjc@google.com>
> Sent: Friday, April 3, 2026 2:36 PM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Thomas Gleixner <tglx@kernel.org>; Ingo Molnar <mingo@redhat.com>;
> Borislav Petkov <bp@alien8.de>; Dave Hansen
> <dave.hansen@linux.intel.com>; x86@kernel.org; H. Peter Anvin
> <hpa@zytor.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/fpu: Disable shstk if no CET_USER state
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Fri, Apr 03, 2026, David Kaplan wrote:
> > 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.
>
> It's not actually broken though, is it?  Just "odd".  AFAICT, neither the SDM
> nor the APM _requires_ CET_{U,S} to be supported in XSS if shadow stacks
> are
> suppported.

The APM language at least isn't super clear on whether this is legal, but there are no real CPUs to my knowledge that do not enumerate XSS support for these.  But this configuration is definitely broken for Linux, because it will eventually crash with random segfaults (and unfortunately this often takes minutes to manifest since very few processes actually try to run with shadow stacks apparently).

>
> > 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..188323442b4d 100644
> > --- a/arch/x86/kernel/fpu/xstate.c
> > +++ b/arch/x86/kernel/fpu/xstate.c
> > @@ -855,6 +855,17 @@ void __init fpu__init_system_xstate(unsigned int
> legacy_size)
> >               goto out_disable;
> >       }
> >
> > +     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);
>
> Doesn't this apply to IBT as well?  This code is also misplaced, as it needs to
> live after at least this code:

Good point, it likely does.  I can't confirm that as I don't have IBT hardware, but assuming that a guest can see CET_IBT=1 this same problem would exist.


>
>         if (!cpu_feature_enabled(X86_FEATURE_XSAVES))
>                 fpu_kernel_cfg.max_features &=
> XFEATURE_MASK_USER_SUPPORTED;
>         else
>                 fpu_kernel_cfg.max_features &=
> XFEATURE_MASK_USER_SUPPORTED |
>                                         XFEATURE_MASK_SUPERVISOR_SUPPORTED;
>
> and should probably play nice with the "out_disable" path too.
>

Ok, that makes sense.  I'm not sure if the out_disable path ever gets used, but wouldn't that cause other problems if XSAVE is fully disabled?  I don't see it clearing any feature bits related to other XSTATE components.

--David Kaplan

> All in all, setup_cet() seems like a much better fit, but unfortunately that
> runs before fpu__init_system() :-(

RE: [PATCH] x86/fpu: Disable shstk if no CET_USER state

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Kaplan, David
> Sent: Friday, April 3, 2026 2:53 PM
> To: 'Sean Christopherson' <seanjc@google.com>
> Cc: Thomas Gleixner <tglx@kernel.org>; Ingo Molnar <mingo@redhat.com>;
> Borislav Petkov <bp@alien8.de>; Dave Hansen
> <dave.hansen@linux.intel.com>; x86@kernel.org; H. Peter Anvin
> <hpa@zytor.com>; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] x86/fpu: Disable shstk if no CET_USER state
>
>
>
> > > ---
> > >  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..188323442b4d 100644
> > > --- a/arch/x86/kernel/fpu/xstate.c
> > > +++ b/arch/x86/kernel/fpu/xstate.c
> > > @@ -855,6 +855,17 @@ void __init fpu__init_system_xstate(unsigned int
> > legacy_size)
> > >               goto out_disable;
> > >       }
> > >
> > > +     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);
> >
> > Doesn't this apply to IBT as well?  This code is also misplaced, as it needs to
> > live after at least this code:
>
> Good point, it likely does.  I can't confirm that as I don't have IBT hardware,
> but assuming that a guest can see CET_IBT=1 this same problem would exist.
>
>

Actually, I don't think this does apply to IBT as well.  Per Documentation/arch/x86/shstk.rst, only kernel IBT is currently supported by Linux.  And kernel IBT does not require either CET_USER or CET_KERNEL XSS support from what I see.  (CET_KERNEL is only for the shadow stack related MSRs)

--David Kaplan

Re: [PATCH] x86/fpu: Disable shstk if no CET_USER state

[Sean Christopherson]

On Fri, Apr 03, 2026, David Kaplan wrote:
> > From: Kaplan, David
> > > > ---
> > > >  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..188323442b4d 100644
> > > > --- a/arch/x86/kernel/fpu/xstate.c
> > > > +++ b/arch/x86/kernel/fpu/xstate.c
> > > > @@ -855,6 +855,17 @@ void __init fpu__init_system_xstate(unsigned int
> > > legacy_size)
> > > >               goto out_disable;
> > > >       }
> > > >
> > > > +     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);
> > >
> > > Doesn't this apply to IBT as well?  This code is also misplaced, as it needs to
> > > live after at least this code:
> >
> > Good point, it likely does.  I can't confirm that as I don't have IBT hardware,
> > but assuming that a guest can see CET_IBT=1 this same problem would exist.
> 
> Actually, I don't think this does apply to IBT as well.  Per
> Documentation/arch/x86/shstk.rst, only kernel IBT is currently supported by
> Linux.  And kernel IBT does not require either CET_USER or CET_KERNEL XSS
> support from what I see.  (CET_KERNEL is only for the shadow stack related
> MSRs)

KVM virtualizes IBT and SHSTK, for both user and kernel, and relies on the host
kernel to save/restore IA32_U_CET.

Note, I think xsave_cpuid_features[] is also flawed.  Per the SDM, {U,S}_CET also
exist if IBT is supported:

  Bit 20: CET_IBT. Supports CET indirect branch tracking features if 1. Processors
  that set this bit define bits 5:2 and bits 63:10 of the IA32_U_CET and IA32_S_CET
  MSRs.

The current code likely works because all "real" CPUs that support IBT also support
SHSTK.

RE: [PATCH] x86/fpu: Disable shstk if no CET_USER state

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Sean Christopherson <seanjc@google.com>
> Sent: Monday, April 6, 2026 9:27 AM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Thomas Gleixner <tglx@kernel.org>; Ingo Molnar <mingo@redhat.com>;
> Borislav Petkov <bp@alien8.de>; Dave Hansen
> <dave.hansen@linux.intel.com>; x86@kernel.org; H. Peter Anvin
> <hpa@zytor.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/fpu: Disable shstk if no CET_USER state
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Fri, Apr 03, 2026, David Kaplan wrote:
> > > From: Kaplan, David
> > > > > ---
> > > > >  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..188323442b4d 100644
> > > > > --- a/arch/x86/kernel/fpu/xstate.c
> > > > > +++ b/arch/x86/kernel/fpu/xstate.c
> > > > > @@ -855,6 +855,17 @@ void __init fpu__init_system_xstate(unsigned
> int
> > > > legacy_size)
> > > > >               goto out_disable;
> > > > >       }
> > > > >
> > > > > +     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);
> > > >
> > > > Doesn't this apply to IBT as well?  This code is also misplaced, as it needs
> to
> > > > live after at least this code:
> > >
> > > Good point, it likely does.  I can't confirm that as I don't have IBT hardware,
> > > but assuming that a guest can see CET_IBT=1 this same problem would
> exist.
> >
> > Actually, I don't think this does apply to IBT as well.  Per
> > Documentation/arch/x86/shstk.rst, only kernel IBT is currently supported by
> > Linux.  And kernel IBT does not require either CET_USER or CET_KERNEL XSS
> > support from what I see.  (CET_KERNEL is only for the shadow stack related
> > MSRs)
>
> KVM virtualizes IBT and SHSTK, for both user and kernel, and relies on the host
> kernel to save/restore IA32_U_CET.

I think you're talking about a nested virt scenario is that right?  So KVM in L1 virtualizes IBT/SHSTK for L2 and relies on the L1 kernel to save/restore IA32_UCET?  And the concern is that if L1 doesn't support the XSS components then this is broken.

But it looks like kvm_setup_xss_caps() appears to check if host XSS includes all the CET components and will clear X86_FEATURE_SHSTK/IBT if they aren't present.  So I think what you'd see is:

L0: CPUID says SHSTK/IBT supported.  XSS bits supported.
L1: CPUID says SHSTK/IBT supported.  XSS bits not supported
L2: CPUID doesn't say SHSTK/IBT supported.

Or did I misunderstand the scenario you're talking about?

>
> Note, I think xsave_cpuid_features[] is also flawed.  Per the SDM, {U,S}_CET
> also
> exist if IBT is supported:
>
>   Bit 20: CET_IBT. Supports CET indirect branch tracking features if 1.
> Processors
>   that set this bit define bits 5:2 and bits 63:10 of the IA32_U_CET and
> IA32_S_CET
>   MSRs.
>
> The current code likely works because all "real" CPUs that support IBT also
> support
> SHSTK.

Yeah that also looks incorrect, but benign (at least for now).

--David Kaplan

Re: [PATCH] x86/fpu: Disable shstk if no CET_USER state

[Sean Christopherson]

On Mon, Apr 06, 2026, David Kaplan wrote:
> > From: Sean Christopherson <seanjc@google.com>
> > On Fri, Apr 03, 2026, David Kaplan wrote:
> > > > From: Kaplan, David
> > > > > > ---
> > > > > >  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..188323442b4d 100644
> > > > > > --- a/arch/x86/kernel/fpu/xstate.c
> > > > > > +++ b/arch/x86/kernel/fpu/xstate.c
> > > > > > @@ -855,6 +855,17 @@ void __init fpu__init_system_xstate(unsigned
> > int
> > > > > legacy_size)
> > > > > >               goto out_disable;
> > > > > >       }
> > > > > >
> > > > > > +     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);
> > > > >
> > > > > Doesn't this apply to IBT as well?  This code is also misplaced, as it needs
> > to
> > > > > live after at least this code:
> > > >
> > > > Good point, it likely does.  I can't confirm that as I don't have IBT hardware,
> > > > but assuming that a guest can see CET_IBT=1 this same problem would
> > exist.
> > >
> > > Actually, I don't think this does apply to IBT as well.  Per
> > > Documentation/arch/x86/shstk.rst, only kernel IBT is currently supported by
> > > Linux.  And kernel IBT does not require either CET_USER or CET_KERNEL XSS
> > > support from what I see.  (CET_KERNEL is only for the shadow stack related
> > > MSRs)
> >
> > KVM virtualizes IBT and SHSTK, for both user and kernel, and relies on the host
> > kernel to save/restore IA32_U_CET.
> 
> I think you're talking about a nested virt scenario is that right?

FWIW, this isn't limited to running in a VM.  Booting on bare metal with
e.g. noxsaves=1 would lead to the same problematic scenario.

> So KVM in L1 virtualizes IBT/SHSTK for L2 and relies on the L1 kernel to
> save/restore IA32_UCET?  And the concern is that if L1 doesn't support the
> XSS components then this is broken.
> 
> But it looks like kvm_setup_xss_caps() appears to check if host XSS includes

Gah, -ENOCOFFEE, I forgot that KVM manually verifies that the kernel will context
switch CET.

> all the CET components and will clear X86_FEATURE_SHSTK/IBT if they aren't
> present.  So I think what you'd see is:
> 
> L0: CPUID says SHSTK/IBT supported.  XSS bits supported.
> L1: CPUID says SHSTK/IBT supported.  XSS bits not supported
> L2: CPUID doesn't say SHSTK/IBT supported.
> 
> Or did I misunderstand the scenario you're talking about?

RE: [PATCH] x86/fpu: Disable shstk if no CET_USER state

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Sean Christopherson <seanjc@google.com>
> Sent: Monday, April 6, 2026 10:32 AM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Thomas Gleixner <tglx@kernel.org>; Ingo Molnar <mingo@redhat.com>;
> Borislav Petkov <bp@alien8.de>; Dave Hansen
> <dave.hansen@linux.intel.com>; x86@kernel.org; H. Peter Anvin
> <hpa@zytor.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/fpu: Disable shstk if no CET_USER state
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Mon, Apr 06, 2026, David Kaplan wrote:
> > > From: Sean Christopherson <seanjc@google.com>
> > > On Fri, Apr 03, 2026, David Kaplan wrote:
> > > > > From: Kaplan, David
> > > > > > > ---
> > > > > > >  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..188323442b4d 100644
> > > > > > > --- a/arch/x86/kernel/fpu/xstate.c
> > > > > > > +++ b/arch/x86/kernel/fpu/xstate.c
> > > > > > > @@ -855,6 +855,17 @@ void __init
> fpu__init_system_xstate(unsigned
> > > int
> > > > > > legacy_size)
> > > > > > >               goto out_disable;
> > > > > > >       }
> > > > > > >
> > > > > > > +     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);
> > > > > >
> > > > > > Doesn't this apply to IBT as well?  This code is also misplaced, as it
> needs
> > > to
> > > > > > live after at least this code:
> > > > >
> > > > > Good point, it likely does.  I can't confirm that as I don't have IBT
> hardware,
> > > > > but assuming that a guest can see CET_IBT=1 this same problem would
> > > exist.
> > > >
> > > > Actually, I don't think this does apply to IBT as well.  Per
> > > > Documentation/arch/x86/shstk.rst, only kernel IBT is currently
> supported by
> > > > Linux.  And kernel IBT does not require either CET_USER or CET_KERNEL
> XSS
> > > > support from what I see.  (CET_KERNEL is only for the shadow stack
> related
> > > > MSRs)
> > >
> > > KVM virtualizes IBT and SHSTK, for both user and kernel, and relies on the
> host
> > > kernel to save/restore IA32_U_CET.
> >
> > I think you're talking about a nested virt scenario is that right?
>
> FWIW, this isn't limited to running in a VM.  Booting on bare metal with
> e.g. noxsaves=1 would lead to the same problematic scenario.
>

Btw, this does not appear to be a problem.  X86_FEATURE_SHSTK is marked as dependent on X86_FEATURE_XSAVES so booting with noxsaves seems to work fine.

--David Kaplan