WRSSQ instruction (CET, APX)

WRSSQ stores a 64-bit register into a shadow stack, 8 bytes where WRSSD stores 4. It is WRSSD’s encoding with REX.W, 0F 38 F6, and exists only in 64-bit mode, where shadow-stack entries are 8 bytes, so it is the form that can write a whole return address or token. Everything else is as on the WRSSD page: the store must go to a shadow stack of the current privilege level, or it raises #PF; it needs shadow stacks and the separate WR_SHSTK_EN bit enabled for that level, or it raises #UD; and on Linux a thread asks for it with arch_prctl(ARCH_SHSTK_ENABLE, ARCH_SHSTK_WRSS). WRUSSQ is the kernel’s way to write a user shadow stack.

Eight-byte alignment

The address must be 8-byte aligned, or WRSSQ raises #GP(0). Both manuals’ pseudocode tests bits 2:0 of the address for the 64-bit form; the exception lists of Intel’s entry mention only 4-byte alignment, which is WRSSD’s rule.

In our builds and on Zen 5

With -mshstk, _wrssq(v, p) compiles to WRSSQ in GCC 14 and Clang 23 at -O2. Clang 23 prints wrssq qword ptr [rsi], rdi in Intel syntax, and GCC 14.4 the same. GCC 14.2 puts the register first, wrssq rdi, QWORD PTR [rsi], which GNU as 2.44 rejects, so with -masm=intel it cannot build the call; its AT&T output, wrssq %rdi, (%rsi), assembles to 48 0F 38 F6 3E. GCC fixed the Intel order in March 2026 (PR 124366), as for WRSSD. In 32-bit code neither compiler declares _wrssq. APX adds an EVEX form in map 4 that reaches R16 to R31.

AMD’s Zen 5 guide lists WRSS 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 memory unchanged; no processor at hand has APX, so its form has no recorded cases.

Forms

Every encoding of WRSSQ that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`WRSSQ m64, r64` 64-bit mode only WRSSQ_MEMu64_GPR64u64	`REX.W 0F 38 F6 /r`	CET
`WRSSQ m64, r64` WRSSQ_MEMu64_GPR64u64_APX	`EVEX.LLZ.NP.MAP4.W1 66 /r`	APX_F + CET

Latency and throughput

What the scheduling models of LLVM 23.1.2 give for each form, not measurements: latency / reciprocal throughput in cycles, the ports under them. A row is a model, or models that agree; a dash, a form that its processors lack. Memory forms: latency from the address, ports without the load and store units. Which processors each model covers.

Model	`m64, r64`
Alder Lake, Sapphire Rapids	100 / 0.25p0156
Zen 3, Zen 4	100 / 25ALU0 ALU1 ALU2 ALU3

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 not cet & 2:                  # WR_SHSTK_EN: WRSS not allowed
    fault(UD)
a = dest.address
if not canonical(a):
    fault(GP, 0)                 # #SS(0) through RSP or RBP
if a & 7:
    fault(GP, 0)                 # 8-byte aligned
ss_store(a, 64, src.read())      # #PF unless a shadow-stack page of
                                 # CPL's kind: no other store
                                 # writes there

Run on AMD Zen 5 (EPYC 9645): 2 cases. Its cases ran where CPUID reported no CET, and every one raised an exception. The APX forms were not run: none of these processors has APX.

Operands

What each form reads and writes, as Intel XED records it: the operands of its syntax, in order, and the implicit ones that the syntax does not name. How to read.

Operand	Kind	Action
`WRSSQ m64, r64` 64-bit mode only
`m64`	explicit	write
`r64`	explicit	read

Flags

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

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

Legacy forms: none in XED
EVEX forms: APX-EVEX-CET-WRSS

Attributes

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

Legacy forms: not in real-address mode

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to WRSSQ, 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
`_wrssq` `void _wrssq(unsigned long long __a, void *__p)`	`WRSSQ m64, r64` Legacy -mshstk

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.

CPUID requirements and processors of the XED ISA sets above. Alternatives are separated by “or”; processors follow XED’s chip model, whose AMD processors end with Zen 2, and the CPU data of this site for Zen 3 to Zen 6.

ISA set	CPUID	Processors
`CET` CET	CET `CPUID.(EAX=07H,ECX=0):ECX[7]` 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 to Zen 6 (55898, 55901, 57238, 58264, 58655) 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.
`APX_F_CET` APX	APX_F + CET `CPUID.(EAX=07H,ECX=1):EDX[21]` APX_F `CPUID.(EAX=07H,ECX=0):ECX[7]` CET	Nova Lake, Diamond Rapids

More CET instructions

More APX instructions

All 88 APX instructions

Eight-byte alignment#

In our builds and on Zen 5#