SAVEPREVSSP

SAVEPREVSSP finishes a switch that RSTORSSP began: it leaves a restore token on the shadow stack the thread has just left, so that a later RSTORSSP can come back to it. It takes no operand. The previous-SSP token that RSTORSSP put on top of the new stack holds the old stack’s SSP, and SAVEPREVSSP takes it from there.

What it writes#

• It reads the top entry, which must have bit 1 set, the mark of a previous-SSP token; otherwise #GP(0). SSP itself must be 8-byte aligned, or #GP(0).
• On the old stack it writes 4 zero bytes just below the recorded SSP, and then the restore token, that SSP with bit 0 set for 64-bit mode, in the 8 bytes at the next multiple of 8 below. Where the old SSP was only 4-byte aligned the zeroes fill the gap; in 64-bit code the token covers them.
• It pops the previous-SSP token: SSP grows by 8.

An example with our own numbers: a thread runs on stack A with SSP = 5000H, and stack B has a restore token at 8FF8H holding 9001H. rstorssp [8FF8H] sets SSP to 8FF8H and leaves 5003H there; SAVEPREVSSP then writes 5001H at 4FF8H on stack A and leaves SSP at 9000H, where B was. Later, rstorssp [4FF8H] switches back, as the token at 4FF8H passes the same check, 5000H less 8. Where the thread will not come back, INCSSPQ with a count of 1 pops the previous-SSP token instead.

CF links the two#

SAVEPREVSSP reads CF as RSTORSSP set it: CF = 1 announces a 4-byte hole above the token, which only 32-bit code leaves, so in 64-bit mode it raises #GP(0). An instruction between the two that sets CF, an ADD or a CMP, makes SAVEPREVSSP fault. AMD’s manual also raises #GP(0) when bit 0 of the token does not match the mode; Intel’s does not test it. SAVEPREVSSP changes no flag.

With -mshstk, GCC 14 and Clang 23 compile _saveprevssp() to the bare instruction; like the other shadow-stack instructions but RDSSP, it raises #UD where shadow stacks are off.

AMD’s Zen 5 guide lists SAVEPREVSSP 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.

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)
if ssp & 7:
    fault(GP, 0)
t = ss_load(ssp, 64)             # the previous-SSP token on top
if cf:                           # RSTORSSP's CF: a hole, which
    fault(GP, 0)                 # 64-bit mode never leaves
if not t & 2:                    # not a previous-SSP token
    fault(GP, 0)
old = t & ~3                     # the SSP of the stack left
ss_store(old - 4, 32, 0)         # 0 below it, the hole that aligning
                                 # may leave
ss_store((old & ~7) - 8, 64, old | 1)
                                 # a restore token, L = 1, on the
                                 # next 8 bytes down
ssp = ssp + 8                    # the token popped
# AMD's manual raises #GP(0) as well where bit 0 of the token, L,
# is not 1 in 64-bit mode; Intel's does not test it

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 SAVEPREVSSP, 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
• RSTORSSP
• SETSSBSY
• WRSSD
• WRSSQ
• WRUSSD
• WRUSSQ