I NCEPTION: Exposing New Attack Surfaces with Training in Transient ExecutionDaniël Trujillo †ETH Zurich

Johannes Wikner †ETH Zurich

Kaveh Razavi
ETH Zurich† Equal contribution first authors

Abstract
To protect against transient control-flow hijacks, software relies on a secure state of microarchitectural buffers that are
involved in branching decisions. To achieve this secure state,
hardware and software mitigations restrict or sanitize thesemicroarchitectural buffers when switching the security context, e.g., when a user process enters the kernel. Unfortunately,
we show that these mitigations do not prevent an attacker frommanipulating the state of these microarchitectural buffers inmany cases of interest. In particular, we present Training inTransient Execution (TTE), a new class of transient execution
attacks that enables an attacker to train a target microarchitectural buffer after switching to the victim context. To show
the impact of TTE, we build an end-to-end exploit called
I NCEPTION that creates an infinite transient loop in hardware
to train the return stack buffer with an attacker-controlled
target in all existing AMD Zen microarchitectures. I NCEP TION leaks arbitrary kernel memory at a rate of 39 bytes/s on
AMD Zen 4 despite all mitigations against transient controlflow hijacks, including the recent Automatic IBRS.

1Introduction

Transient execution attacks let attackers execute codein the victim’s context to leak sensitive information [9, 30, 33, 36, 48, 49]. To hijack the transient control
flow, attackers need to manipulate microarchitectural buffers
involved in making branching decisions. A common approachis restricting or sanitizing these microarchitectural buffers
when switching security contexts [6, 12, 14, 15, 40]. In thispaper, we show that current approaches are insufficientagainst an attacker that uses privileged software and hardware
as confused deputies to train microarchitectural branchpredictors with transiently executed instructions.
Hijacking transient execution and mitigations. To hijack
the transient control flow of privileged software, like thekernel, attackers manipulate microarchitectural branch prediction buffers, such as the Return Stack Buffer (RSB) [33]or the Branch Target Buffer (BTB) [49]. Consequently, toprotect privileged software, mitigations sanitize or restrict
these when switching to higher privilege mode. The RSB
may be sanitized by means of stuffing [15, 33], preventing
return instructions of other execution contexts to be hijacked
by poisoned RSB entries. A combination of retpoline [47]and jmp2ret [6] mitigations transform all indirect branches
and returns into a single return instruction, whose prediction
is sanitized on kernel entry for certain AMD CPUs. Modern
microarchitectures support hardware-level features, such as
Automatic and Enhanced IBRS [12, 40], that restrict usageof potentially-malicious branch predictions, providing a more
efficient mitigation against transient control-flow hijacks.
Training in Transient Execution. Restriction and sanitization of branch predictors assume that an attacker is unable tomanipulate these predictors after entering the victim context,
such as the kernel. This is unfortunately not true. We present a
new class of transient execution attacks that do their Training
in Transient Execution (TTE). TTE expands the attack
surface of transient control-flow hijacks by using the kernel
and in some instances even the CPU as confused deputies for
manipulating the BTB and RSB. Our evaluation of the TTE
variants shows new capabilities in different scenarios: TTE of
the BTB (TTE BTB ) trains the BTB in transient execution witha target that is later consumed by a branch to trigger attackercontrolled transient execution. Likewise, by executing a call
instruction in transient execution, TTE of the RSB (TTE RSB )trains the RSB with a target that is subsequently consumed
by a return instruction. While TTE BTB and TTE RSB can use
the kernel as a confused deputy to poison microarchitectural
buffers after kernel entry, they require specific gadgets that are
not necessarily trivial to find. Is it possible to lift this requirement by turning the CPU into a confused deputy instead?
I NCEPTION. Recent work shows that P HANTOM J MPS enabletransient control-flow hijacking from an arbitrary instruction
on AMD Zen 1(+) and Zen 2 [50], as well as the more
recent AMD Zen 3 and Zen 4 [51]. If P HANTOM J MPS allow
manipulation of the branch predictor in their short transientwindow, synergies between P HANTOM and TTE would
allow for new variants of TTE. Our investigation showsthat TTE RSB is possible inside a P HANTOM J MP, even in theabsence of a call, using a new primitive which we refer to as
P HANTOM C ALLS. By triggering this P HANTOM C ALL inside
the transient window of a P HANTOM J MP, an attacker canpush an arbitrary return address to the RSB by injecting a callprediction for an arbitrary instruction. In essence, the CPUtrains the RSB autonomously with a non-existent control
flow. P HANTOM C ALLS manipulate the RSB regardlessof execution of the target, bypassing AMD’s hardware
mitigations such as Zen 2’s chicken bit and the brand-new
Automatic IBRS feature for Zen 4.
Poisoning a single RSB entry alone, however, complicates exploitation. Therefore, our proof-of-concept exploit
I NCEPTION creates an infinite loop in transient execution
using a recursive P HANTOM C ALL, poisoning multiple RSB
entries. Subsequent return instructions provide I NCEPTION
with a long-lasting transient execution window from anattacker-provided code location. On Zen 1(+) and Zen 2, thisreturn instruction is in fact the one sanitized on kernel entry
with jmp2ret, now again under transient control of the attacker
due to TTE. Our analysis of possible mitigations suggeststhat a full flush of the branch predictor is necessary to mitigate
I NCEPTION. Unfortunately, our analysis shows that Zen 3 andZen 4 do not provide hardware support for a full flush of the
branch predictor, requiring mitigations at the microcode level.
Contributions. Our contributions are as follows:• Introducing the new TTE class and an evaluation of its
variants on Intel and AMD microarchitectures.
• Discovering P HANTOM C ALL, allowing manipulationof the RSB despite recent hardware mitigations on all
existing AMD Zen microarchitectures.
• Constructing I NCEPTION by creating nested P HANTOM C ALLs to pollute the RSB recursively. I NCEPTION leaks/etc/shadow on fully patched AMD Zen 4 systems in
40 minutes, in 6 out of 10 trials.
• Evaluation of the ibpb mitigation against I NCEPTION
on Zen 1(+) and Zen 2. This mitigation introduces
between 93.1% and 239.2% overhead on Zen 1(+) andZen 2, depending on the specific microarchitecture. Our
analysis shows that ibpb is not a sufficient mitigation
against I NCEPTION on Zen 3 and Zen 4.
Responsible disclosure. We communicated with Intel andAMD in February 2023. I NCEPTION was under embargo until
August 8, 2023 to provide adequate time for development
and testing of new mitigations that require microcode
patching. I NCEPTION is tracked under CVE-2023-20569.
Further information about I NCEPTION can be found at:https://comsec.ethz.ch/inception.

2

BackgroundWe discuss the necessary background concepts for thispaper including speculative execution, branch prediction,
control-flow hijacks and their mitigation.

2.1

Speculative execution

To prevent under-utilization of execution units due to pipeline
stalls, a continual stream of instructions must be provided by
the CPU frontend. Slow operations, such as memory requests,
that dictate the control flow of a program, are examples
of such stalls. Speculative execution is a key technique foravoiding stalls by predicting the control flow of the program.
A control-flow edge, or branch, needs a predicted branchtarget before its potential dependencies (e.g., memory loads)
have been resolved. Branches are either conditional or unconditional, and direct or indirect. All types of branches needpredictions to avoid stalls. In particular, unconditional indirect(e.g., jmp [reg]) and conditional direct (e.g., cmp [reg], 0; je L)
branches that depend on slow memory operations greatly benefit from early predictions. Conditional branches can be predicted in two directions: taken or non-taken (i.e., fall through).
Direction prediction may be rule-based (i.e., static). For
example, a conditional backward branch is likely a loop, thus
likely taken, whereas a conditional forward branch is likely
from an error check, thus likely non-taken (i.e., fall through).
Programs are typically run in predictable patterns, so thatover time, branch predictors that remember previous branchresolutions can predict current branches with barely any error.

2.2

Modern branch prediction

The branch prediction unit serves predictions for all typesof branches. It predicts the direction of conditional branches,
the target of conditional and unconditional direct branches,
indirect branches, and returns.
A Branch Target Buffer (BTB) stores branch targets
associated with different branches. The indexing and structureof BTB entries varies across CPUs. Their purpose however
is to provide a branch target given the current instruction
pointer and branch history. Both direct and indirect branchtargets are provided by the BTB. Conditional direct branches
are moreover associated with a Pattern History Table (PHT)
that is indexed by the n last branch directions [54]. Modern
CPUs are known to use other prediction structures than PHT,
such as TAGE [43,45]. Return target predictions are managed
by the Return Address Predictor or Return Address Stack(AMD terminology) or Return Stack Buffer (RSB) (Intelterminology). We refer to this buffer as the RSB throughout
the paper. The RSB tracks return targets alongside thearchitectural program stack to provide faster return target
predictions without needing to wait for memory-dependent
return targets on the program stack. Although RSBs oftenbehave like circular stacks [36], modern processors diverge
from such semantics, for example by being able to detect andrecover from incorrectly pushed and popped entries [4].
For an accurate prediction, the history of previous
branches is sometimes taken into account. This is particularly
important for indirect branches and conditional branches,
where the target may change during program execution. On
Intel CPUs, branch history is stored in a global per-thread
Branch History Buffer (BHB) as a footprint of the source andtarget of the n previously taken branches [9, 30].
Branch predictors receive feedback throughout program
execution. However, it is unclear at which stage in theprocessor pipeline feedback is provided. Can branchpredictors receive branch resolution feedback from branches
that have not advanced through all pipeline stages?

2.3

Speculative control-flow hijacks

Spectre attacks abuse the above-mentioned buffers totrigger controlled mispredictions, resulting in speculative
control-flow hijacks. Spectre-PHT [30] forces the directionof a conditional branch to be mispredicted, Spectre-BTB [30]forces a poisoned BTB entry to be served for an indirect
branch, and Spectre-RSB [33, 36] forces a mismatch between
the return target on the program stack and RSB. While
software and hardware defenses exist to mitigate these,researchers continue to find mitigation flaws that re-enable
these attacks [9, 37, 48, 49].
Recent work on AMD CPUs shows that branch target prediction occurs at an early stage in the pipeline, before instructions are decoded [50]. This means that the type of branch(if any) is also subject to prediction, which introduces P HAN TOM speculation [51], also known as Branch Type Confusion(BTC) [6]. As such, the prediction of branch type must also be
tracked in a data structure, which is assumed to be the BTB.

