Inception Under the Hood: How AMD Zen 4 Return Address Security Discloses Speculative Execution to Training Injections

Following the disclosure of Spectre, Meltdown, and Retbleed, modern microprocessor designers declared that hardware-level return address defenses had finally neutralized speculative execution side-channels. Advanced x86 microarchitectures introduced dedicated silicon mechanisms—such as Indirect Branch Restricted Speculation (eIBRS), Return Address Stack (RAS) depth tracking, and Automatic IBPB—specifically designed to prevent unprivileged software from poisoning CPU branch targets across security boundaries. But in mid-2023, security researchers at ETH Zurich unveiled Inception (CVE-2023-20569), a microarchitectural exploit that completely dismantles AMD’s flagship Zen 3 and Zen 4 hardware security foundations. By engineering a radical technique called Phantom Speculative Execution paired with Training in Transient Execution (TTE), Inception coerces the CPU into manufacturing imaginary branch instructions out of non-branch opcodes, injecting attacker-controlled targets into the Return Address Stack without requiring virtual address collisions. The result is a universal cross-privilege leak delivering 30 kilobytes per second of unrestricted kernel and hypervisor memory.

1. Speculative Branch Predictors & The Return Address Stack (RAS)

To execute instructions at multi-gigahertz speeds without stalling on high-latency memory accesses, modern superscalar CPUs predict the outcome of program control flow dozens of cycles before instructions are formally decoded.

When a CPU encounters a subroutine call instruction (such as x86 CALL), the microarchitecture pushes the target return address onto an architectural stack in physical RAM, and simultaneously pushes that address onto an internal hardware circular FIFO structure called the Return Address Stack (RAS).

When the CPU later encounters the corresponding subroutine return instruction (RET):

1. Fast Speculative Path: The CPU pops the top entry from the internal hardware RAS and speculatively steers the instruction fetch unit (IFU) to that address immediately, avoiding a 150-cycle stall on L1/DRAM stack retrieval.
2. Architectural Verification: Cycles later, the true return address is read from RAM stack memory. If the architectural address matches the speculatively popped RAS entry, execution proceeds smoothly without penalty.
3. RAS Underflow Mechanism: If deeply nested call stacks exceed the physical RAS depth (e.g., 32 entries on Zen 3/4), the hardware RAS underflows. To prevent pipeline stalls, AMD Zen microarchitectures fall back to predicting the return address using the Branch Target Buffer (BTB)!

This fallback mechanism was the core vulnerability exploited by Retbleed (2022). In response, AMD hardened Zen 3 and Zen 4 silicon with hardware-level Return Address Security features: restricting BTB updates, isolating branch prediction arrays across privilege boundaries, and inserting automated fences on kernel entry.

Microarchitectural Anatomy: The Decoupled AMD Zen 4 Branch Prediction Engine

To understand why Inception is unique to AMD Zen microarchitectures, one must inspect how Zen 3 and Zen 4 organize their instruction front-end.

In modern high-performance microprocessors, the instruction pipeline is split into an autonomous Front-End Fetch Engine and a downstream Execution/Retirement Core. The AMD Zen 4 front-end contains a multi-level branch prediction hierarchy designed to supply up to 32 bytes of instructions per clock cycle to the decode unit:

• L1 Branch Target Buffer (L1 BTB): A small, ultra-fast 1,024-entry array that provides single-cycle branch target predictions to prevent fetch bubbles.
• L2 Branch Target Buffer (L2 BTB): A massive 6,144-entry secondary array backed by an aggressive Tagged Geometric History Length (TAGE) directional branch predictor capable of tracking branch patterns across thousands of instructions.
• Return Address Stack (RAS): A 32-entry circular FIFO array tracking function call depths.

Crucially, to achieve extreme clock frequencies, AMD decoupled the L1/L2 BTB lookup from the instruction pre-decode byte scanner. The BTB indexes solely based on the lowest bits of the program counter (\(\text{PC}\)). If the BTB contains an entry for a specific address offset, it initiates a speculative branch redirection before the processor even knows what instruction bytes reside at that memory location!

2. Phantom Speculative Execution: Creating Branches Out of Nothing

Inception’s first breakthrough lies in discovering that AMD Zen microarchitectures suffer from Phantom Speculative Execution.

Prior to Inception, all speculative execution research operated under a universal paradigm: an attacker had to find a real, architecturally valid branch instruction (such as JMP, CALL, or RET) inside the victim’s address space or binary, and manipulate its branch history.

Phantom Speculative Execution shatters this assumption. The researchers discovered that the AMD Zen Branch Prediction Unit (BPU) evaluates branch predictions completely decoupled from and ahead of the instruction decode pipeline!

Because the CPU treats this phantom instruction as a branch during the transient execution window, it allocates state inside the branch prediction structures, creating an architectural ghost that violates the integrity of the decoder.

