Instruction
RDSSPQ
Copies the 64-bit shadow-stack pointer into a register; a NOP where shadow stacks are off, which code can test for.
- Extensions
- Forms
- 1 (1 Legacy)
- Data
- Intel XED v2026.08.23
RDSSPQ copies SSP, the shadow-stack pointer, into a 64-bit register. Its use lies in what it does without a shadow stack: on a processor without CET, or while shadow stacks are off at the current privilege level, it is a NOP and the register keeps its value. Code that zeroes the register first can therefore ask whether its thread runs on a shadow stack, with no CPUID test and no system call: in user code, 0 means no. (In the kernel, SSP can be 0 with shadow stacks on: AMD’s manual has SYSCALL clear it.) Its bytes, F3 REX.W 0F 1E with a register operand, lie in the hint-NOP space 0F 18 to 0F 1F, as those of ENDBR64 do, which is how older processors skip it. RDSSPD, without REX.W, reads the low 32 bits.
The intrinsic decides what 0 means
_get_ssp() is the one that zeroes: with -mshstk, GCC 14 and Clang 23
at -O2 compile it to xor eax, eax and rdsspq rax. Clang 23 has two
more. _rdsspq(x) returns x where the instruction does nothing.
_rdsspq_i64() hands the instruction an uninitialized variable, and
Clang compiles it to a bare rdsspq rax: without shadow stacks it
returns whatever RAX held, so it says nothing about whether they are on.
GCC 14 has neither.
Popping to a saved point
A setjmp-like routine can save SSP next to RSP; the jump back then
pops the difference, one entry per 8 bytes, with
INCSSPQ. INCSSPQ raises #UD where shadow stacks are
off, so the saved 0 is also the test that skips it. SSP points at the
top entry, the return address of the latest CALL; the entries of the
callers lie above it, where only shadow-stack instructions such as
WRSSD may write.
On Linux, user shadow stacks need a processor that has them, a kernel
configured for them and libraries built for them; the loader enables
them per thread, and /proc/<pid>/status lists shstk among the
thread’s features when it runs with one.
AMD’s Zen 5 guide lists RDSSP 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 Zen 5 ran all three recorded cases as a NOP: RAX, R9 and RDX kept their values.
Forms
| Instruction | Encoding | Requires |
|---|---|---|
RDSSPQ r64 64-bit mode only
RDSSPQ_GPR64u64 | F3 REX.W 0F 1E /1 | CET |
Operation
What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.
if cr4 >> 23 & 1: # CR4.CET; clear without CET
cet = u_cet if CPL == 3 else s_cet
if cet & 1: # SH_STK_EN: shadow stacks on
dest.write(ssp)
# a NOP otherwise (a hint NOP, 0F 1E), so that the register keeps the
# value a program put thereRun on AMD Zen 5 (EPYC 9645): 3 cases. Its cases ran where CPUID reported no CET.
Operands
| Operand | Kind | Action |
|---|---|---|
RDSSPQ r64 64-bit mode only | ||
r64 | explicit | write |
SSP | implicit | read |
Flags
None: XED records no flag that the forms test or change.
Intrinsics
The C intrinsics of Clang 23.1.2 that compile to RDSSPQ, 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.
| Intrinsic | Compiles to |
|---|---|
_rdsspq
unsigned long long _rdsspq(unsigned long long __a) |
|
_rdsspq_i64
unsigned long long _rdsspq_i64(void) |
|
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.
| ISA set | CPUID | Processors |
|---|---|---|
CET | CET | Tiger Lake, Alder Lake, Arrow Lake, Panther Lake, Nova Lake, Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Sierra Forest, Clearwater Forest, Zen 3, Zen 4, Zen 5, Zen 6 Note: Zen 3 to Zen 6 have the shadow stacks of CET but not its indirect branch tracking, so ENDBR32 and ENDBR64 run on them as hint NOPs. AMD's references for Zen 3, Zen 4 and Zen 5 (55898, 55901, 57238) set CPUID_Fn00000007_ECX_x00[CET_SS] (bit 7) and leave bit 20 of CPUID_Fn00000007_EDX_x00, which Intel gives to indirect branch tracking, reserved and clear. Note: Zen 6 is listed because Zen 5 has these instructions. GCC's -march sets, which give the other features of Zen 6, leave them out, and AMD has not yet published a Processor Programming Reference for Zen 6. |
More CET instructions
Sources
- Intel XED v2026.08.23 (commit
0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model. - The CPU data of x86-64.net: Zen 3 to Zen 6, from GCC’s
-marchfeature sets and AMD’s Processor Programming References, which the page of each processor cites. - Clang's x86 intrinsic headers, LLVM 23.1.2 (commit
85ac56026243): the intrinsics, their signatures and doc comments, and the Clang of that release, which compiled each of them. - Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2B, page 4-558 (RDSSPD/
RDSSPQ) - Linux kernel documentation: Control-flow Enforcement Technology (CET) Shadow Stack
- Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1 (253665-093, September 2026)
- AMD64 Architecture Programmer's Manual, Volume 2: System Programming (24593, rev. 3.42, March 2024), Wayback Machine copy of AMD's PDF
- AMD64 Architecture Programmer's Manual, Volume 3: General-Purpose and System Instructions (24594, rev. 3.36, March 2024), Wayback Machine copy of AMD's PDF
- Software Optimization Guide for the AMD Zen5 Microarchitecture (58455, rev. 1.00, August 2024), Wayback Machine copy of AMD's ZIP
The tables are derived from Intel XED, Copyright Intel Corporation, licensed under the Apache License 2.0; x86-64.net converted and reformatted them. The intrinsics and their signatures come from Clang, part of the LLVM Project, licensed under the Apache License 2.0 with LLVM Exceptions. The text is our own.