2.4 Mitigating speculative control-flow hijacks
Spectre-BTB can be mitigated using retpolines [47] or
IBRS [12, 40]. Retpolines replace indirect branches withreturns, forcing the RSB to be used instead of the BTB for
predictions. IBRS is a hardware mitigation that prevents
branch targets entries learned in a lower privilege mode(e.g., user mode) to be used in a higher one (e.g., kernelmode). Enhanced IBRS (eIBRS) [12] and Automatic
IBRS (AutoIBRS) [40], deployed in newer Intel and AMD
processors respectively, are more efficient by not requiring
MSR writes on privilege transitions.
Spectre-RSB is mitigated through RSB stuffing. By fillingup the RSB with harmless return targets when switchingexecution context, the return predictions of the victim context
can not be influenced by an attacker. Return target prediction
can also be forced into BTB prediction by underflowing the
RSB [49]. RSB stuffing can be used in combination withcall-depth tracking to prevent this on Intel CPUs [56]. Modern
Intel CPUs instead support Restricted RSB Alternative toprevent harmful speculation on RSB underflows [25].
Because return instructions can be confused with indirect
branches and hence be served BTB predictions on AMD
systems vulnerable to P HANTOM speculation, retpolines are
insufficient. jmp2ret mitigates P HANTOM speculation on
returns by replacing all returns (including those inside retpolines) with direct branches to a single, protected return. On
privilege transitions, this return is sanitized (i.e., untrained)
in the BTB by confusing it with a non-branch instruction [6].
P HANTOM speculation also occurs on non-branch instructions, known as P HANTOM J MPS [50]. To mitigate this issue,
AMD revealed an undocumented MSR register bit, known
as the Spectral Chicken (Linux terminology [57]) or SuppressBPOnNonBr (AMD terminology). When set, branchprediction is limited to control-flow edges.

2.5

Discussion

The mitigations discussed above can be categorized as either
restricting or sanitizing predictions. Restricting predictions
either prevent use of certain predictions (AutoIBRS, andeIBRS) or of an entire predictor (retpolines). Sanitizing
predictions, such as jmp2ret and RSB stuffing, sanitize
predictions before execution of vulnerable branches. The
main assumption behind both categories, is that predictions
must have been poisoned by the attacker before transitioning
to the victim context (e.g., the higher privileged kernel). The
question is whether this assumption is necessarily true, orif branch predictions can be poisoned after switching to thehigher privilege through a confused deputy?

3

Threat Model

We consider a typical scenario where an unprivileged attacker
process aims to leak sensitive information from the kernel.
We assume the kernel to be free of software vulnerabilities,
and running on a processor that supports speculative andout-of-order execution. Specifically, in this work we target theLinux kernel running on x86-64 Intel and AMD processors.
We also assume the default configuration of all existing mitigations against transient execution attacks. These mitigations
include retpoline [3, 13], call-depth tracking [56], jmp2ret
and SuppressBPOnNonBr [6], user pointer sanitization [1],KPTI [23], and disabling of unprivileged eBPF [38]. For
our TTE primitives, we consider CPUs from both Intel andAMD, but our end-to-end exploit requires the processor to beaffected by P HANTOM speculation (AMD Zen 1 (+), Zen 2,
Zen 3 or Zen 4 [51]). For Zen 4, we additionally consider
Automatic IBRS, supported in Linux 6.3 and later [40].

4

Overview

void TTE_pht_btb (state_t *a, void (*b)()) {if (*a) { /* mispredict as true */b(); /* inject disclosure gadget referenced by b */
}
}

1
2

To prevent transient execution attacks, mitigations restrict
or sanitize branch predictors between privilege levels. Despite these mitigations, an attacker can still trigger (limited)transient execution windows under which potentially invalid
control-flow transfers may be observed by the processor.
While these limited windows do not immediately lead to information disclosure, they may be used to perform TTE. The firstchallenge that we try to address in this paper is to understandthe conditions under which TTE is successful on either the
BTB or RSB and the requirements that it puts on the attacker.

3
4
5

Listing 1: A code snippet vulnerable to TTE PHT- BTB
code in transient execution using recursive P HANTOM C ALLS,
poisoning many RSB entries as a result. This mechanism
enables I NCEPTION to hijack return instructions. There are anumber of additional practical challenges, such as bypassing
KASLR and finding disclosure gadgets, that we also discussin Section 7.

Challenge (C1). Understanding the necessary conditions
for TTE and its requirements for an attack.

5
Section 5 addresses this challenge by reverse engineering
the conditions under which the BTB and RSB can be trainedin transient execution. In Section 5, we focus on TTE variants
that are relevant for our end-to-end attack, and we leave amore thorough analysis of other TTE variants to Section 8.
Our analysis shows that TTE expands the attack surface oftransient execution, but the necessary gadget are sometimes
difficult to find [26, 49]. Instead of using a kernel gadget as
our confused deputy, we use the CPU to perform TTE with
P HANTOM speculation. According to AMD however, theSuppressBPOnNonBr bit (on-by-default in Linux) prevents
P HANTOM speculation arising from non-branch instructions(i.e., P HANTOM J MPS) on Zen 2. Furthermore, P HANTOM
speculation does not trigger transient execution on Zen 3 andZen 4 [51]. This leads us to our second challenge:
Challenge (C2). Understanding the impact of P HANTOM
speculation on TTE, considering its mitigations and its
limited effect on newer microarchitectures.
Section 6 introduces a new P HANTOM speculation
primitive that we refer to as P HANTOM C ALL. P HANTOM C ALL enables training of the RSB in transient execution(TTE RSB ) using non-branch instructions, without requiring
any execution. Because of this, P HANTOM C ALL is effective
on Zen 3 and Zen 4 as well, and neither SuppressBPOnNonBR
nor Automatic IBRS prevents P HANTOM C ALLS.
While this primitive enables us to poison one RSB entry
in the kernel context, practical exploitation is difficult due tothe undocumented RSB recovery mechanisms. This provides
us with the last challenge:
Challenge (C3). Practical exploitation with P HANTOM C ALL.
Section 7 describes I NCEPTION, our end-to-end exploit
using TTE RSB , and P HANTOM C ALL. I NCEPTION creates
an infinite hardware loop without the corresponding software

Training in Transient Execution

The common setup of a transient execution attack is a
speculation gadget that is trained to transiently execute anincorrect control flow where memory can be leaked througha disclosure gadget. A common disclosure gadget loads asecret from an attacker-controlled address, which is thenencoded in a subsequent dependent memory access thatleaves a trace in the cache, observable via a cache attack
such as Flush+Reload [53] or Prime+Probe [39]. TTE has
two interesting properties: (i) the injected branch target only
ever executes transiently, meaning it can contain, beyond a
disclosure gadget, arbitrary or invalid instructions, and (ii)the attacker can escalate a limited speculation primitive undercertain conditions.
We experiment with various transient execution windows
to see whether they can manipulate the BTB or RSB. We consider four methods to trigger a transient execution path where
the BTB or RSB may be trained: (1) through conditional
branches, (2) indirect branches, (3) returns, or (4) throughOut-of-Order (OoO) execution, which causes a transient
execution path, for example after a faulting instruction. We
note that other methods are possible, for example transient
windows caused by store-to-load forwarding [28] and speculative store bypass [24], which we leave for future work. We
use TTE A - B to refer to using a transient execution triggeredby method A to train the microarchitectural buffer B. In thissection, we discuss the general method to accomplish TTE
and leave the details of the individual variants to Section 8.

5.1

BTB training in transient execution

Listing 1 demonstrates an example of a code snippet,
potentially exploitable with TTE BTB . If the condition of the
branch on line 2 holds, an indirect branch to b is executed,
which trains the BTB. If the attacker can skew the directionof this conditional branch so that b() is executed transiently(TTE PHT- BTB ), we hypothesize that the BTB is also trainedwith the attacker-controlled value b as branch target.

1
2
3
4
5
6
7

void TTE_pht_rsb (state_t *a) {if (*a) {/* mispredict as true */f();/* push return target to RSB */DISCLOSURE_GADGET; /* top of RSB will point here */}return; /* predict DISCLOSURE_GADGET as target */}A: jmp [r1]Architectural path

B: jmp [r2]Transient path

r1=&B
r2=&C

T1
A

Listing 2: A code snippet vulnerable to TTE PHT- RSB
To turn TTE of the BTB into arbitrary transient code
execution, two conditions must be fulfilled: (i) we can skew
the conditional branch direction, and (ii) we control b to
inject an arbitrary branch target. To furthermore leak memory,an attacker needs additional control over at least a memory
pointer to some secret of interest. Leveraging TTE with thisexample, the attacker gains an extra primitive: they can train
the indirect branch using transient execution in a preparatory
step. Afterwards, they can run the victim again and provide
an arbitrary value in b while still reaching the previously
injected branch target.
However, indirect branches are commonly replaced by
retpolines on many microarchitectures, since they are known
to be vulnerable to Spectre-BTB. Additionally, meeting
condition (ii) means the attacker already has arbitrarytransient code execution but uses it for training instead ofleaking data. More complex scenarios exist than the toy
example in Listing 1, for example caused by speculative
type confusion [29]. Regardless, TTE BTB exposes new
possibilities for the attacker, and we discuss its variants in
Section 8. Next, we discuss TTE for the RSB, that loosens
requirements from the viewpoint of an attacker.

5.2

RSB training in transient execution

Listing 2 demonstrates a piece of code that may update the
RSB in with a transiently executed call instruction triggeredby a mispredicted conditional branch (TTE PHT- RSB ). This
piece of code yields some interesting results: the transiently
executed call updates the RSB only on all AMD microarchitectures, although unreliably. To investigate further, weconstruct a more thorough experiment using TTE BTB - RSB .
Experiment setup. Figure 1 illustrates how we verify RSB
training through a mispredicted indirect branch with a training
procedure (T1 ) and a training in transient execution procedure(TTE). The goal of the experiment is to determine whether
a call instruction executed in transient execution manipulates
the state of the RSB. Green nodes (Di , 0 ≤ i < x) are disclosure gadgets that we try to inject into the RSB by transiently
executing call sites Ei , 0 ≤ i ≤ x (yellow nodes) that immediately precede the disclosure gadgets. For each Di , a different
memory load inside a reload buffer is used to indicate which
Di transiently executed. Ei calls the next call site Ei+1 , insequence, such that Di becomes the return target of Ei+1 , until
reaching Ex . Gray nodes Ex and C, are barrier gadgets to stop

B

E0

E1

D0

D1

...

Initial
state

TTE

r1=&C
r2=&E0 Initial
state

C

A

B

Ex

E0

E1

D0

D1

C

...

Ex

Figure 1: Injecting RSB entries in the transient execution windowof an indirect branch (TTE BTB - RSB ). In T1 , A is trained to execute
B. Next, in TTE, A transiently executes B, which in turn executes aseries of call gadgets Ei , each followed by a disclosure gadget Di .
1
2
3
4
5
6
7
8

id = 0.rept Ncall 1f
load (RB + id*4096), %rdi
1: lfence
pop %r8
id = id + 1.endr

Listing 3: Pseudo-assembly priming the RSB with N different returntargets before the TTE RSB experiment. Execution is measured witha cache side-channel. N is the RSB capacity.
1
2
3
4
5

.rept N
push 1f
ret
1:
.endr

