RSTORSSP

RSTORSSP moves a thread onto another shadow stack. A switch between coroutines or user-level threads loads a new RSP, and under CET the shadow stack has to follow; SSP cannot be written directly, so RSTORSSP moves it, but only onto a stack that carries a restore token: an 8-byte entry on top that records where that stack’s SSP stood when the token was made. The unwinding page notes that glibc’s longjmp uses it to return to a different shadow stack.

The checks#

The memory operand is the token’s address, which must be 8-byte aligned, or #GP(0), and lie in a shadow-stack page, or #PF. In one locked step RSTORSSP reads the token and checks that bit 0 matches 64-bit mode, bit 1 is clear, and the address it records, less 8 and rounded down to a multiple of 8, is the token’s own: a token is valid only right on top of the stack it describes. A failing token is written back unchanged and RSTORSSP raises #CP, with error code 4 in Intel’s list and 3 in AMD’s. A valid one is replaced by a previous-SSP token, the old SSP with bits 1 and 0 set, and SSP moves to the token’s address. As the read and the write are one locked operation, two threads cannot both take the same stack.

After the switch#

The previous-SSP token now on top tells SAVEPREVSSP where the old stack ended, so that it can leave a restore token there for the way back; a switch that never returns pops it with INCSSPQ instead. CF reports bit 2 of the restore token: the recorded SSP was 4-byte but not 8-byte aligned, a hole of 4 bytes that only 32-bit code leaves. OF, SF, ZF, AF and PF are cleared. SAVEPREVSSP reads that CF, so code between the two must not change it.

With -mshstk, GCC 14 compiles _rstorssp(p) to rstorssp QWORD PTR [rdi]; Clang 23’s Intel syntax prints dword ptr for the same 8-byte operand. Without shadow stacks enabled at the current privilege level, RSTORSSP raises #UD.

AMD’s Zen 5 guide lists RSTORSSP among the shadow-stack instructions Zen 5 supports, as microcoded. The KVM guest that ran the probe reported no shadow stacks in CPUID (leaf 07H, ECX bit 7), and both recorded cases raised #UD, with the token in memory unchanged.

Forms

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

if not cr4 >> 23 & 1:            # CR4.CET; clear without CET
    fault(UD)
cet = u_cet if CPL == 3 else s_cet
if not cet & 1:                  # SH_STK_EN: shadow stacks off
    fault(UD)
a = src.address                  # the restore token
if not canonical(a):
    fault(GP, 0)                 # #SS(0) through RSP or RBP
if a & 7:
    fault(GP, 0)                 # 8-byte aligned
t = ss_load(a, 64)               # locked until the store below
home = (t & ~1) - 8 & ~7         # where the token says it lies
ok = t & 3 == 1 and home == a    # L = 1 (64-bit mode), bit 1 clear
p = ssp | 3                      # previous-SSP token: SSP, L = 1
ss_store(a, 64, p if ok else t)  # a bad token is written back as
if not ok:                       # it was
    fault(CP, 4)                 # #CP(RSTORSSP)
ssp = a
cf = t >> 2 & 1                  # SSP in the token 4-byte aligned:
                                 # an alignment hole, which only
                                 # compatibility mode leaves
zf = pf = af = of = sf = 0

Operands

Flags

None: XED records no flag that the forms test or change.

Attributes

What else XED records about the forms. How to read.

All forms

not in real-address mode

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to RSTORSSP, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More CET instructions

• CLRSSBSY
• ENDBR32
• ENDBR64
• INCSSPD
• INCSSPQ
• RDSSPD
• RDSSPQ
• SAVEPREVSSP
• SETSSBSY
• WRSSD
• WRSSQ
• WRUSSD
• WRUSSQ