WRUSSD instruction (CET, APX)

WRUSSD stores the low 32 bits of a register into a user shadow stack, from the kernel. Unlike WRSSD, it does not depend on the WRSS enables or on shadow stacks being on at CPL 0: it needs only CR4.CET, or it raises #UD, and it runs only at CPL 0, or it raises #GP(0). Its store is a shadow-stack access made as if from user mode, the one exception to the rule that accesses at CPL 0 to 2 are supervisor accesses, so the destination must be a page that the page tables mark as a user shadow-stack page; any other page raises #PF. The address must be 4-byte aligned, or it raises #GP(0). WRUSSQ is the 8-byte form.

What the kernel writes

User code cannot write its own shadow stack without WRSS, which is off unless a thread asks for it, so a kernel that changes a user shadow stack does it with WRUSS. Linux, for one, puts entries there when it delivers a signal: as its documentation describes, it pushes the old shadow-stack pointer, in a token format with bit 63 set, and the signal restorer’s address, and checks the token on sigreturn. Linux supports shadow stacks only in 64-bit programs, whose entries are 8 bytes, which is WRUSSQ’s size; WRUSSD’s 4 bytes match the entries of 32-bit code.

Encoding and Zen 5

WRUSSD is 66 0F 38 F5. With -mshstk, _wrussd(v, p) compiles to it in GCC 14 and Clang 23 at -O2, in 64-bit and 32-bit code. In Intel syntax Clang 23 and GCC 14.4 print wrussd dword ptr [rsi], edi; GCC 14.2 puts the register first, wrussd edi, DWORD PTR [rsi], which GNU as 2.44 rejects; GCC fixed the order in March 2026 (PR 124366), as for WRSSD. AMD’s Zen 5 guide lists WRUSS as microcoded. Both cases recorded on Zen 5, at CPL 3 in a KVM guest that reports no shadow stacks, raised #UD, not #GP: CR4.CET was clear, and that test comes before the CPL test.

Forms

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

Instruction	Encoding	Requires
`WRUSSD m32, r32` WRUSSD_MEMu32_GPR32u32	`66 0F 38 F5 /r`	CET
`WRUSSD m32, r32` WRUSSD_MEMu32_GPR32u32_APX	`EVEX.LLZ.66.MAP4.W0 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	`m32, r32`
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 & 3:
    fault(GP, 0)                 # 4-byte aligned
ss_store_user(a, 32, src.read())
                                 # as a user access: #PF unless a
                                 # user shadow-stack page
# the kernel's way to write a process's shadow stack, which needs
# neither shadow stacks nor WRSS enabled

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
`WRUSSD m32, r32`
`m32`	explicit	write
`r32`	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 WRUSSD, 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
`_wrussd` `void _wrussd(unsigned int __a, void *__p)`	`WRUSSD m32, r32` 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

What the kernel writes#

Encoding and Zen 5#