Listing 4: Inferring the RSB state by issuing N returns.
speculation using a memory barrier instruction (e.g., mfence).
We run our experiment for 0 ≤ x ≤ 50 to be able to compare
the results of executing different numbers of transient calls.
To recover from call instructions which are executed transiently, return target predictors implement mechanisms that
restore the RSB to a consistent state [4]. This means that RSB
entries manipulated in transient execution may become invalid and unusable as a consequence. The Di gadgets are thus
only observable for transiently pushed entries that were notinvalidated. To also observe invalidated entries, we establish aknown state of the RSB by priming it fully using N calls preceding N additional disclosure gadgets, as shown in Listing 3,
where N is the size of the target RSB (e.g. 31 on Zen 1, Zen +and Zen 2). We flush the x + N reload buffer (RB) entries
from the cache hierarchy before running the experiment.
We first execute T1 , which trains the BTB to transiently
execute B in the TTE step. Next, we prime the RSB according
to Listing 3. We then execute TTE, which triggers a seriesof calls to Ei , potentially manipulating the RSB. After
performing the experiment, we examine the RSB state. To dothis, we execute N returns, as shown in Listing 4. If the RSB
was not manipulated by TTE, we expect to have transiently

2
1
0
7
6
5
4
3
RSB

2
1
8
7
6
5
4
3
RSB

2
1
8
7
6
5
4
3
RSB

2
1
8
7
6
5
4
3
RSB

1

2

3

4

Figure 2: An implementation of a circular RSB with a committed
top-of-the-stack pointer (shown in blue) and a speculative counterpart(shown in red). RSB entry numbers indicate their insertion order(0 first, 8 last). Entries depicted in red were inserted transiently. 1
shows RSB state before transient execution. 2 pushes an entry
to the RSB transiently. In 3 , the transient window is over and thespeculative pointer is restored. 4 shows the RSB state after 7 returns.

executed the primed return sites in Listing 3. If an RSB entry
was manipulated but invalidated, we expect it to no longer
be used. If an RSB entry was manipulated but not invalidated,
we expect to observe a memory access triggered by Di .
Results. The results show that manipulating the RSB
with TTE BTB-RSB is feasible on all considered AMD
microarchitectures, but not on Intel microarchitectures(Table 1 in Section 8 includes all our TTE results). This is inline with the Software Optimization Guide, which states thattransient pushes and pops to the RSB may occur [4, 5]. We
observe that transiently executed calls evict the oldest entries,
at the bottom of the RSB. That means that, in the case of asingle transiently executed call, the last return will not use
its corresponding primed RSB entry. Likewise, executing two
transient calls evicts two entries at the bottom of the RSB,
causing the last two returns executed to their corresponding
RSB entries. RSB manipulation of the bottom entries could
be explained by having two RSB pointers for a circular buffer:a committed one and a speculative one, as shown in Figure 2.
Upon misprediction, the speculative pointer restores to thecommitted one, which effectively puts transiently injected
entries at the bottom of the buffer.
However, the returns associated with the corrupted entries
do not consume the injected Di targets, nor the previously
primed entries. Instead, RSB entries untouched by thetransiently executed calls are recycled. For example, instep 4 of Figure 2, entry 1 may be predicted instead of
the overwritten entry 8. This suggests that AMD’s return
predictors implement recovery mechanisms for handlingtransiently pushed entries. We find that we can bypass
these mechanisms by executing multiple calls in a transient
window. For example, on Zen 1(+) and Zen 2, this happens
as soon as we overwrite all 31 RSB entries. We will discuss
this in more detail in Section 7.1.

Observation (O1). We can corrupt return predictions
on AMD microarchitectures with TTE BTB-RSB .
On Intel microarchitectures, we were unable to poison
any RSB entry with TTE. Intel patents describe speculative
RSBs [19, 27], which could result in the behavior we observe.
We will further show in Section 8 that other transient
execution windows have a similar effect on AMD’s RSB.
However, finding exploitable gadgets similar to Listing 2 inthe victim code might be difficult. The question is whether
we can relax this constraint by abusing other properties ofAMD microarchitectures.

6

P HANTOM and TTE

AMD Zen microarchitectures are known to be vulnerable
to P HANTOM speculation, leading to additional potential
variants of TTE. P HANTOM is a class of transient execution
issues arising when the predicted branch type, stored in the
BTB, conflicts with the actual instruction [6,51]. For example,
the BTB may contain a prediction for an indirect jump, while
the actual code location contains a return, resulting in the return being predicted as an indirect branch. P HANTOM can also
occur in absence of any branch, triggering speculation fromnon-branch instructions, referred to as P HANTOM J MPS [50].
Chicken out from P HANTOM J MPS. In response to thediscovery of P HANTOM, AMD revealed an undocumented
configuration of Zen 2 CPUs that can be enabled by setting
MSR bit 0xC00110E3[1], known as SuppressBPOnNonBr.
This is a chicken bit that configures the CPU’s branch target
predictor to suppress predictions for non-branch instructions.
The configuration promises that all speculative execution
on non-branch instruction is prohibited, which reduces theattack surface of P HANTOM to arbitrary branches only. This
mitigation is currently enabled by default on Linux.
P HANTOM on Zen 3 and Zen 4. While AMD originallyclaimed that Zen 3 and Zen 4 are immune to P HANTOM,
later work has shown that these microarchitectures are also
affected by P HANTOM, although only partially [51]. In
particular, transient execution due to a P HANTOM J MP is notpossible on these newer microarchitectures, but the predicted
target is still fetched and decoded.

6.1

Synergies between TTE and P HANTOM

Recalling the hard-to-find gadget in Listing 2, we want toknow whether it can be simplified using P HANTOM. Our firstobservation is that a conditional branch is unnecessary if we
can trigger a call transiently using P HANTOM. Since P HAN TOM on Zen 1(+) and Zen 2 results in transient execution, we
can use any branch to trigger a transient call to manipulate
the RSB. On Zen 1(+), we can even hijack non-branch instructions. Hence, P HANTOM would significantly relax the

BTB
T1

TJ

JMP

T2

TC

CALL

TTE

PJ

PHANTOM
JMP

PC

...

JMP

Pc

JMP

Pc

RSB

CALL ...

PC

-

-

-

-

?

PHANTOM CALL
Arch. path

Spec. path

Figure 3: Experiment setup to test feasibility of executing a
P HANTOM C ALL in a P HANTOM J MP. Green and blue colors indicate
two different BTB mappings.

constraints of the original gadget, since it can be split into two.
The first half of the gadget only needs to contain an arbitrary
instruction that can be poisoned with P HANTOM, followed bya return. The second half, being a call followed by a disclosure
gadget, can be anywhere in the executable address space.
Training the RSB in a P HANTOM window. With P HANTOM,
the architectural branch type solely dictates the length of thetransient execution window [6], giving rise to two cases whichlead to transient execution: a short transient window, concerning architectural direct branches or non-branch instructions,and a long transient window, concerning architectural indirect
branches and returns. We are mostly interested in the cases
yielding a short transient window, since they can be triggeredon arbitrary branches on both Zen 1(+) and Zen 2.
We design an experiment to determine the feasibility ofmanipulating the RSB within a P HANTOM-induced transient
window. For this, we execute an indirect branch to triggera P HANTOM J MP at the victim instruction using out-of-place
training. We set the target of the indirect branch to an addressthat contains a call instruction. To determine whether theP HANTOM J MP interacts with the RSB, we prime the RSB
as as shown in Listing 3 and 4.
Results. Our results show that we can manipulate the RSB
within a P HANTOM-induced window on both Zen 1(+) andZen 2. On Zen 1(+) the P HANTOM J MP to the call can betriggered even on non-branch instructions, which is expected,
since mitigations against this are only available on Zen 2.
Observation (O2). We can manipulate the RSB using
P HANTOM speculation on Zen 1(+) and Zen 2.
However, P HANTOM speculation on non-branch instructions is prevented with the SuppressBPOnNonBr mitigation
on Zen 2. Likewise, on Zen 3 and Zen 4, P HANTOM speculation does not allow transient execution. Section 6.2 discusses
how we bypass SuppressBPOnNonBr on Zen 2 with a newprimitive we refer to as P HANTOM C ALL, and Section 6.3
discusses how minor adaptations to P HANTOM C ALL makes
it effective on Zen 3 and Zen 4 as well, despite AutoIBRS.

6.2 Bypassing SuppressBPOnNonBr with
P HANTOM C ALL
We hypothesize that TTE of the RSB using P HANTOM works
because of a call prediction on the P HANTOM J MP target, andnot because of the call instruction itself. We design an experiment to test our hypothesis, as shown in Figure 3, with thestate of the BTB and RSB shown after each step. In training
step T1 , we first execute a branch from training branch source
TJ to P HANTOM C ALL source PC . This creates a BTB entry
for a branch, with its target set to PC , which only contains
NOPs. In training step T2 , we execute a 3-byte wide call
instruction at call source TC , inserting a BTB entry for a call(target not relevant). TC and PC map to the same BTB entry.
After performing steps T1 and T2 , we fully prime the RSB
with distinct return sites, each issuing an identifiable memory
access, as shown in Listing 3. In step TTE, we execute the
NOP instructions at P HANTOM J MP source PJ , which collides
with the BTB entry of TJ . Thanks to step T1 , we expect PC
as the predicted target of PJ . Thanks to step T2 , because
there exists a call-prediction for PC , we expect the CPU totransiently push a return target (PC +3) onto the RSB. Lastly,
we flush our reload buffer and execute return instructions
according to Listing 4. We reload our memory pointers todetermine which of the RSB entries are invalid or still intact.
The results confirm our hypothesis: the last return does
not transiently execute the primed return site, meaning wehave overwritten an RSB entry using a P HANTOM C ALL
inside a P HANTOM J MP-induced speculation window (i.e.,
nested P HANTOM speculation). If there exists a call-target
prediction at our P HANTOM J MP target, we presume theCPU does not need to decode before pushing its predicted
return target to the RSB. We therefore conclude that thecall prediction alone prematurely pushes to the RSB, before
instructions are decoded. Supporting this conclusion, we findthat the P HANTOM J MP to the P HANTOM C ALL manipulates
the RSB even when both branches are injected on non-branch
instructions, despite the Zen 2 SuppressBPOnNonBr mitigation. Given this, we hypothesize that SuppressBPOnNonBr,
while suppressing transient execution of P HANTOM J MP
targets, does not suppress BTB consultation, allowing RSB
manipulation without execution.
We refer to this new primitive as P HANTOM C ALL,
allowing us to manipulate the RSB from any instruction,
without any architectural call instruction on the transient path.
Observation (O3). We can corrupt an RSB entry
using a P HANTOM C ALL on Zen 1(+) and Zen 2
microarchitectures, bypassing SuppressBPOnNonBr.

6.3

P HANTOM C ALL on Zen 3 and Zen 4

Given that our results show that we can perform TTE RSB
without any transient execution using a P HANTOM C ALL,

CL:

...

...

A

A+1

PhantomJMP

BTB

...

call

B

B+1

Figure 4: Triggering TTE RSB inside a P HANTOM speculation
window on Zen 3/4. The colored boxes identify different cache lines.
Architectural and transient branches are indicated by solid black anddashed red arrows, respectively.

T1

TJ

JMP

T2

TC

CALL

TTE

PJ

PHANTOM
JMP

PC

PC

PC

PHANTOM CALL
Arch. path