3. Training in Transient Execution (TTE): The Recursive Poisoning Loop

The second, even more devastating component of Inception is Training in Transient Execution (TTE).

In all previously analyzed microarchitectures, engineers assumed that CPU branch predictors were only updated by instructions that actually retired and committed architecturally. If an instruction was speculatively fetched down a mispredicted branch path and later squashed, any branch predictions made during that transient window were presumed to be harmlessly discarded.

Inception demonstrated that AMD Zen 3 and Zen 4 processors update their branch prediction arrays during transient, speculatively mispredicted execution paths!

By chaining Phantom Branches with Training in Transient Execution, an attacker creates a recursive feedback loop:

1. The attacker triggers a mispredicted conditional branch, entering a transient execution window.
2. Inside this transient window, the core encounters a phantom CALL instruction.
3. The phantom CALL pushes a malicious return target address directly onto the hardware Return Address Stack (RAS).
4. When the transient window collapses, the CPU flushes the Reorder Buffer (ROB) registers—but the poisoned return address remains permanently logged inside the physical hardware RAS!
5. When a subsequent privileged subroutine (such as a Linux kernel system call or hypervisor interrupt) executes an architectural RET instruction, the core pops the attacker’s poisoned address, speculatively redirecting supervisor execution to an arbitrary side-channel disclosure gadget.

Step-by-Step Proof-of-Concept Exploit Execution Flow

The end-to-end Inception exploit demonstrates that an attacker can systematically extract 64-bit kernel memory pointers and cryptographic keys in four deterministic stages:

1. BTB Alias Priming: The attacker executes a dense chain of real direct call instructions in unprivileged userspace, training the BTB to associate address \(VA_{\text{phantom}}\) with a specific target address in user memory containing a disclosure gadget.
2. Phantom Instruction Substitution: The attacker rewires memory mapping or points execution to a non-branch instruction sequence at \(VA_{\text{phantom}}\) (such as xor eax, eax; nop; nop). The decoupled BTB predicts a branch anyway, speculatively executing a phantom CALL.
3. RAS Cross-Privilege Contamination: The phantom CALL pushes the attacker’s chosen return target onto the hardware Return Address Stack. When the transient branch rolls back, the poisoned entry remains in the RAS.
4. Kernel System Call Trigger & Cache Side-Channel Extraction: The attacker issues a standard Linux system call (e.g. write() or pread()). When the kernel finishes executing and prepares to return via architectural RET, the hardware pops the attacker’s poisoned address. The CPU speculatively loads target kernel bytes (such as /etc/shadow or RSA keys) into the Level 1 Data Cache. The attacker subsequently probes L1D cache access latency via Flush+Reload, recovering secret bytes at 30 kilobytes per second!

4. Exploit Comparison: Inception vs. Spectre-v2 vs. Retbleed

To appreciate why Inception created such alarm within the cloud infrastructure community, consider how its microarchitectural mechanics contrast with prior branch prediction vulnerabilities:

Because Inception does not require branch address collisions, it works universally across arbitrary address spaces. An unprivileged user running inside a sandboxed Linux container or guest virtual machine can leak arbitrary hypervisor physical RAM without knowing the virtual memory layout of the host.

5. Silicon Remediation: Microcode Updates & Performance Impact

When the ETH Zurich researchers privately disclosed Inception to AMD, the semiconductor giant determined that Inception cannot be mitigated purely in software without catastrophic performance destruction. Software trampolines (like Retpoline) rely on RET instructions, which are the very target of Inception’s poisoning loop!

AMD was forced to engineer new CPU microcode updates for Zen 3 (Milan / Chagall / Vermeer) and Zen 4 (Genoa / Raphael / Bergamo) processors:

1. Automatic Indirect Branch Predictor Barrier (Auto-IBPB)

The microcode update introduces an automated mode for the Indirect Branch Predictor Barrier (IBPB). When software transitions across privilege boundaries (such as a kernel context switch via SYSENTER or a KVM VM-exit):

Executing an IBPB forces the CPU core to completely purge all entries inside the Branch Target Buffer and Return Address Stack, preventing transient predictions from surviving into the kernel.

2. Workload Performance Benchmarks Under Auto-IBPB

Purging the branch predictor on every context switch carries a measurable performance tax:

• High-Syscall Web Gateways (NGINX / Envoy): Throughput drops by 3.5% to 5.8% due to branch prediction cold misses following system call transitions.
• Database Transaction Processing (PostgreSQL / Redis): Queries per second (QPS) decline by 2.1% to 4.2%.
• Pure Compute & AI Training (BLAS / PyTorch): Negligible impact (< 0.5%), because mathematical workloads execute long uninterrupted matrix loops inside userspace without context switching.

Microarchitectural Gadget Assembly & Transient Training Code Walkthrough

