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

[Sean Christopherson <seanjc@google.com>]

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?