we investigate whether we can use this primitive on Zen 3
and Zen 4 as well. After additional reverse engineering, wefind that TTE RSB using P HANTOM on Zen 3 and Zen 4 iseffective, but only under certain circumstances. In particular,
TTE RSB using P HANTOM requires both the P HANTOM J MP
and the P HANTOM C ALL to be at specific memory addresses
relative to those used for BTB consultation.
To successfully trigger the call in a P HANTOM J MP target,
we consider four different cache lines as shown in Figure 4.
We inject the P HANTOM J MP on a cache line A+1, which
linearly follows the cache line of a preceding branch target.
Similarly, we place the P HANTOM C ALL on a cache line B+1,
which is the cache line following that of the P HANTOM J MP
target. We hypothesize that this is necessary to delay the
decoder. The time it takes for the frontend to fetch the next
cache line and feed it to the decoder may introduce enoughdelay to allow manipulation of the RSB before the decoder
can detect that predictions are incorrect.
We find that AutoIBRS does not prevent RSB manipulation
due to a P HANTOM C ALL inserted in a lower privilege level.
This is in line with our observations on Zen 2, where
we bypassed the SuppressBPOnNonBr mitigation with
P HANTOM C ALL. We thus hypothesize that AutoIBRS only
prevents transient execution at the target of a P HANTOM J MP,
and not consultation and manipulation of the BTB and
RSB respectively. We can also deduce this from statements
previously released by AMD [6], which mention that IBRS
is effective for branches decoded as indirect, indicating the
restriction is enforced after instructions have been decoded.
Observation (O4). P HANTOM C ALL works on Zen 3 andZen 4 as well under certain circumstances, bypassing
AutoIBRS.
P HANTOM C ALLS significantly simplify the requirements
for exploitation with TTE RSB . We can insert the address ofan arbitrary disclosure gadget into the RSB by injecting a
P HANTOM C ALL right before it. Furthermore, by performing
this P HANTOM C ALL inside a P HANTOM J MP, we can trigger
this from anywhere. We leverage these capabilities in our
end-to-end exploit, I NCEPTION, which we discuss next.

7

I NCEPTION

To turn P HANTOM C ALL into an end-to-end exploit, we need
to overcome two challenges. First, to bypass mechanisms that

JMP

Pc

JMP

Pc

CALL

Pc

-

-

CALL

Pc

RSB

?
?
?

Spec. path

Figure 5: The experiment setup to test the number of entries we canpollute with a recursive P HANTOM C ALL in a P HANTOM J MP. Greenand blue colors indicate two different BTB mappings.

restore the RSB, we need to overwrite multiple RSB entries,
as pointed out in Section 5.2. We thus need to construct a
chain of P HANTOM C ALLS, where the last P HANTOM C ALL
has to precede a disclosure gadget. In particular, on Zen 1(+)
and Zen 2 we need to overwrite all 31 RSB entries to bypass
the recovery mechanism. Second, the short transient execution
window, caused by a P HANTOM J MP, needs to somehow fit the
chain of P HANTOM C ALLS to overwrite all these RSB entries.
Addressing this challenge requires new insights that we
discuss in Section 7.1 and Section 7.2. We then proceed to thedesign of our end-to-end exploit I NCEPTION in Section 7.3
through Section 7.7. Lastly, we evaluate I NCEPTION on Zen 2
and Zen 4 in Section 7.8 and Section 7.9, respectively.

7.1

Recursive P HANTOM C ALL

To turn P HANTOM C ALLS into a practical exploit, we needa large number of P HANTOM C ALLS in a single transient
window. We therefore construct a chain of P HANTOM C ALLS
to determine how many we can execute using a single
P HANTOM J MP. We realize that we can establish a single
P HANTOM C ALL that branches into itself, i.e. a recursive loopof P HANTOM C ALLS. By avoiding changing the (transient)
instruction pointer, we assume that the CPU can manipulate
the most RSB entries in a single transient window.
Repeating the experiment described in Section 6.2, wemonitor the number of RSB entries that get corrupted bya recursive P HANTOM C ALL. However, this time, the callat TC branches into PC , at which the P HANTOM C ALL willbe triggered, thus establishing a recursive prediction. An
overview of the experiment is shown in Figure 5. Since PC
executes after TC in T2 , and PC and TC map to the same BTB
entry, executing PC should invalidate the prediction from TC
to PC . To avoid this, we make sure that the indirect call in stepT2 page faults, by temporarily unmapping PC . Regardlessof the page fault, we expect the BTB to be primed with aprediction, as shown in previous work [49]. Interestingly,
unmapping is unnecessary on Zen 1(+) and Zen 2. We believethat this could be due to a race condition that happens to bein our favor. The prediction associated with TC may not haveBTB

RSB entry
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

VICTIM

ATTACKER

Zen 1
Zen 1 (2T)Zen 1+
Zen 1+ (2T)Zen 2
Zen 2 (2T)
Zen 3
Zen 4

Figure 6: Entries affected by the recursive P HANTOM C ALL. Yellow
shows invalidated entries that remain unconsumed, while red indicatespoisoned entries consumed for prediction, enabling arbitrary transientcode execution. The size of the RSB is 31 on Zen 1(+) and Zen 2 (or15 in 2T mode), while it contains 32 entries on Zen 3 and Zen 4.

JMP

Pc

JMP

Pc

CALL

Pc

-

-

T1

TJ

JMP

PC

T2

TC

CALL

PC

TTE

PJ

PHANTOM PCJMPCALL Pc
PHANTOM CALL

S

VR

Arch. path

G
G
G

G

RETURNSpec. path

RSB

Page fault

Figure 7: I NCEPTION visualized. The BTB and RSB state is shown
updated the BTB when we are executing PC .
Results. Figure 6 shows that we can corrupt a large number
of RSB entries using our recursive P HANTOM C ALL in a
P HANTOM J MP on all Zen microarchitectures. An interestingobservation we make is that the P HANTOM C ALL at PC is
not invalidated after the TTE step for most of the iterations,unlike the prediction for the P HANTOM J MP. This is beneficial
for our attack, since it allows us to trigger the recursive
P HANTOM C ALL multiple times after priming the BTB.
As discussed in Section 5.2, corrupted entries are not always used for return prediction, due to the RSB recovery
mechanisms. On Zen 3 and Zen 4 however, we find that our recursive P HANTOM C ALL overwrites enough entries to bypass
the recovery mechanisms, as shown in Figure 6. Specifically,on Zen 3 microarchitectures we hijack a single return instruction by first exhausting 17 uncorrupted RSB entries. On Zen 4,
we need to exhaust 8 uncorrupted RSB entries, after which we
control the next 16 return target predictions. We find that the
number of RSB entries polluted heavily relies on the exact location at which we trigger P HANTOM speculation, the state of
the cache, the state of the BTB, and the preceding control flow.
On Zen 1(+) and Zen 2 microarchitectures, however, we
do not overwrite enough RSB entries to bypass the recovery
mechanisms. Our results in Section 5.2 showed that transiently overwriting all 31 RSB entries leads to all corrupted
entries being used for prediction on these microarchitectures.
We therefore expect that overwriting all RSB entries using
a recursive P HANTOM C ALL would allow us to bypass therecovery mechanisms on Zen 1(+) and Zen 2 as well.

7.2

Dual-threaded mode

Rather than trying to achieve 31 transient recursions in thetransient window of a P HANTOM J MP, we consider whether
the capacity of the RSB can be reduced. When two sibling
threads are operating in parallel, Zen 1(+) and Zen 2 cores
switch to dual-threaded mode (2T-mode) [5], reducing the
RSB to only 15 entries per thread, instead of 31. As shownin Figure 6, we can poison 18 entries in nested P HANTOM
speculation on Zen 1(+) and Zen 2, and we thus potentiallyfollowing steps T1 , T2 , and TTE. Green and blue colors indicate twodifferent BTB mappings.

control the entire RSB associated to a sibling thread underdual-threaded mode.
We verify that the RSB capacity decreases from 31 to 15
entries for our thread while executing a workload in parallelfrom the sibling thread. Repeating the experiment shown in
Figure 5 reveals that we can indeed overwrite all 15 RSB entries on Zen 1(+) and Zen 2 microarchitectures. Having overwritten all entries, our transiently injected return target is usedby all following returns, as shown in Figure 6. This means that
we do not rely on deep call stacks on Zen 1(+) and Zen 2: any
return can be hijacked in dual-threaded mode by triggering
the recursive P HANTOM C ALL right before it is executed.

7.3

Exploit design

We are now able to hijack return instructions by injecting arbitrary return targets using our recursive P HANTOM C ALL on all
AMD Zen microarchitectures. Using this, we will construct
our exploit I NCEPTION on Zen 1 (+), 2, and 4. I NCEPTION is
not fully successful on Zen 3, as discussed later this section.
Figure 7 shows a visualization of I NCEPTION together
with the resulting state of the BTB and RSB after eachtraining step. In the first training step T1 , the attacker
executes a training branch at TJ , which collides with the BTB
entry of P HANTOM J MP source PJ . Residing in the kernel
address space, PJ is the address that initiates the recursive
P HANTOM C ALL. The victim return VR is allocated after PJ
in the control flow. The target of the P HANTOM J MP is set to
PC , at which the recursive P HANTOM C ALL will be triggered.
In training step T2 , the attacker executes a training call at
TC that collides with PC in the BTB, which will establish theprediction for the P HANTOM C ALL. The target of this training
call at is set to PC , establishing a recursive P HANTOM C ALL
prediction. Upon execution of PC , the CPU will thus
recursively inject RSB predictions to disclosure gadget G,
whose location immediately follows the P HANTOM C ALL at
PC . As PC resides in kernel space, the training branches TJ
and TC will trigger page faults, which we recover from.

On Zen 3 and 4, we take the cache line placement of
the branches at TJ and TC into account. Concretely, thismeans that the P HANTOM C ALL in PC may be precededby different instructions to ensure that the start of PC andthe P HANTOM C ALL fall in different cache lines. Likewise,
the P HANTOM J MP in PJ may be preceded by different
instructions, depending on the address using which the BTB
is indexed before executing PJ .
After steps T1 and T2 , we invoke the kernel using a systemcall to trigger the TTE step. Whenever we reach PJ , the BTB
provides the prediction to PC , and the speculative instruction
pointer is set to PC . Since there exists a prediction for a callat PC , G is pushed to the RSB. Since the call prediction
is recursive, we will continue the loop of 1) updating the
instruction pointer, 2) consulting the BTB and 3) pushing to
the RSB. This recursion continues until the actual instruction
at the location of the P HANTOM J MP in PJ is eventually
decoded and the CPU corrects the misprediction by resetting
the instruction pointer back to PJ . Finally, in step S the victim
return at VR will take a prediction from the RSB. Since wehave overwritten RSB entries with return target G during
the TTE step, we start executing the disclosure gadget at
G, accomplishing a long speculation window in which we
control the executed instructions.

7.4

Dueling recursive P HANTOM C ALLS

