RET

RET pops 8 bytes and jumps there. Nothing checks that a CALL put them on the stack, so a function whose return address was overwritten, by a buffer overflow for example, returns wherever the new bytes point. CET’s shadow stacks close that hole: when they are enabled, RET also pops the copy that CALL wrote to the shadow stack and raises #CP if the two differ. Intel and AMD both have shadow stacks; on Linux the loader turns them on for programs whose ELF notes say they are built for it.

The forms:

• RET (C3) is the return of all ordinary 64-bit code.
• RET imm16 (C2) adds imm16 to RSP after the pop, releasing the stack arguments that the caller passed. 32-bit conventions in which the callee cleans up, such as __stdcall (see the 32-bit Windows conventions), end in it; in the 64-bit ABIs the caller owns its argument area, so compilers emit a plain RET.
• Far RET (CB, CA) pops RIP and then CS. Its default operand size in 64-bit mode is 32 bits, not 64: without REX.W it pops a 4-byte offset and a 4-byte slot for CS, so a frame built with two 8-byte PUSHes, as when 64-bit code enters a compatibility-mode segment, needs the REX.W form (lretq in AT&T syntax).

Things to know:

• Faults. A non-canonical return address raises #GP(0) at the RET, before RSP moves, as Zen 5 recorded: the bad address is still on top of the stack.
• Prediction. Processors predict a RET from a stack of the addresses that CALLs pushed (52 entries per thread on Zen 5, by AMD’s optimization guide). A RET whose address did not come from its matching CALL, such as a PUSH of an address followed by RET to jump there, is mispredicted; Intel’s optimization manual asks for calls and returns in pairs.
• 66 prefix. Intel’s manual fixes the operand size of near branches at 64 bits in 64-bit mode. AMD’s lets a 66 prefix make a near RET 16 bits: a 2-byte pop, with RIP cut to 16 bits.
• Straight-line speculation. Intel’s manual promises that the bytes after a near RET are not executed speculatively unless they are also a branch target or a predicted one. It makes no such promise after an indirect JMP or CALL.

In the optimization guide

What the optimization guide says about RET, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Branches

• Calls and returns: Returns are predicted by a return stack, which every call pushes and every return pops.
• Calls and returns: The return stack predicts returns only while calls and returns pair up, so pushing an address and jumping, or returning to a computed address, costs mispredictions.
• Calls and returns: A call that is the last thing a function does can become a jump to the callee, whose return then goes straight to the original caller.
• Calls and returns: Even predicted calls and returns cost time: each leaves the predictor idle for a cycle on Zen 3 and Zen 4, a return for two on Zen 5, and Agner Fog measured one every two cycles.

Bulldozer to Excavator

• Branches: The return address stack has 24 entries, so each call should have its ret: a deeper chain loses the oldest and an unpaired call desynchronises it, except a call to the very next instruction, which the core recognises.

Jaguar and Puma

• Branches: A 16-entry return stack that a call to the next instruction puts out of step, and no need for rep ret.

Sandy Bridge and Ivy Bridge

• Branches: The return stack buffer holds 16 near return addresses.

Silvermont to Goldmont Plus

• Branches: The return stack buffer holds 16 entries on Silvermont and Goldmont, twice the in-order Atom’s.

Skylake to Cooper Lake

• The JCC erratum: Under rare conditions a jump that crosses a 64-byte line could make these cores misbehave (erratum SKX102).

Zen and Zen+

• Branches: The return address stack has 32 entries, of which 31 can be used, and 15 per thread with two threads.

Zen 2

• Branches: The return address stack has 32 entries, 31 of them usable, and 15 per thread with two threads.

Zen 3

• Branches: The return address stack has 32 entries per thread.
• Integer execution: PUSH, POP, CALL and RET update RSP without a dependency, and loads, stores, lea and mov from RSP can use the tracked value.

Zen 4

• Branches: The return address stack has 32 entries per thread, against 52 on Zen 5.
• Integer execution: PUSH, POP, CALL and RET update RSP without a dependency, and loads, stores, lea and mov from RSP can use the tracked value.

Zen 5

• Branches: The return address stack has 52 entries per thread.
• Integer execution: PUSH, POP, CALL and RET update RSP without a dependency, and loads, stores, lea and add or sub of a small immediate through RSP can use the tracked value.

Vulnerability mitigations

Mitigations of these processor vulnerabilities use RET:

• CVE-2022-23824: Incomplete Branch Prediction Barrier (IBPB and Return Stack Buffer Interactions)
• CVE-2020-0551: Load Value Injection

Forms

Latency and throughput

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

w = OSIZE                        # the size of the return address:
if OSIZE == 16:                  # with 66, 2 bytes on AMD's (APM,
    if INTEL:                    # Zen 5)
        w = 64                   # ignored: SDM
t = load(rsp, w)                 # 8 bytes, or 2 zero-extended
if not canonical(t):
    fault(GP, 0)                 # RSP stays as it was
rsp = rsp + w // 8
rip = t

w = OSIZE                        # as RET's
if OSIZE == 16:
    if INTEL:
        w = 64                   # ignored: SDM
t = load(rsp, w)
if not canonical(t):
    fault(GP, 0)
rsp = rsp + w // 8 + size        # and size bytes more
rip = t

n = OSIZE // 8
off = load(rsp, OSIZE)
sel = load(rsp + n, OSIZE) & 0xFFFF
rsp = rsp + 2 * n                # to an outer privilege level, RSP
cs = sel                         # and SS are popped too; with the
rip = off                        # checks of the descriptor

n = OSIZE // 8
off = load(rsp, OSIZE)
sel = load(rsp + n, OSIZE) & 0xFFFF
rsp = rsp + 2 * n + size
cs = sel
rip = off

Operands

Flags

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

Attributes

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

RET imm16 RET

far transfer; may abort a TSX transaction

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.

More General-purpose instructions

• MOVS
• MOVSX
• MOVSXD
• MOVZX
• MUL
• NEG
• NOP
• NOT
• OR
• OUT
• OUTS
• PAUSE
• POP
• POPA
• POPF
• PUSH
• PUSHA
• PUSHF
• RCL
• RCR
• ROL
• ROR
• SALC
• SAR
• SBB
• SCAS
• SETcc
• SHL
• SHLD
• SHR
• SHRD
• STC
• STD
• STI
• STOS
• SUB
• TEST
• UD0
• UD1
• UD2

All 109 General-purpose instructions