Re: Kernel Shadow Stacks Versus XFEATURE_MASK_GUEST_SUPERVISOR

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 23/10/2026 10:21 pm, Dave Hansen wrote:
> On 10/23/26 14:00, Paolo Bonzini wrote:
>> On 10/23/26 21:03, Dave Hansen wrote:
>>> Any thoughts on what we should do?
>>>
>>> Actually context switching XFEATURE_CET_KERNEL seems kinda silly in a
>>> lot of ways. PL0_SSP can always be derived _and_ it isn't actually even
>>> needed at context switch time, only when running userspace.
>> True but, just to understand, what is the performance like if you
>> actually use XSAVES/XRSTORS to update SSP0 on context switches instead
>> of WRMSR+cache?  Hopefully the microcode does a bunch of optimizations
>> as well.
> First, we can use WRMSRNS for this MSR, so it's faster than usual.
> Second, on kernel=>kernel context switches that don't go out to
> userspace, it doesn't need to be written at all. It's kinda like the
> user FPU state. Third, I'm actually reusing the fred_ssp0 cache, so
> further reduces the incremental cost.

XSTATE_CET_S is a weird thing.  It contains MSRs for PL{0..2}_SSP which
are the shstk equivalents of tss->rsp{0..2}.

The Ring1/2 aspects are practically useless; CET-SS was the thing which
finally caused me to put Ring1 PV kernels to rest.  All of
tss->rsp{0..2} are switched together, so I suppose PL{0..2}_SSP were
grouped for the same reason, not that 64bit OSes use task switching.

Windows uses %xmm in the main ABI, so already need to XSAVE/XRSTOR when
switching between kernel threads.  So it's "simple" to add one extra bit
to RFBM while doing this.


VMMs probably want to use XSTATE_CET_S simply to have the guest state
held together.  Even then, it does feel like a waste; PL1/2_SSP are
going to be 0 ~all of the time, while PL0_SSP is nonzero ~all of the
time in a CET-enabled kernel, so you can't even rely on the INIT
optimisation to speed things up.

Linux obviously doesn't want to do an X{SAVE,RSTOR}S between kernel
threads, and isn't using Rings 1/2, so the WRMSRNS approach seems fine. 
And I agree that it only needs to be good at the point of returning to
userspace.


> Fourth, it's not _really_
> context-switched. There's never a need to read the register. It can
> always be conjured out of thin air.

The requirements are different, depending on FRED or not.

Without FRED, PL0_SSP must point to a Supervisor Shadow Stack token. 
IRET marks the token non-busy (squashing any errors), and IDT delivery
checks it can atomically set the token busy, yielding #CP if not.

With FRED, ERETU checks that SSP == SL0_SSP and yields #CP on a
mismatch.  There are no checks on entry.

~Andrew