The desired disclosure gadget may not exist in the kernel code,
specially if the hijacked return is in a deep call stack (i.e., onZen 3 and Zen 4). In this case, I NCEPTION can execute two
separate disclosure gadgets within the same transient window,that together perform the desired operation, similar to [55].
I NCEPTION achieves this by introducing two recursive
P HANTOM C ALLS, or dueling recursive P HANTOM C ALLS,
establishing a transient Return-Oriented Programming(ROP) chain. The first recursive P HANTOM C ALL trains the
RSB with the first disclosure gadget, G1 , while the second
recursive P HANTOM C ALL inserts the address of the second
disclosure gadget G2 . As a result, some entries in the RSB
contain the address of G1 , while others contain the addressof G2 . If G1 ends with a return instruction, G2 potentially
executes in the same speculation window. However, for this towork, RSB recovery mechanisms must be bypassed without
overwriting all entries, which is only possible on Zen 3 and 4.
The end goal of dueling recursive P HANTOM C ALLS is tohave some (ideally one) of the newer RSB entries contain theaddress of G1 , and to have the other, older RSB entries containthe address of G2 . Figure 8 shows a possible progression of
the RSB state over time. 1 shows the unmodified RSB, before
the first recursive P HANTOM C ALL. 2 shows the state after
triggering the first recursive P HANTOM C ALL, which precedes
G1 . 3 shows the state after two returns. 4 shows the state
after issuing the second recursive P HANTOM C ALL, which
precedes G2 . Lastly, step 5 shows the RSB state after addi-

G2
G2

G2
G2

G2
G2

RSB

G1
G1
G1
RSB

G1
G1
G1
RSB

G1
G1
G2
RSB

G1
G1
G2
RSB

G1
G1
G2
RSB

1

2

3

4

5

6

Figure 8: Triggering dueling recursive P HANTOM C ALLS tochain two disclosure gadgets G1 and G2 together. The arrow is thecommitted top-of-the-stack pointer.

tionally two returns. The next return will transiently execute
G1 , and until its return target has been resolved, subsequent
returns will keep taking predictions from the RSB, eventually leading to transient execution of G2 . If G1 is idempotent
with respect to the CPU state relied on by G2 (e.g. registeror memory values), G1 can be executed more than once transiently. Otherwise, we target the next return instruction, which
executes G1 once before reaching G2 , as shown in step 6 .

7.5

Victim return instruction

Having designed I NCEPTION, we proceed by searching foran exploitable victim return in the Linux kernel. The firstrequirement is that upon execution of the victim return, we
control the values in two registers or memory locations, V1
and V2 . We use this to leak arbitrary information through thekernel’s physmap area, similarly to previous work [20, 49].
As stated before, we can overwrite all RSB entries on
Zen 1 (+) and 2, and all of them will be used for return target
prediction. On Zen 3 and 4 we can only reach poisoned RSB
entries served for prediction after exhausting a number of
uncorrupted RSB entries. Therefore, on Zen 3 and 4, a second
requirement is to exhaust these returns after the recursive
P HANTOM C ALL, before the victim return.
Previous work built an open-source framework to trace
register contents in the Linux kernel at the time of executing
a return instruction [49]. We use this framework to findvulnerable returns that meet our requirements.

7.6

Derandomizing KASLRAs in previous work [49], we derandomize KASLR in threesteps. In all, we prime the BTB with the P HANTOM J MP and
the recursive P HANTOM C ALL before issuing the system call.
1 Finding the kernel text. We use a disclosure gadget that
dereferences the attacker-controlled pointer in V1 . When executing the system call, this load triggers only if we guess thekernel text location right, which we infer using Prime+Probe.
2 Finding physical address mapping. To find the physicaladdress of our reload buffer, we trigger a transient load ofa physmap offset. We achieve this using a gadget that adds
V1 to the physmap base address and dereferences the result.

1
2
3
4
5

leave
xor
edx,edx
mov
esi,edx
mov
edi,edx
jmp
return_thunk

1
2
3

Listing 5: The location where we trigger P HANTOM speculation in__fdget_pos at kernel code offset 0x41db94 on Zen 1 (+) and 2. It
ends with a direct branch to the return thunk.

2
3
4
5
6
7

2

add
mov

r12,QWORD PTR [physmap]
rax,QWORD PTR [r12]

8
9
10

1
2
3

0x8cfbe640
eax,eax; index BTB upon return from call
0x8cf9040d ; trigger PhantomJMP (next cacheline)

call
test
js
pop
mov
pop
pop
pop
pop
xor

0x8cf1bbf0
eax,eax; index BTB upon return from call
0x8cfbbc83
rbx
eax,r13d
r12
r13
r14
rbp
edx,edx; trigger PhantomJMP (next cacheline); jumps to return (jmp2ret mitigation)
1

1

call
test
jg

movzx eax,BYTE PTR [r14+0x2]
lea
rdx,[r12+rax*2]
movzx r13d,WORD PTR [rdx]

Listing 6: Disclosure gadgets used on Zen 1(+) and Zen 2 for derandomizing KASLR (top, at offset 0xf22a44 of kernel text) andarbitrary information leakage (bottom, at offset 0x70c4a6 of kerneltext).

Using Flush+Reload, we detect when we guess the physicaladdress correctly.
3 Finding physmap. We derandomize physmap using thesame gadget as in 1 . We trigger a transient load of V1 , whichinstead provides the reload buffer physical address added toour physmap base address guess. Using Flush+Reload, we
detect when we guess the physmap address correctly.

Listing 7: The locations where we trigger P HANTOM speculation in ip6_protocol_deliver_rcu (top, at offset 0xd905b9 from thestart of the kernel) and udpv6_queue_rcv_one_skb (bottom, at offset
0xdbbba7 from the start of the kernel text) on Zen 3 (bottom only)
and Zen 4.

KASLR. Lines 1 and 2 are together used for step 2 . Lastly,
Listing 6-bottom presents the disclosure gadget used to leakarbitrary data.

To leak memory, we need to trigger transient executionof a disclosure gadget that performs a secret-dependent
access in our reload buffer. We first prime the BTB with
the P HANTOM J MP and the recursive P HANTOM C ALL. We
trigger execution of a disclosure gadget that dereferences
V1 and uses its result to index into the address in V2 , which
points to the reload buffer. If V1 or V2 are provided bymemory locations, they first need to be loaded from memory
into registers. Using Flush+Reload, we can deduce the secretresiding at address V1 .

Results. We evaluate I NCEPTION on an AMD Zen 2 EPYC
7252 with microcode version 0x8301038 and 64GB of
RAM, running Linux 5.19.0-28-generic with all mitigations
deployed. We run our attack 50 times, each time leaking
4KB of randomized data. We reboot the machine every run
to re-randomize KASLR. Of the 50 runs, we successfully
break KASLR in 48 cases, in a median time of 5.5 seconds.
In those cases, I NCEPTION leaks data at a rate of 126 bytes/s,
with an accuracy of 89.9%.
We furthermore show that I NCEPTION is capable oflocating secrets in the physical memory. Specifically, we
let I NCEPTION search for /etc/shadow to leak the root
password hash. We run I NCEPTION in parallel on all 8
available cores, where each instance starts searching at adifferent physical address. We try to locate /etc/shadow 10
times and reboot the machine after every attempt. Our results
show that we are able to successfully leak the root password
hash in all 10 runs, in a median of 11 minutes and 38 seconds.

7.8

7.9

7.7

Leaking kernel memory

I NCEPTION on Zen 1(+) and Zen 2

Vulnerable return. We find that after issuing the system callreadv(), register R12 will hold the value we pass in RSI (i.e.,
second argument) and register R14 will hold the value wepass in RDX (i.e., third argument) at the moment we executethe return instruction of function __fdget_pos(). Listing 5
shows the last instructions of this function. We trigger theP HANTOM J MP on line 2, poisoning the RSB right before
jumping to the return.
Disclosure gadgets. We could find the desired gadgets withsimple string matching against the assembly code of thekernel text. Listing 6 shows the disclosure gadgets found.
Line 2 of Listing 6-top is used for steps 1 and 3 of breaking

I NCEPTION on Zen 3 and Zen 4

Vulnerable return. We target the sendto() system call,
controlling memory locations using our message buffer,whose address we pass in RSI (i.e. second argument). We
find that upon execution of the return in do_softirq.part.0(),
our message buffer is reachable using the address in RBX.
Likewise, our message buffer is pointed to by the R13 register
upon execution of the return instructions of ip6_local_out()
and ip6_send_skb().
Listing 7-top shows the location where we trigger
the P HANTOM J MPS to our recursive P HANTOM C ALL.
Specifically, we trigger the P HANTOM J MP on the jg
instruction, shown on Line 3. We find that we reliably

1
2
3
4
5
6
7
8

1
2

1
2
3
4
5
6
7
8
9
10

mov
mov
mov
mov
mov
shr
and
mov

rax,QWORD PTR [rbx+0x58]
r13,QWORD PTR [rax+0x8]
rax,QWORD PTR [rbx+0x18]
r12d,DWORD PTR [rax+0x20]
rax,QWORD PTR [rbx+0x30]
r12d,0x8
r12d,0xff00
rsi,QWORD PTR [rax+0x10]

mov
mov

rax,QWORD PTR [rbx+0x48]
rdi,QWORD PTR [rax+0xc0]

movrax,QWORD PTR [rbx+rax*8+0x20] ; Load phys guess addr
movrbx,QWORD PTR [rbp-0x8]
leave
xor
edx,edx
mov
ecx,edx
mov
esi,edx
mov
edi,edxret; return into gadget below

1; Load kernel text

2
3

; Load kernel text + 4096

4
5
6
7

; Load kernel text + 8192

8

; Load physmap guess addr
; Load physmap guess1

mov
rsi,QWORD PTR [rbx+0x48]; Load secret addr
lea
eax,[rdx+0x2]; rdx == 0shl
r14d,clmov
rcx,QWORD PTR [rbx+0x60]; Load reload buffer addr
andedx,DWORD PTR [rbx+0x40]
movzx eax,BYTE PTR [rsi+rax*1]; Load the secret
xor
eax,r14d; XORs secret
andeax,DWORD PTR [rbx+0x74]; ANDs secretmov
DWORD PTR [rbx+0x68],eax
movzx r14d,WORD PTR [rcx+rax*2]; Leaks the data

Listing 8: Disclosure gadgets used on Zen 4 for derandomizing
KASLR (top and mid, at offset 0xb0a720 and 0x97ef01 of kernel
text respectively) and arbitrary information leakage (bottom, at offset
0x701d74 of kernel text).

hijack the return in do_softirq.part.0() on Zen 4, during
which the address of our message buffer is held by RBX.
On Zen 3, however, we only control this return in a small
percentage of the iterations. Therefore, on Zen 3 we trigger
the P HANTOM J MP to our recursive P HANTOM C ALL in the
udpv6_queue_rcv_one_skb() function, specifically on thexor on Line 10 in Listing 7-bottom. We find that we reliably
hijack the return of either ip6_local_out() or ip6_send_skb(),
during which our message buffer address is stored in R13.
Disclosure gadgets. On Zen 3, we are unable to find adisclosure gadget that uses the address in R13, even using
tools from previous work [49], or when considering duelingrecursive P HANTOM C ALLS. Hence, we leave finding thedisclosure gadget for the Zen 3 exploit as future work. We
note however, that other kernel versions may include working
disclosure gadgets.
On Zen 4, we successfully found the disclosure gadgets
shown in Listing 8. To increase the Prime+Probe signal instep 1 of breaking KASLR, out gadget loads 3 different
offsets of our guessed kernel text region, as shown in
Listing 8-top. To find the physmap base (i.e., step 3 ofbreaking KASLR), we use the disclosure gadget shown in
Listing 8-mid. Listing 8-bottom shows the arbitrary data
disclosure gadget, found using tools of previous work [49].
Dueling recursive P HANTOM C ALLS. We do not find adisclosure gadget that leaks the physical address of our
reload buffer using a location in our message buffer, i.e.,
step 2 of breaking KASLR. We therefore leverage duelingrecursive P HANTOM C ALLS to complete this step, using
the two disclosure gadgets shown in Listing 9. The second
recursive P HANTOM C ALL is triggered by a P HANTOM J MP
on the instruction at Line 10 of Listing 7-bottom.