To understand how Inception forces the processor into executing arbitrary kernel code speculatively, we examine the disassembly of the microarchitectural Training in Transient Execution (TTE) gadget. The attacker engineers a nested loop structure wherein a conditional branch condition depends on an uncached memory address, guaranteeing an architectural pipeline stall of approximately 250 clock cycles:

; Inception Transient Training in Transient Execution (TTE) Primitive
; Registers: rdi = probe_array, rsi = uncached_flag, rbx = target_training_addr
.align 64
clflushopt  [rsi]                   ; Invalidate cache line to force branch misprediction
mfence                              ; Memory fence ensuring cache invalidation commits
mov         rax, [rsi]              ; Load uncached flag (miss in L1/L2/L3, stalls pipeline)
test        rax, rax
jnz         .target_branch_label    ; Branch predictor speculates fallthrough path!

; --- TRANSIENT WINDOW BEGINS HERE (Zen 4 executes ~180-220 instructions speculatively) ---
mov         rdx, 0x41414141         ; Non-branch instruction at ghost address
call        .phantom_call_target    ; Phantom branch creates transient RAS push
.phantom_call_target:
pop         rcx                     ; Extract pushed RIP in transient domain
add         rcx, 0x1000             ; Compute malicious target offset
push        rcx                     ; Push attacker-chosen spec target to RAS!
ret                                 ; Return speculatively executes at hijacked kernel target!

; --- SPECULATIVE EXFILTRATION GADGET ---
movzx       rbx, byte ptr [r8]      ; Transiently read target secret kernel byte
shl         rbx, 0xC                ; Multiply by 4096 (4KB page stride to evade hardware prefetchers)
mov         al, [rdi + rbx]         ; Bring probe_array[secret * 4096] into L1 Data Cache
; --- ARCHITECTURAL RETIREMENT SQUASHES TRANSIENT STATE ---
.target_branch_label:
; Attacker measures probe_array access latency via RDTSCP

In this assembly sequence, the clflushopt forces the outer conditional branch predictor to guess the outcome while the memory controller queries system DRAM. During this 200-cycle transient speculative window, the Zen 4 execution units process the phantom call gadget. Because the front-end branch predictor tags the instruction stream speculatively before decode retirement, the transient return address pushes directly into the internal 32-entry circular hardware RAS. When the subsequent RET instruction executes within the transient window, it pops the attacker-poisoned target rather than the genuine architectural call site.

Cache Side-Channel Metrology & L3 Prefetcher Evasion Mechanics

Once the CPU speculatively accesses the secret kernel memory byte \(S \in [0, 255]\), the attacker must extract this byte without triggering a fatal architectural Page Fault exception (since the user-space process lacks supervisor read privileges). This is accomplished via a calibrated Flush+Reload side-channel across the shared Core Complex (CCX) Last Level Cache (L3).

On AMD Zen 4 CCDs (Core Complex Dies), each 8-core CCX shares a 32 MB unified L3 cache partitioned into slices. To prevent the hardware L2 Stream Prefetcher and L1 Next-Line Prefetcher from artificially populating adjacent cache lines, the probe array allocates 256 distinct 4,096-byte pages (a total allocation of 1 MB of virtual memory). The attacker reads the time-stamp counter using serialized RDTSCP instructions before and after querying each offset:

By establishing an empirical decision threshold \(T_{\text{threshold}} = 85 \text{ cycles}\), the attacker scans all 256 page offsets. The unique offset yielding an access time \(t < 85 \text{ cycles}\) reveals the exact value of the secret kernel byte. Across unmitigated Zen 4 microarchitectures, this pipeline delivers sustained extraction throughput exceeding 30 kilobytes per second with a bit error rate below 0.12%.

Enterprise Linux Kernel Mitigations & Performance Regression Benchmarks

Mitigating Inception required extensive collaboration between AMD and upstream Linux kernel maintainers. Because Inception circumvents traditional eIBRS (which was designed assuming return predictions strictly adhered to call boundaries), AMD issued microcode patches alongside kernel software fences:

• Microcode Patch (Zen 4 Family 19h Model 61h+): Forces an automatic branch predictor serialization fence during privilege level transitions, preventing transient branch entries from cross-pollinating across CPL3 (User) to CPL0 (Kernel) rings.
• Safe RET Trampolines (Software Fallback): In legacy environments where microcode updates cannot be applied, the compiler inserts a return trampoline that overwrites the top-of-stack entry with a known benign stub, neutralizing poisoned RAS entries before architectural return execution.
• Performance Regressions: In high-frequency system-call workloads (such as Redis in-memory key-value caching, PostgreSQL transaction processing, and context-switch heavy virtualization), the microcode fence imposes a measurable performance overhead ranging from 4.2% to 12.8% on raw I/O throughput. However, compute-bound matrix operations and machine learning inference pipelines remain essentially unaffected (< 0.4% impact).

6. Institutional FAQ: AMD Inception Exploit Q&A