WRUSSQ instruction (CET, APX)

WRUSSQ is the 8-byte form of WRUSSD: the kernel’s store of a 64-bit register into a user shadow stack, encoded 66 REX.W 0F 38 F5 and valid only in 64-bit mode. It shares WRUSSD’s rules: #UD without CR4.CET, #GP(0) above CPL 0, a store made as a user-mode shadow-stack access, so that only a user shadow-stack page takes it, and #PF for any other page. The WRUSSD page explains why a kernel needs it.

Alignment

The address must be 8-byte aligned, as in both manuals’ pseudocode for the 64-bit form, or WRUSSQ raises #GP(0); like the WRSSQ entry, the exception lists of Intel’s entry name only 4-byte alignment. A 64-bit shadow stack holds 8-byte entries, so an aligned WRUSSQ always writes exactly one, such as a return address or the token in which Linux saves the old shadow-stack pointer for a signal handler.

In our builds and on Zen 5

With -mshstk, _wrussq(v, p) compiles to WRUSSQ in GCC 14 and Clang 23 at -O2; neither declares it for 32-bit code. In Intel syntax Clang 23 and GCC 14.4 print wrussq qword ptr [rsi], rdi. GCC 14.2 prints wrussq rdi, QWORD PTR [rsi], which GNU as 2.44 rejects; its AT&T output is right. GCC fixed the order in March 2026 (PR 124366). Compared with WRSSQ, the opcode moves from F6 to F5 and gains the 66 prefix. AMD’s Zen 5 guide lists WRUSS as microcoded. The KVM guest that ran the probe reported no shadow stacks, and both recorded cases, at CPL 3, raised #UD, since the CR4.CET test comes before the CPL test.

Forms

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

Instruction	Encoding	Requires
`WRUSSQ m64, r64` 64-bit mode only WRUSSQ_MEMu64_GPR64u64	`66 REX.W 0F 38 F5 /r`	CET
`WRUSSQ m64, r64` WRUSSQ_MEMu64_GPR64u64_APX	`EVEX.LLZ.66.MAP4.W1 65 /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)
if CPL > 0:
    fault(GP, 0)
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_user(a, 64, src.read())
                                 # as a user access: #PF unless a
                                 # user shadow-stack page

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
`WRUSSQ 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-WRUSS

Attributes

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

All forms: privileged: CPL 0 only
Legacy forms: not in real-address mode

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to WRUSSQ, 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
`_wrussq` `void _wrussq(unsigned long long __a, void *__p)`	`WRUSSQ 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

Alignment#

In our builds and on Zen 5#