add
mov

2

rax,QWORD PTR [physmap]
QWORD PTR [rax],rdx; Adds physmap base
; Loads from physmap

Listing 9: Disclosure gadgets used on Zen 4 for finding the physicaladdress of the reload buffer by loading the guess from memory (top,at offset 0xbf6dc6 of kernel text) and adding the physmap base to it,
and dereferencing it (bottom, at offset 0xc0407 of kernel text).

Results. We evaluate I NCEPTION on an AMD Zen 4 (Ryzen
7 7700X), with microcode version 0xa601201 and 16GB of
RAM, running Linux 5.19.0-28-generic with all mitigations
enabled. We run our attack 50 times, each time leaking
1KB of randomized data after a reboot. Of the 50 runs, we
successfully break KASLR in 45 cases, using a median timeof 168 seconds. In those cases, I NCEPTION leaks data at a
rate of 39 bytes/s, with an accuracy of 93.5%.
To find /etc/shadow, we again run I NCEPTION in parallelon all 8 available cores. We attempt to locate /etc/shadow
10 times, each with a timeout of 3 hours, and reboot themachine after every attempt. Our results show that we areable to successfully leak the root password hash in 6 of the
10 runs, in a median of 40 minutes.

8

Alternative TTE variants

We have demonstrated how a variant of TTE can be leveraged
on AMD systems to leak arbitrary data. In this section, we
will discuss the security impact of other potential variants of
TTE. We then systematically explore what TTE variants canbe triggered on various Intel and AMD microarchitectures.
We expect our exploration to motivate future work that looks
for exploitable transient execution gadgets and effective
mitigations that cover these new attack surfaces.

8.1

Exposing new attack surfaces with TTE

We lay out three scenarios that would allow arbitrarytransient code execution despite mitigations, if the target
microarchitecture allows for specific cases of TTE.
Firstly, conditional branches in the kernel may be followed by call instructions. We previously showed that on
AMD, transiently executed call instructions triggered by
BTB-misprediction can manipulate the state of the RSB.
Therefore, being able to skew the direction of a conditional
branch, the attacker may be able to inject an existing returnsite in the kernel (i.e., TTE PHT-RSB ). On AMD Zen 3 and 4,
we found that we do not need to overwrite all RSB entries
to reliably trigger misprediction to transiently injected return

B

A

B

C

D

C

D

(a) TTEBTB-BTB

A
E1
D1

A

B

D

C

A

...

(d) TTEPHT-RSBCD(c) TTEOoO-BTB

B: *sp = C
ret

cond=1
r1=&cond

D0

r1=&D

r1=0
r2=&D

A: call B

je C
jmp E0E0TTE(b) TTERSB-BTB

A: test [r1], 1

TTE

TTE

TTE

C

A

B

Ex

E0

E1

D0

D1

C

...

Ex

(e) TTERSB-RSB

Figure 9: TTE using five different methods. The leak gadgets(D, green) and the training calls in (d) and (e) (Ei , yellow) arenever architecturally executed. A barrier (C, gray) is used to stop
speculation. Dashed red arrows indicate transiently executed paths.

targets. If a return target contains a disclosure gadget, thiswould allow an adversary to leak arbitrary data.
Secondly, on newer Intel microarchitectures with eIBRS,BHI [9] has shown that, although kernel branch predictions
are isolated from user mode, an attacker can still influence
the selection of previously used branch targets in privileged
mode. Hence, to exploit BHI, the disclosure gadget must be apreviously used branch target. TTE loosens this requirement.
Instead of needing a disclosure gadget, we can use an indirect
branch at a previously used branch target, which we in turnleverage to inject a disclosure gadget (i.e., TTE BTB-BTB ).
Lastly, conditional branch targets in the kernel may containindirect branches when retpolines are disabled (e.g., on Intel
CPUs that support eIBRS). While transient out-of-boundmemory accesses are prevented by index masking [52], speculative type confusions may bypass such checks [29]. That is,
if an attacker can skew the direction of a conditional branch,
it may allow them to execute an indirect branch transiently.
If the destination of the indirect branch is attacker-controlled,
this would result in arbitrary transient execution whenever theindirect branch is executed architecturally as also discussed
in Section 5.1 (i.e., TTE PHT-BTB ). Note that through BHI,
the injected branch target may be reused by executing a
different indirect branch in the kernel. Having established thescenarios in which TTE would bypass existing mitigations,
we now evaluate different variants of TTE.

8.2

Testing for TTE variants

We discussed TTE PHT-BTB and TTE BTB-RSB in Section 5.
We now explore other possible variants of TTE. Figure 9
describes the experiments that we designed to test for

Model

Microarch.

Year

TTE RSB-RSBA

B: *sp = C
ret r1

TTE PHT-RSB

r1=&C
r2=&D

TTE BTB-RSBTTETTE OOO-BTB

r1=&B
r2=&C

A: load [r1]jmp [r2]

TTE RSB-BTB

T

A: call B
jmp rret

TTE PHT-BTB

B:
jmp [r2]

TTE BTB-BTBA:
jmp [r1]

Ryzen 5 1600X
Ryzen 5 2600X
EPYC 7252
Ryzen 5 5600G
EPYC 7413
Ryzen 7 7700X
i7-8700K
i9-9900K
Xeon Silver 4314
i7-10700K
i7-11700K
i7-12700K (P-core)i7-12700K (E-core)i7-13700K (P-core)i7-13700K (E-core)

Zen 1
Zen +
Zen 2
Zen 3
Zen 3
Zen 4
Coffee Lake
Coffee Lake R
Ice Lake
Comet Lake
Rocket Lake
Golden Cove
Gracemont
Raptor Cove
Gracemont

2017
2018
2019
2019
2021
2022
2017
2018
2021
2020
2021
2022
2022
2022
2022

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
-

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
-

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
-

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
-

✓
✓
✓
✓
✓
✓
-

✓
✓
✓
✓
✓
✓
-

✓
✓
✓
✓
✓
-

Table 1: CPUs that are vulnerable speculative training of the BTB,
i.e., TTE *-BTB , and of the RSB, i.e., TTE *-RSB .

these other variants. Similar to experiments in Section 5,code locations A and B are used to manipulate the branchpredictors, C is a barrier target and D is a disclosure gadget.
TTE BTB experiments. To test for TTE BTB - BTB , we first train
the branch predictor to branch from A to B in a preparatory
training step T. In the training in transient execution step
TTE, we transiently execute B by changing the architecturalbranch target in A to the barrier target C. However, thepreviously injected B will be predicted, and we provide itwith D as branch target. To test for TTE RSB - BTB , we train the
RSB to return to the instruction immediately following thecall in A. We prevent this from architecturally executing by
overwriting the actual return target on the stack (sp) with C.
We expect the jmp rret in A to transiently execute with thebranch target D. Finally, to test for TTE OOO - BTB , the training
branch source follows a load instruction that faults in the
TTE step, because we pass it a null pointer. Because of OoO,
the branch is transiently executed regardless. The CPU defers
handling the fault to a later stage in the pipeline.
TTE RSB experiments. To test for TTE PHT- RSB , we rely on
conditional forward branches being predicted as non-taken by
default. Therefore, in the TTE step we speculatively execute
jmp E0 , which starts executing calls transiently. Likewise, totest for TTE RSB - RSB , we again overwrite the architectural return target on the stack (sp) with C. We expect the gadgets Ei
following A to transiently execute, pushing their return targets(Di ) to the RSB. Testing TTE O O O-RSB is challenging, since
an invalid memory access as done for TTE O O O-BTB would require kernel-level page-fault handling, which trashes the RSB
state. We therefore excluded this experiment for the RSB.
Results. Table 1 shows the results of running all TTE
variants on the CPUs we have available in our lab. We notethat certain experiments show weaker (yet distinct) signal
on certain microarchitectures. This is a common artifact ofconstructing generic experiments, which can be overcome
by fine-tuning them for the given microarchitecture. The
results show that training of BTB in transient execution is
feasible in most scenarios and microarchitectures. Exceptions
are TTE OOO - BTB on the more recent AMD CPUs andTTE *- BTB on energy-efficient Intel cores embedded next
to the high-performance cores in recent Intel processors.
The results further show that all AMD CPUs in our lab aresusceptible to the training of the RSB in transient execution,although the injected entry is not always used, as discussed
in Section 5.2. On Intel, we are unable to transiently train
the RSB on any of the considered microarchitectures.
Discussion. Our results show that the previously describedattack scenarios (TTE PHT-RSB on AMD, TTE BTB-BTB
on Intel, and TTE PHT-BTB on both) are realistic on the
microarchitectures that we considered, and future mitigations
should consider their attack surfaces.

9

Mitigation

We discuss mitigation strategies against I NCEPTION in thissection. Our analysis shows that a complete mitigation of
I NCEPTION requires hardware modification for stopping
TTE, but the attack surface can be reduced by flushing thebranch predictor state on privilege transitions on certain microarchitectures. Unfortunately, this introduces a significant
performance penalty as shown by our evaluation. We firstpresent our analysis of possible mitigations before discussing
flushing branch prediction state and its performance impact.

9.1

Analysis of possible mitigations

