RVOPcode
Home/Instructions/SSPUSH
SSPUSH

RISC-V SSPUSH Instruction Details

Instruction ManualSYSTEM (MOP.RR.7)

With xSSE=1, SSPUSH pushes x1/x5 onto the downward-growing shadow stack.

Instruction Syntax

sspush rs2

RV32/RV64 Zicfiss (depends on Zicsr, Zimop, Zaamo); sspush rs2, rs2 restricted to x1/x5.

32-bit SYSTEM: bits31:25=1100111, rs1=00000, funct3=100, rd=00000, opcode=1110011; rs2 is the source field.

With xSSE=1, store the XLEN-wide source at ssp−XLEN/8, committing the new ssp only after a successful store; the source register is not written.

With S-mode implemented, xSSE is 0 for M, menvcfg.SSE for S/HS, henvcfg.SSE for VS and senvcfg.SSE for U/VU; without S-mode, it is 0 for M/U. Compatibility requires Zimop support. With xSSE=0 there is no shadow-stack access or ssp update; when active, non-XLEN alignment raises store/AMO access-fault.

ZicfissSecurity Mechanisms
Related Search Terms
sspush instructionRISC-V sspushsspush syntaxsspush encodingsspush shadow-stack pushsspush CFIsspush shadow stack

Instruction Behavior

With xSSE=1, SSPUSH stores a shadow copy of x1 or x5 to the address ssp - XLEN/8, then commits ssp to that new value only after the shadow-stack store succeeds. It is used in non-leaf prologues alongside the normal stack return-address save.

SSPUSH Decode & Execute Animation

Shows only specification-defined encodings, conditions, and architectural state.

sspush x1
sspush
Execution Context

Assumes Zicfiss and Zimop are implemented; xSSE is the enable state determined for the current mode. ssp low two bits must be zero; RV64 inputs with bit2=1 assume 32-bit modes are also supported. complete means shadow-stack access protections pass. Steps are not processor cycles.

Instruction Encoding
31..25
MOP.RR.7
1100111
24..20
rs2
00001
19..15
rs1
00000
14..12
funct3
100
11..7
rd
00000
6..0
opcode
1110011 SYSTEM
Decode fixed fields
ssp=0x0000000000002000, x[x1]=0x0000000012345678
mem[0x0000000000001FF8] <- 0x0000000012345678; ssp <- 0x0000000000001FF8
Architectural state has not been committed.

Quick Understanding & Search Notes

SSPUSH is a Zicfiss shadow-stack push; it updates ssp only after the store completes.

Implicitly uses ssp and XLEN-wide memory accesses; with xSSE=0 there is no shadow-stack access or ssp update.
MOP compatibility when Zicfiss is absent or inactive requires Zimop support; processors without Zimop may raise an illegal-instruction exception.
The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture — Control-flow Integrity (20260120)The RISC-V Instruction Set Manual, Volume II: Privileged Architecture — Shadow Stack (20260120)

Common Usage Scenarios

Function Call & Return

Assume RV64 Zicfiss, S-mode, menvcfg.SSE=1 (xSSE=1), and ssp=0x2000. With x1=0x12345678, a permitted store completes with mem[0x1FF8]=0x12345678 and ssp=0x1FF8.

Shadow-stack checking and unwinding

Assume RV64 Zicfiss, S-mode, menvcfg.SSE=1 (xSSE=1), and ssp=0x2000. With x1=0x12345678, a permitted store completes with mem[0x1FF8]=0x12345678 and ssp=0x1FF8.

Pre-Use Checklist

Syntax Check
  • RV32/RV64 Zicfiss (depends on Zicsr, Zimop, Zaamo); sspush rs2, rs2 restricted to x1/x5.
  • 32-bit SYSTEM: bits31:25=1100111, rs1=00000, funct3=100, rd=00000, opcode=1110011; rs2 is the source field.
Semantic Check
  • With xSSE=1, store the XLEN-wide source at ssp−XLEN/8, committing the new ssp only after a successful store; the source register is not written.
  • With S-mode implemented, xSSE is 0 for M, menvcfg.SSE for S/HS, henvcfg.SSE for VS and senvcfg.SSE for U/VU; without S-mode, it is 0 for M/U. Compatibility requires Zimop support. With xSSE=0 there is no shadow-stack access or ssp update; when active, non-XLEN alignment raises store/AMO access-fault.

Pitfalls / Common Confusions

Only x1 and x5 are supported source link-register operands.
Zicfiss depends on the Zicsr, Zimop, and Zaamo extensions.
Shadow-stack protection is provided only when the corresponding Zicfiss state is enabled; otherwise the specified compatible behavior applies.
If the implicit shadow-stack store raises a store/AMO access, page, or guest-page fault, ssp is not updated.
If ssp is not XLEN-aligned, SSPUSH raises a store/AMO access-fault.
The accessed memory must be idempotent and PMP must allow read/write access; otherwise it raises a store/AMO access-fault.
Trap behavior depends on privilege level, environment configuration CSRs, and page-table/memory attributes.
ssp is decremented before the store address is formed, but the update commits only after the store succeeds.

FAQ

What happens if the related CFI feature is inactive for SSPUSH?

With xSSE=0, SSPUSH neither accesses the shadow stack nor updates ssp. Without Zicfiss but with Zimop, its MOP behavior also applies; without Zimop support an illegal-instruction exception is possible.

What official rule defines SSPUSH?

The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture defines this instruction in Control-flow Integrity; Volume II: Privileged Architecture defines enable state and shadow-stack memory protection.