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@xxxxxxxxxx>
> Sent: Monday, April 6, 2026 9:27 AM
> To: Kaplan, David <David.Kaplan@xxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>;
> Borislav Petkov <bp@xxxxxxxxx>; Dave Hansen
> <dave.hansen@xxxxxxxxxxxxxxx>; x86@xxxxxxxxxx; H. Peter Anvin
> <hpa@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> 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