Synchronization. CPU vendors recommend serializing
instructions, such as lfence, to stop transient executionof malicious control flow. While synchronization can stop
the TTE PHT-* variants, it is insufficient against I NCEPTION
since P HANTOM speculation enables hijacks of arbitrary
instructions.
Address Space Isolation (ASI). There is an ongoing effort toprevent secrets from being present in the kernel address spaceas part of a broader industry effort for a more principled
mitigation of transient execution attacks. However, currently
ASI may only reduce the attack surface; the entire address
space must still be mapped in to handle many interactions,where microarchitectural buffer flushes are necessary [44].
Unfortunately, adequate flushing mechanisms are at the timeof writing not available, as we find in Section 9.2.
Avoid transient training. Updating branch predictors usingtransient control flow is the root cause of TTE. If branchpredictors were only updated at retirement, our I NCEPTION
would be unsuccessful. There might exist undocumented
MSR registers that control the behavior of the CPU frontend,such that early branch predictor updates are prevented frombeing dispatched. This would mitigate all TTE attacks. At
time of writing, we are unaware whether such a functionality
exists on affected CPUs. AMD has previously disclosed such
undocumented MSR registers that can be accessed to toggle
features or reconfigure CPU properties. SuppressBPOnNonBr
MSR bit in AMD documents, for mitigating P HAN TOM J MPS [50], is one such example [6]. Counter-intuitively
and unfortunately, I NCEPTION works using P HANTOM J MP,
regardless setting this bit, as we discussed in Section 6.
Speculative BPU structures. By designing dedicated speculative variants of branch predictor structures, predictions
do not become visible outside of the transient window
in which they were inserted. As an example, our resultson Intel microarchitectures suggest that they implementa speculative RSB. By using speculative variants of all
branch predictor structures, TTE attacks can be prevented bydiscarding the transiently updated structure. However, while
the RSB typically contains only 16 or 32 entries, the BTB
typically contain thousands of entries. Creating a speculative
counterpart for every predictor structure is thus a costly
operation, and unlikely to be implemented in practice.
Isolating the branch predictor state. Some existing
hardware mitigations, such as Intel eIBRS, stop the branchpredictions learned in a lower privilege mode from being
used in a higher one. While this reduces the attack surfaceof TTE, and in particular I NCEPTION, other TTE variants
remain possible in principle, as discussed in Section 8.1.
Investigating the feasibility of such attacks is an interesting
direction for future research. For mitigating I NCEPTION on
affected AMD CPUs without eIBRS, a complete flushing of
the branch predictor state is an alternative option.

9.2

Full predictor buffer sanitization

Creative spot mitigations continue to fall short in face of
newer attacks. For example, retpoline [47] is bypassed
by Retbleed [49], and now jmp2ret [6] by I NCEPTION.
Furthermore, these mitigations introduce ubiquitous sourcecode changes and configuration parameters, which affect themaintainability of the OS kernel. Instead of additional spot
mitigations, issuing IBPB on privilege level elevation may
provide an in-depth mitigation against P HANTOM speculation
and I NCEPTION, however with a high performance cost. The
Xen Project Security Team anticipated that jmp2ret wasinadequate and enable IBPB-on-entry by default for the Xen
hypervisor to mitigate P HANTOM vulnerabilities [46]. Using
IBPB-on-entry rests on the assumption that all potentiallyharmful branch prediction state is sanitized.
We evaluate the performance impact of IBPB-on-entry
on Linux using the UnixBench test suite1 . We run the test
suite 5 times with and without the IBPB-on-entry enabled.
1 https://github.com/kdlucas/byte-unixbenchMicroModelarchitecture
Zen 1
Zen +
Zen 2
Zen 2
Zen 3
Zen 4

Microcode

Ryzen 5 1600X 0x8001137
Ryzen 5 2600X 0x800820d
Ryzen 5 3600X 0x8701021
EPYC 7252
0x8301038
Ryzen 5 5600G 0xa50000c
Ryzen 7 7700X 0xa601201

Performance overhead
single-core
multi-core
239.2 % / 234.3 % ∗ 198.4 % / 216.9 % ∗226.6 % / 205.0 % ∗ 183.1 % / 204.0 % ∗130.1 %
95.2 %
128.6 %
93.1 %
35.05 %
29.35 %
59.90 %
87.33 %IBPB effectcycles (median) flush direct flush indir
8,803 cycles
8,196 cycles
1,306 cycles
1,306 cycles
738 cycles
962 cycles

✓
✓
✓
✓
✗
✗

✓
✓
✓
✓
✓
✓

∗ : Simultaneous Multi-Threading (SMT) disabled

Table 2: Performance overhead of single- and multi-core benchmarks with the IBPB-on-entry mitigation, including the cost of issuing one
IBPB. We benchmark with and without SMT enabled where relevant. IBPB only concerns indirect branches on Zen 3 and 4.

We compute median results for each of the 12 tests in thetest suite, from which we then derive a cumulative geometricmean. The final result is a score analogous to number of operations per time unit. Hence, we denote performance overhead
as scorebaseline /scoreibpb − 1. Furthermore, we measure themedian number of clock cycles for issuing IBPB (using the
precise APREF clock cycle counter [7]) over 1 M samples.
Table 2 shows the results of our benchmarks. Because
Zen 1 and Zen + do not have STIBP support, for a complete
mitigation, we also benchmark with SMT disabled. An
attacker could otherwise poison the BTB from a sibling
thread after the IBPB has been issued. Without disabling
SMT, these parts are also vulnerable to existing attacks, like
Retbleed. However, SMT is left enabled on Linux regardless.
IBPB is an expensive operation, most particular for
Zen 1(+), but it is necessary for a complete mitigation of
I NCEPTION. Surprisingly, for Zen 3 and Zen 4, IBPB issubstantially cheaper, and has suspiciously low performance
impact. This observation led us to furthermore check thescope of IBPB on the evaluated systems. We discover that
IBPB, which sanitized branches of all types on Zen 1(+) andZen 2, no longer does so for Zen 3 and Zen 4. To determine
the impact of this for mitigating I NCEPTION, we execute anarchitectural direct recursive call, while catching the stack
overflow fault. Our results show that this primes the BTB
with a direct recursive P HANTOM C ALL which is not flushed
by IBPB. Consequently, we conclude that I NCEPTION cancircumvent IBPB-on-entry on Zen 3 and Zen 4 systems byinjecting all P HANTOM J MP and P HANTOM C ALL predictions
using direct branches instead of indirect ones. AMD does
not recommended IBPB-on-entry as a mitigation against
I NCEPTION, which likely is for this reason.

10

Related work

The confinement problem is a known issue in computer
security since the 1970s [34]. 20 years later, Kocher wasamong the first to consider this problem in the context of
microarchitectural timing attacks [31]. Over the past few
decades, microarchitectural side channels have been studied
on the CPU caches [16, 22, 39, 41, 53], µop caches [42],execution units [8, 10, 21, 32] and branch predictors [2, 17, 18].
Transient execution attacks. Kocher et al. [30] showedthat a mispredicted branch combined with a CPU cache sidechannel can be used to leak arbitrary memory, resulting inSpectre attacks. Spectre variant 1 (also known as SpectrePHT) bypasses array bounds checks through mispredictedconditional branches and Spectre variant 2 (also known
as Spectre-BTB) injects malicious branch targets into the
BTB for indirect branch instructions. In addition, Lipp etal. [35] showed that OoO pipelines in modern CPUs execute
instructions following a faulting instruction, which could
result in transient use of unauthorized memory if present in
the L1d cache. These are the two main categories transient
execution attacks as Canella et al. categorized them, andthey furthermore categorized branch predictor training
methods as in-place and out-of-place [11]. Following Spectre,
Maisuradze et al. [36], Koruyeh et al [33], and Wikner et
al. [48] demonstrated Spectre attacks via the RSB. Similar
to [48] and [36], I NCEPTION works by overflowing the RSB.
However, unlike previous attacks, I NCEPTION does so in atransient execution window which expands the attack surfaceof Spectre. RSB training in transient execution was explained
however not used in [33]. BTB training in transient execution
was used by [49], but the purpose was to suppress page faults,
and not to increase the attack surface.
Spectre attack arms-race. To mitigate Spectre-BTB attacks
against the kernel, Turner et al. invented retpolines [47], andAMD invented lfence-retpoline [3]. Intel invented IBRS, andenhanced IBRS for newer CPUs, to prevent use of branches
injected from a lower privilege level to be used at a higher
one [12, 40]. These defenses have all been broken. Milburn
et al. [37] showed that lfence-retpolines are vulnerable toSpectre-BTB, because certain workloads on the sibling
thread could extend the speculation window of the victim.
Barberis et al. [9] presented BHI, a confused-deputy attack
against the BTB, forcing branch target injection within theprivileged context to bypass the eIBRS mitigation. Wikner
and Razavi [49] showed that the RSB-backed return target
predictor could be bypassed to use the branch target predictor
instead, bypassing the deployed retpoline mitigations

with their Retbleed attack. Moreover, they showed that
AMD CPUs vulnerable to Retbleed are also vulnerable
to P HANTOM J MPS [51]. In this paper we introduced
P HANTOM C ALLS, and showed that they can be transiently
executed inside a P HANTOM J MP to manipulate the RSB.
To mitigate Retbleed and BHI on Intel CPUs, Linux
combines (enhanced) IBRS and retpolines. AMD, who isunaffected by BHI, proposed jmp2ret to mitigate Retbleed [6].
This paper shows that jmp2ret can be broken with recursive
P HANTOM speculations that cause the RSB to overflow.

11

Conclusion

We introduced Training in Transient Execution (TTE) in thispaper. TTE expands the attack surface of transient controlflow hijacks by enabling the attacker to train the BTB and
RSB in the kernel context. We further introduced P HANTOM C ALL, a new P HANTOM primitive that enables TTE without
relying on complex gadgets in the kernel, by using the CPU
as a confused deputy. Our end-to-end exploit, called I NCEP TION , uses a recursive P HANTOM C ALL to create an infinite
hardware loop in transient execution that poisons many RSB
entries with an attacker-controlled return address. In 6 out of
10 trials, I NCEPTION can leak the contents of /etc/shadow
in 40 minutes on AMD Zen 4 despite all existing andrecent hardware and software mitigations against speculative
control-flow hijacks. We expect our insights to motivate
future work to explore TTE’s new attack surfaces further andconsider efficient mitigations that protect against them.

Acknowledgments
We thank the anonymous reviewers for their feedback. We
would also like to thank Andrew Cooper of XenServer forthe discussions around P HANTOM J MP and Michele Marazzi
for proofreading the paper. This work was supported in partby the Swiss State Secretariat for Education, Research andInnovation under contract number MB22.00057 (ERC-StG
PROMISE).

References[1] The Linux kernel user’s and administrator’s guide: Spectre Side Channels. https://www.kernel.org/doc/Documentation/admin-guide/hw-vuln/spectre.
rst. Accessed on 8.2.2023.
[2] Onur Aciiçmez, Çetin Kaya Koç, and Jean-Pierre
Seifert. On the power of simple branch prediction
analysis. In CCS, 2007.
[3] AMD. Amd64 technology indirect branch control
extension. https://developer.amd.com/wp-conte
nt/resources/Architecture_Guidelines_Updat

e_Indirect_Branch_Control.pdf, 2018. Accessedon 8.2.2023.
[4] AMD. Software optimization guide for amd family 17hmodels 30h and greater processors, March 2020.
[5] AMD. Software optimization guide for amd family 17hmodels 30h and greater processors, March 2020.
[6] AMD. Technical guidance for mitigating branchtype
confusion. revision 3.0. https://www.amd.com/syst
em/files/documents/technical-guidance-for-mitigating-branch-type-confusion.pdf, 2022.
Accessed on 8.2.2023.
[7] AMD. AMD64 Architecture Programmer’s Manual
Volume 2: System Programming. https://www.amd.
com/system/files/TechDocs/24593.pdf, January
2023. accessed on 1.2.2023.
[8] Marc Andrysco, David Kohlbrenner, Keaton Mowery,
Ranjit Jhala, Sorin Lerner, and Hovav Shacham. On
subnormal floating point and abnormal timing. In S&P,
pages 623–639. IEEE, 2015.
[9] Enrico Barberis, Pietro Frigo, Marius Muench, HerbertBos, and Cristiano Giuffrida. Branch history injection:
On the effectiveness of hardware mitigations againstcross-privilege spectre-v2 attacks. In SEC. USENIX,
2022.
[10] Atri Bhattacharyya, Alexandra Sandulescu, Matthias
Neugschwandtner, Alessandro Sorniotti, Babak Falsafi,
Mathias Payer, and Anil Kurmus. Smotherspectre: Exploiting speculative execution through port contention.
In CCS. ACM, 2019.
[11] Claudio Canella, Jo Van Bulck, Michael Schwarz,
Moritz Lipp, Benjamin von Berg, Philipp Ortner, Frank
Piessens, Dmitry Evtyushkin, and Daniel Gruss. A
Systematic Evaluation of Transient Execution Attacks
and Defenses. In SEC. USENIX, 2019.
[12] Intel Corp. Indirect Branch Restricted Speculation.
https://www.intel.com/content/www/us/en/developer/articles/technical/software-secur
ity-guidance/technical-documentation/ind
irect-branch-restricted-speculation.html,
2018. Accessed on 8.6.2023.
[13] Intel Corp. Retpoline: A Branch Target Injection
Mitigation. https://www.intel.com/content/dam/develop/external/us/en/documents/retpoline-a-branch-target-injection-mitigation.pdf,
2018. Accessed on 8.2.2023.
[14] Intel Corp. Speculative Execution Side Channel
Mitigations. https://www.intel.com/content/ww

w/us/en/developer/articles/technical/softw
are-security-guidance/technical-documenta
tion/speculative-execution-side-channel-m
itigations.html, 2018. Accessed on 8.2.2023.
[15] Intel Corp. Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706.
https://www.intel.com/content/www/us/en/
developer/articles/technical/software-sec
urity-guidance/advisory-guidance/post-bar
rier-return-stack-buffer-predictions.html,
2022. Accessed on 8.2.2023.

uidance/return-stack-buffer-underflow.html,
2022. Accessed on 11.6.2023.
[26] Brian Johannesmeyer, Jakob Koschel, Kaveh Razavi,
Herbert Bos, and Cristiano Giuffrida. Kasper: Scanningfor Generalized Transient Execution Gadgets in theLinux Kernel. In NDSS, 2022.
[27] Stephan J Jourdan, John Alan Miller, and Namratha
Jaisimha. Return address stack including speculative
return address buffer with back pointers, May 24 2005.
US Patent 6,898,699.

[16] Craig Disselkoen, David Kohlbrenner, Leo Porter, andDean Tullsen. Prime+abort: A timer-free high-precision
l3 cache attack using intel TSX. In SEC. USENIX, 2017.

[28] Vladimir Kiriansky and Carl Waldspurger. Speculative
buffer overflows: Attacks and defenses. arXiv preprint
arXiv:1807.03757, 2018.

[17] Dmitry Evtyushkin, Dmitry Ponomarev, and Nael
Abu-Ghazaleh. Jump over ASLR: Attacking branchpredictors to bypass ASLR. In MICRO. IEEE, 2016.

[29] Ofek Kirzner and Adam Morrison. An analysis of
speculative type confusion vulnerabilities in the wild.
In SEC. USENIX, 2021.

[18] Dmitry Evtyushkin, Ryan Riley, Nael CSE AbuGhazaleh, Dmitry Ponomarev, et al. Branchscope: A
new side-channel attack on directional branch predictor.
In ASPLOS. ACM, 2018.

[30] Paul Kocher, Jann Horn, Anders Fogh, , Daniel Genkin,
Daniel Gruss, Werner Haas, Mike Hamburg, Moritz
Lipp, Stefan Mangard, Thomas Prescher, Michael
Schwarz, and Yuval Yarom. Spectre attacks: Exploiting
speculative execution. In S&P. IEEE, 2019.

[19] Simcha Gochman, Nicolas Kacevas, and Farah Jubran.
Method and apparatus for implementing a speculative return stack buffer, October 12 1999. US Patent 5,964,868.
[20] Enes Göktas, Kaveh Razavi, Georgios Portokalidis, Herbert Bos, and Cristiano Giuffrida. Speculative probing:
Hacking blind in the spectre era. In CCS. ACM, 2020.

[31] Paul C Kocher. Timing attacks on implementations ofdiffie-hellman, rsa, dss, and other systems. In Advancesin Cryptology—CRYPTO’96: 16th Annual International
Cryptology Conference Santa Barbara, California, USA
August 18–22, 1996 Proceedings 16, pages 104–113.
Springer, 1996.

[21] Ben Gras, Cristiano Giuffrida, Michael Kurth, Herbert Bos, and Kaveh Razavi. Absynthe: Automatic
blackbox side-channel synthesis on commodity
microarchitectures. In NDSS, 2020.

[32] David Kohlbrenner and Hovav Shacham. On theeffectiveness of mitigations against floating-point
timing channels. In SEC, pages 69–81. USENIX, 2017.

[22] Ben Gras, Kaveh Razavi, Erik Bosman, Herbert Bos, andCristiano Giuffrida. Aslr on the line: Practical cacheattacks on the mmu. In NDSS, volume 17, page 26, 2017.

[33] Esmaeil Mohammadian Koruyeh, Khaled N. Khasawneh, Chengyu Song, and Nael Abu-Ghazaleh.
Spectre returns! speculation attacks using the return
stack buffer. In WOOT. USENIX, 2018.

[23] Daniel Gruss, Moritz Lipp, Michael Schwarz, Richard
Fellner, Clémentine Maurice, and Stefan Mangard.
KASLR is Dead: Long Live KASLR. In Engineering
Secure Software and Systems, 2017.
[24] Jann Horn. Issue 1528: Speculative Execution, Variant 4:
Speculative Store Bypass. https://bugs.chromium.
org/p/project-zerot/issues/detail?id=1528,
2018. Accessed on 11.6.2023.
[25] Intel Corp. Return Stack Buffer Underflow / Return
Stack Buffer Underflow / CVE-2022-29901, CVE-202228693 / INTEL-SA-00702. https://www.intel.com/
content/www/us/en/developer/articles/technical/software-security-guidance/advisory-g[34] Butler W Lampson. A note on the confinement problem.
Communications of the ACM, 16(10):613–615, 1973.
[35] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas
Prescher, Werner Haas, Anders Fogh, Jann Horn,
Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval
Yarom, and Mike Hamburg. Meltdown: Reading kernel
memory from user space. In SEC. USENIX, 2018.
[36] Giorgi Maisuradze and Christian Rossow. Ret2spec:
Speculative execution using return stack buffers. In
CCS. ACM, 2018.
[37] Alyssa Milburn, Ke Sun, and Henrique Kawakami. You
cannot always win the race: Analyzing the lfence/jmp

mitigation for branch target injection. arXiv preprint
arXiv:2203.04277, 2022.
[38] Alex Murray. Unprivileged eBPF disabled by default for
Ubuntu 20.04 LTS, 18.04 LTS, 16.04 ESM. https://
discourse.ubuntu.com/t/unprivileged-ebpf-d
isabled-by-default-for-ubuntu-20-04-lts-1
8-04-lts-16-04-esm/27047. Accessed on 8.2.2023.
[39] Dag Arne Osvik, Adi Shamir, and Eran Tromer. Cache
attacks and countermeasures: the case of aes. In Cryptographers’ track at the RSA conference. Springer, 2006.
[40] Kim Phillips. LKML: [PATCH 0/3] x86/speculation:
Support Automatic IBRS, 2022.
[41] Antoon Purnal, Furkan Turan, and Ingrid Verbauwhede.
Prime+Scope: Overcoming the Observer Effect for
High-Precision Cache Contention Attacks. In CCS.
ACM, 2021.
[42] Xida Ren, Logan Moody, Mohammadkazem Taram,
Matthew Jordan, Dean M Tullsen, and Ashish Venkat.
I see dead µops: Leaking secrets via intel/amd micro-op
caches. In ISCA, pages 361–374. IEEE, ACM, 2021.
[43] André Seznec and Pierre Michaud. A case for (partially)tagged geometric history length branch prediction. The
Journal of Instruction-Level Parallelism, 8:23, 2006.
[44] Junaid Shahid and Ofir Weisse. [RFC PATCH 00/47]
Address Space Isolation for KVM. https://lkml.org/lkml/2022/2/23/14, 2022. accessed on 12.06.2023.
[45] Teja Singh, Sundar Rangarajan, Deepesh John, Russell
Schreiber, Spence Oliver, Rajit Seahra, and Alex
Schaefer. 2.1 zen 2: The amd 7nm energy-efficient
high-performance x86-64 microprocessor core. In
ISSCC. IEEE, 2020.
[46] Xenproject.org Security Team. Retbleed - arbitrary speculative code execution with return instructions. https://xenbits.xen.org/xsa/advisory- 407.html,
2022. Accessed on 8.2.2023.
[47] Paul Turner.
Retpoline: a software construct
for preventing branch-target-injection.
https://support.google.com/faqs/answer/7625886,
2018. Accessed on 8.2.2023.
[48] Johannes Wikner, Cristiano Giuffrida, Herbert Bos,
and Kaveh Razavi. Spring: Spectre Returning in the
Browser with Speculative Load Queuing and Deep
Stacks. In WOOT. IEEE, 2022.
[49] Johannes Wikner and Kaveh Razavi.
Retbleed:
Arbitrary Speculative Code Execution with Return
Instructions. In SEC. USENIX, August 2022.

[50] Johannes Wikner, Daniël Trujillo, and Kaveh Razavi.
Addendum to Retbleed: Arbitrary Speculative Code
Execution with Return Instructions. August 2022.
[51] Johannes Wikner, Daniël Trujillo, and Kaveh Razavi.
Phantom: Exploiting Decoder-detectable Mispredictions. August 2023.
[52] Dan Williams.
LKML: [PATCH v6 02/13] array_index_nospec: sanitize speculative array dereferences. https://lkml.org/lkml/2018/2/16/
65, 2018. Accessed on 8.2.2023.
[53] Yuval Yarom and Katrina Falkner. FLUSH+RELOAD:
A High Resolution, Low Noise, L3 Cache Side-Channel
Attack. In SEC. USENIX, 2014.
[54] Tse-Yu Yeh and Yale N Patt. Two-level adaptive
training branch prediction. In Proceedings of the 24th
annual international symposium on Microarchitecture,pages 51–61, 1991.
[55] Tao Zhang, Kenneth Koltermann, and Dmitry Evtyushkin. Exploring branch predictors for constructing
transient execution trojans. In ASPLOS, pages 667–682.
ACM, 2020.
[56] Peter Zijlstra and Thomas Gleixner. [PATCH v3
00/59] x86/retbleed: Call depth tracking mitigation.
https://lkml.org/lkml/2022/9/15/427, 2022.
Accessed on 8.2.2023.
[57] Peter Zijlstra and Borislav Petkov. Re: [PATCH]
x86/CPU/AMD: Rename the spectral chicken.
https://lkml.org/lkml/2023/4/25/875, 2023.
Accessed on 11.6.2023.