# SoK: Analysis of Root Causes and Defense Strategies for Attacks on
Microarchitectural Optimizations

Nadja Ramhöj Holtryd, Madhavan Manivannan and Per Stenström  Department of
Computer Science and Engineering
Chalmers University of Technology
Göteborg, Sweden
Email: {holtryd, madhavan<EMAIL_ADDRESS>

###### Abstract

Microarchitectural optimizations are expected to play a crucial role in
ensuring performance scalability. However, recent attacks have demonstrated
that microarchitectural optimizations, which were assumed to be secure, can be
exploited. Moreover, new attacks surface at a rapid pace limiting the scope of
existing defenses. These developments prompt the need to review
microarchitectural optimizations with an emphasis on security, understand the
attack landscape and the potential defense strategies.

We analyze timing-based side-channel attacks targeting a diverse set of
microarchitectural optimizations. We provide a framework for analysing non-
transient and transient attacks, which highlights the similarities. We
identify the four root causes of timing-based side-channel attacks:
determinism, sharing, access violation and information flow, through our
systematic analysis. Our key insight is that a subset (or all) of the root
causes are exploited by attacks and eliminating any of the exploited root
causes, in any attack step, is enough to provide protection. Leveraging our
framework, we systematize existing defenses and show that they target these
root causes in the different attack steps.

##  1 Introduction

Computer architecture is facing a security crisis [79, 80]. Recent attacks
[100, 114, 97, 173, 170, 28, 149] have demonstrated that microarchitectural
optimizations, which were assumed to be fundamentally secure for a long time,
leak information which can be exploited to steal secrets. Furthermore,
efficient attacks continuously emerge targeting defenses, thereby limiting
their effectiveness or even rendering the defenses moot altogether [58, 22,
52, 176, 140, 27, 138, 29, 137, 161, 20, 184]. Simultaneously, with the
slowing down of Moore’s Law, microarchitectural optimizations are expected to
play an increasingly important role in ensuring performance scalability.
Consequently, there is a strong need to be able to leverage microarchitectural
optimizations without compromising security.

Microarchitectural optimizations, widely implemented in commercial processors,
like branch predictors [5, 4, 49, 100, 51], caches [68, 188, 136] and
prefetchers [1, 40, 44, 158, 66, 175] among others, are prone to attacks. A
recent paper [146] demonstrates that several optimizations proposed in
literature, but not known to be commercially implemented as yet, such as value
prediction [111], also are vulnerable. This underscores the importance of
conducting a thorough review of microarchitectural optimizations with an
emphasis on security.

Prior works have started the important task of analyzing attacks and defenses
for different microarchitectural optimizations [163, 35, 33, 82, 118, 37, 78,
185, 54]. However, most of the works focus only on transient attacks and
defenses [35, 33, 82, 185, 78], SW-based defenses [37] or cover a limited set
of non-transient attacks [163, 54]. Pandora [146] considers a broader set of
non-transient microarchitectural optimizations and provides
_microarchitectural leakage descriptors_ (MLDs) which quantify the information
leakage. The MLDs show if a specific optimization can leak and how much
information is leaked (1-bit or a few bits). Unfortunately, this information
falls short on providing a systematic analysis of the similarities across
different microarchitectural optimizations and the underlying root causes
which make them vulnerable to attacks. Such an analysis can also help with the
categorization of existing defense strategies and with the potential
identification of attacks and defenses.

Our goal, in this paper, is to perform a systematic analysis to highlight the
common root causes which make microarchitectural optimizations vulnerable to
exploits that reveal secrets. In order to enable analysis of a diverse set of
microarchitectural optimizations, we present an abstract model of the
architecture and the microarchitectural state transitions involved in an
attack. Using this model as a framework, we analyze several timing-based side-
channel attacks available in the literature on an extensive set of
microarchitectural optimizations: cache, prefetching, branch prediction,
computational simplification, speculative execution and value prediction. We
also analyse additional microarchitectural optimizations like cache
compression, pipeline compression, register-file compression, silent stores
and computation reuse but omit them from the discussion due to space
constraints.

Our analysis reveals four root causes which are exploited in order to succeed
with attacks targeting the diverse set of microarchitectural optimizations
covered. The root causes are determinism, sharing, access violation and
information flow. Here, determinism causes microarchitectural optimizations to
be triggered in the same way under the same pre-conditions, leading to
predictable microarchitectural state transitions and timing variations.
Sharing of microarchitectural state, which is accessible to both the adversary
and the victim, enables the creation of a side-channel. Access violation
enables access to a secret outside of the intended protection domain. Finally,
information flow refers to exchange of information through microarchitectural
state. We note that a subset of these root causes have been identified
individually in the context of specific attacks [116, 43, 163, 82, 28].
However, in our analysis we show that a subset of, or all, the root causes are
common across attacks on a broad set of microarchitectural optimizations.

We show that the proposed defenses that focus on the vulnerabilities in
different microarchitectural optimizations can be classified as targeting one
or more of the identified root causes. We observe that similar defenses can be
/ are applied across different microarchitectural optimizations, with the same
root cause vulnerability. For instance, partitioning can thwart attacks using
the cache [98, 115], SMT [2] and branch prediction [177, 193], by affecting
sharing, information flow and determinism. In addition, the defenses can also
be applied to address the applicable root causes in the different steps of the
attack. Eliminating any of the root causes, exploited by an attack, in any of
the attack steps can protect against the attack. We also discuss potential
attacks and defenses for vulnerable microarchitectural optimizations.

Overall, our analysis demonstrates the versatility of the framework to capture
a diverse set of attacks and defense strategies for different
microarchitectural optimizations. We expect that our framework can be easily
extended to study microarchitectural optimizations we do not explicitly cover
in this paper. We also believe that it can assist computer architects in
understanding the landscape of attacks on a broad range of microarchitectural
optimizations, categorizing existing defense strategies proposed to thwart
such attacks, and in designing secure microarchitectural optimizations.

In summary, we make the following contributions:

  * •

We identify four root causes: determinism, sharing, access violation and
information flow, that enable timing-based side-channel attacks on a wide
range of microarchitectural optimizations.

  * •

We provide a framework and analyze both transient and non-transient execution
attacks on a broad range of microarchitectural optimizations, highlighting
similarities and differences.

  * •

We analyze available defenses using our framework and make a classification
based on the root causes they address. Based on the analysis, we discuss
potential attack and defense possibilities for microarchitectural
optimizations.

The paper is structured as follows. Section 2 presents our framework and
defines the root causes. Section 3 and 4 use the framework to systematize the
attacks and defenses, respectively. Section 5 discuss general observations
before we conclude in Section 6.

##  2 Systematization Framework

We first present an abstract architecture model and outline the steps for
carrying out attacks based on the model. We then use this model as a framework
to identify the root causes that enable attacks. Finally, we present an actual
attack in the context of this framework.

###  2.1 Abstract model and side-channel attack

The architecture model is represented as a finite state machine (FSM) where
the architectural state (AS), comprising SW-visible registers and memory, is
the externally visible interface, that is accessible to a program. An FSM
transition is caused when instruction execution leads to a change in the $AS$.

The microarchitecture represents an implementation of the FSM specification
and typically comprises several microarchitectural optimizations, denoted _{
O1,O2, … ,On}_, to enable an efficient implementation. A microarchitectural
optimization uses a set of microarchitectural resources, denoted _R ={R1,R2, …
,Rm}_, to implement the intended functionality. This model permits resources
to be shared across different optimizations. We define microarchitectural
state (MS) as a snapshot of the state of all the $m$ microarchitectural
resources in the system at time instance $t$, denoted _MS ={state(R1),
state(R2), … , state(Rm)}_t__.

It is important to note that while the change in $AS$ caused by an FSM
transition remains the same across different implementations of a given FSM
specification, the change in _MS_ varies depending on the optimizations
triggered, resources used and the implementation. Even when considering a
specific implementation, there is a one-to-many mapping relationship between
$AS$ and _MS_ ; i.e., a single $AS$ can have several equivalent _MS_.
Furthermore, the time it takes for an implementation to make a transition
between different _MS_ (caused by an action) may vary and this property is
typically exploited by attacks. As an example, executing a load instruction
will cause a change in the $AS$ while the insertion of a corresponding line in
the cache hierarchy as a consequence of executing the load instruction will
cause a change in the state of the cache(s) which is a microarchitectural
resource.

We next consider an abstract model of an attack that shows the different steps
involved while leveraging _MS_ as the side-channel to communicate the secret
from a victim to an adversary. In our model, we define a step as a tuple of
current state and action which leads to a new state, _{ MScurrent,
action_}$\rightarrow$_MS next_. Figure 1 shows the different steps listed in
this model and is based on the attacks proposed in literature [163, 35, 33,
82, 118, 37, 78, 185]. We assume _MS_ is in the initial state (_MS I_) before
any of the steps in the attack are carried out. When the _setup_ step is
performed _MS I_ makes a transition to the primed state (_MS P_). The _setup_
step ensures that the necessary preconditions are in place to encode the
secret into _MS P_ in the next step of the attack. When the _interact_ step is
performed the secret is accessed and is encoded in the microarchitectural
state (_MS E_). The secret is encoded specifically through the state of one or
more microarchitectural resources. If the secret is encoded through a
microarchitecture resource state, that is accessible to both the victim and
the adversary, it can potentially be used as a side-channel to communicate the
secret.

Figure 1: _MS_ transitions in different steps of an attack.

Attacks optionally utilize the _transmit_ step in case the encoded
microarchitectural resource state is not accessible by the adversary or the
specific _MS_ based side-channel is noisy (i.e. the channel is prone to high
error rate and has low channel bandwidth). When the transmit action is
performed the secret is usually re-encoded through the state of a different
shared microarchitectural resources (_MS T_) which can address the
aforementioned transmission limitations. When the _receive_ step is performed,
the adversary accesses the microarchitectural state of the specific
resource(s) and observes timing variations based on the encoded secret while
the state transitions to _MS R_. Finally, in the decode step, the timing
variations observed are used as the basis to infer the secret.

The steps outlined above that cause _MS_ transitions and secret information to
be leaked can be performed by the adversary, the victim or both, depending on
the type of attack. In the abstract model it is required that the state of at
least one microarchitectural resource is shared between the victim and an
adversary to enable information flow and consequently communicate the secret.
The microarchitectural resources that are shared between the victim and the
adversary are specific to the implementation and the threat model (see Section
2.3 for details).

Prior works define attack steps differently which leads to fewer/more steps.
For example, Xiong et al. [118] defines three attack steps while Hu et al.[82]
use six attack steps. In contrast, our attack model include five steps where
each step consists of action(s) performed by adversary and/or victim on
microarchitectural resource(s) _MS_ which leads to a new _MS_. Note that the
difference between the _interact_ and _transmit_ step is that the former
accesses and encodes the secret on _MS_ while the latter re-encodes the secret
on shared _MS_.

We exemplify the abstract model by describing the steps in the well-known
flush+reload [188] attack. This attack uses a single shared microarchitectural
resource, a shared cache (_SC_). The goal of the attack is to infer the secret
which is revealed through the victim’s cache accesses because of data-
dependent control flow. A prerequisite for the attack is that the cache lines
of interest are mapped to a shared page that is accessible by the adversary as
well as the victim. During the _setup_ step, the adversary uses the _clflush_
instruction to evict the lines belonging to the shared pages from the cache.
The fact that the pages are shared allows the adversary to evict data that is
accessed by a victim. The state of the cache after this step is _MS
P{RSC[[target]=null]}_. During the _interact_ step the victim executes and
interacts with the secret which is encoded in the _SC_ state by the
presence/absence of the specific target cache line(s). The cache state changes
to _MS E{RSC[[target]=A]}_. Since the cache is shared the adversary can detect
the state change that has occurred as a result of the interaction. The
adversary, during the _receive_ step, accesses the cache line(s) (target) and
measures the time. Through timing the adversary deduces which line(s) the
victim has inserted and thereby infers the secret.

###  2.2 Root causes

We define the root causes of an attack in the context of the abstract model
and exemplify with an actual attack.

####  2.2.1 Determinism

We define determinism as the characteristic of a microarchitectural
optimization whereby microarchitectural resource(s) used by an optimization,
under the same pre-conditions, is/are triggered in the same manner and cause a
predictable microarchitectural state transition and timing variation. In other
words, determinism causes an expected _MS_ transition and timing variation
upon an action by the adversary and/or the victim. In the abstract model of
the attack, determinism enables the adversary to control _MS_ transitions from
_MS I_ through to _MS R_ across multiple steps.

####  2.2.2 Sharing

We define sharing as the characteristic of a microarchitectural optimization
whereby the state of the microarchitectural resource(s) used by an
optimization is/are shared between a victim and an adversary. In the abstract
model sharing allows for the creation of a side-channel between the victim and
the adversary’s protection domain through _MS_.

####  2.2.3 Access violation

We define access violation as the characteristic of a microarchitectural
optimization whereby one/many microarchitectural resource(s) permit(s) access
of secret data which is outside the protection domain of the program on the
microarchitectural level. This consequently enables information to flow
outside the intended protection domain and occurs either in the _interact_ or
the _receive_ step of the attack which causes secret information to be encoded
into _MS_.

####  2.2.4 Information flow

We define information flow as the characteristic of a microarchitectural
optimization to exchange information through the state of one or many
microarchitectural resource(s). Information flow enables the adversary to
infer the secret by observing the state change of microarchitectural
resource(s).

The flush+reload attack, discussed earlier, exploits determinism, sharing and
information flow in each of the steps of the attack. Determinism guarantees
that the three state transitions occur in the attack. Firstly, the eviction of
the target line(s) from the cache in _setup_ , followed by insertion of a
cache line in _interact_. Finally, timing differences are observed based on
the presence and/or absence of specific cache lines in _receive_. Likewise,
information flow and sharing guarantee that the secret is encoded and
communicated, through _MS_ of the shared _SC_ , from the victim to the
adversary, across the different steps. Access violation is not exploited in
this attack since the _interact_ step, executed by the victim, does not lead
to an access outside its own protection domain, i.e., there is not an access
violation on the microarchitectural level. In general, attacks can exploit a
subset or all the root causes as we will show in Section 2.4 and 3.

###  2.3 Threat Model

We consider four types of threat models in our classification. Across the
different threat models, the secret, that the adversary attempts to steal,
resides in a different protection domain from that of the adversary.

An adversary can execute on a separate core from the victim, referred to as
_CrossCore_ ; be time-multiplexed on the same core as the victim process,
referred to as _SameThread_ ; run on distinct SMT threads executing on the
same core, referred to as _SMT_ or run in isolation, referred to as _Solo_. In
the _Solo_ threat model the adversary only needs to have a pointer to the
location of the victims data (kernel memory). The threat model determines
which set of microarchitectural resources are shared or private in the attack
setting on a given machine. A _CrossCore_ threat model leads to a scenario
where fewer microarchitectural resources are shared. In contrast, assuming the
_SameThread_ or the _SMT_ threat model leads to potentially more
microarchitectural resources being shared between victim and adversary,
leading to a broader attack surface.

Another dimension of the threat model is based on whether the adversary or the
victim performs the different actions in an attack. In a typical attack the
adversary performs one or more steps. However, it has been shown that an
adversary can manipulate the victim to perform some of the required actions
through the use of specific gadgets. This is especially useful in scenarios
where the adversary does not have access to a shared microarchitectural
resource state to facilitate the _MS_ transitions. This strategy increase the
scope of possible attacks even in cases where the threat models limit the
attack surface.

One example is the Spectre v2 attack [100] which requires training the Branch
Target Buffer (_BTB_) as part of the _setup_ step. Without gadgets such
attacks would only be possible with the _SMT_ /_SameThread_ threat models
since the _BTB_ is not shared between cores. However, when the victim can be
manipulated to perform the training, a _CrossCore_ threat model can be used.
The manipulation from the adversary can be performed by calling a function in
the victims code with a controlled input, i.e., the action of triggering a
gadget. The gadget can be constructed using Return Oriented Programming (ROP)
[155] where code snippets ending with a return instruction are used by
changing the return address and thereby chaining the different snippets
together. However, these attack scenarios depend on the availability of
gadgets and/or vulnerabilities, such as buffer overflows, and most have not
been demonstrated outside of specific environments [35].

For some optimizations and attack scenarios the side-channel can be noisy
and/or obscured by other optimizations, thereby making it difficult to decode
the secrets based on _MS_ transition and the consequent timing variations.
Amplification gadget(s) can be used by the adversary to enhance the timing
differences and ease the decoding of the secret. A simple example is on the
cache side-channel, where prefetching can obscure the secret-related accesses.
This can be circumvented by using a linked list [168] or by spreading accesses
across pages [100] since most prefetchers only target linear or strided access
patterns and do not prefetch across page boundaries.

###  2.4 Case Study

Next, we will describe an actual attack, Spectre v1, using the abstract model,
the root causes we have identified and the threat model, as a framework.

####  2.4.1 Spectre v1

Figure 2: Example code for Spectre v1 attack [100].

Spectre v1 [100] leverages three different optimizations: branch prediction,
speculative execution and shared cache. The example code for the attack is
shown in Figure 2, where _x_ is controlled by the adversary and is used to
represent the address delta between the base address of _array1_ and the
secret’s location. The attack involves speculatively executing the if-clause
code block, by training the branch predictor to predict taken. When the taken
code block is speculatively executed the adversary can cause speculative
access to _array2_ indexed using the adversary controlled _x_. Even when the
speculatively executed instructions are eventually rolled back this still
leaves a trace in the cache, as a consequence of the access to _array2_ ,
which is then used to infer the secret.

Figure 3: _MS_ transitions and actions in Spectre v1.

Figure 3 show an overview of the attack steps and MS transitions. The _setup_
step consists of (mis)training the branch predictor Pattern History Table
(_PHT_) by adversary/victim to change the prediction for the targeted
conditional branch from _MS I{RPHT[[target]=Not taken]}_ to _MS
P{RPHT[[target]=Taken]}_. The necessary (mis)training can either be performed
by the adversary, restricting the threat model to SMT/SameThread, or be
performed by the victim. To make the victim perform the (mis)training of the
specific conditional branch a gadget must be located in the victim binary
containing instructions which execute and train the target _PHT_ entry to
mispredict on the conditional branch. Setup of the _SC_ , as in flush+reload,
is also needed since it will be used later in the _transmit_ step.

In the _interact_ step the victim executes speculatively and accesses the
secret because of the (mis)prediction. Speculative execution allows the CPU to
temporarily violate program semantics by transiently execute code that
accesses the secret and leave a trace in the _MS_. In the _transmit_ step the
secret is re-encoded in the state of another microarchitectural resource
through a secret dependent access to the _SC_ (_load (secret*page_size)_).
This access causes the _SC_ to transition to _MS T{RSC[(secret*page_size)]}_.
The _MS_ transition occurs before the processor detects that the speculative
execution was erroneous and rolls back the register state, leaving a trace in
the state of the _SC_. In the _receive_ step the adversary accesses the cache,
measures the time and infers the secret based on timing variations for cache
lines.

The root causes which enable this attack are determinism, sharing, access
violation and information flow. Determinism guarantees that, the adversary can
cause a _BTB_ state update in an intended entry in the _setup_ step, which is
then used in the _interact_ step. In addition, determinism ensures that the
_SC_ becomes primed, as a result of the flush, in _setup_ and that the secret-
dependent loads will result in timing variations corresponding to the lines
presence/absence observed in the _receive_ step. Access violation enables
access to the secret which resides in a different protection domain, through
speculative execution. Sharing is exploited in both the _BTB_ and the _SC_
during the _setup_ step and in the cache during the _receive_ step.
Information flow is allowed through each of the state of the shared resources,
across the different attack steps.

##  3 Systematization of Attacks

In this section we use the abstract model, the root causes and the threat
model as a framework to systematize attacks on a broad set of
microarchitectural optimizations. We describe a typical attack on each
optimization and analyze the necessary root causes exploited in the different
steps of the attack. We group attacks wherever possible and also discuss
dissimilarities between the attacks on the same microarchitecture
optimization. Note that the goal of this analysis is not to exhaustively
discuss all the attacks proposed in literature. Rather, through the
discussion, our aim is to highlight commonalities and differences across
different attacks that target a microarchitectural optimization by discussing
the following questions:

  1. 1.

Which microarchitectural resource(s) are exploited in an attack?

  2. 2.

Which root cause(s) are necessary to enable the attack and in which attack
step(s)?

  3. 3.

Under which threat model(s) is/are the attacks possible?

To simplify the discussion we categorize the microarchitectural optimizations
into two broad groups – non-transient and transient optimizations – and
analyze attacks on each of them. The systematization of attacks is presented
in Table I. Finally, we discuss microarchitectural optimizations without any
published attacks that are prone to leaks.

Microarchitectural | Attack(s) | Resource(s) | Attack steps | Threat
---|---|---|---|---
optimization |  |  | $A_{S}$ | $A_{I}$ | $A_{T}$ | $A_{R}$ | model
Shared cache (SC) |  flush+flush [68], flush+reload [188, 72, 89] | $R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 1,2,3
|  prime+probe [136, 132, 88, 93, 133] | $R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 1,2,3
|  observation [159], C5 [123] | $R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 1
|  collide+probe [113] | $R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 2
|  load+reload [113] | $R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 3
|  xlate+probe/abort [172] |  $R_{SC}$, $R_{MMU}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 1,2,3
| TLBleed [61, 3] |  $R_{SC}$, $R_{TLB}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 2,3
| CacheBleed [189] | $R_{SC_{bank}^{T}}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 3
| MemJam [126] | $R_{SC}$ | D/S/I [A] | D/S/A/I [V] | - | D/S/I [A] | 2,3
| LoR [134] | $R_{ring^{T}}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 1
| MeshUp [178] MeshAround [45] | $R_{mesh^{T}}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 1
|  CacheTiming [23, 169] | $R_{SC}$ | \- [A] | D/I [V*] | - | D/I [A] | 1/-2̂
Prefetching (P) |  Prefetch SCAs[67, 1] |  $R_{P}$,$R_{SC}$,$R_{TLB}$ | D/S/I [A] | D/S/A/I [V] | - | D/S/I [A] | 2,3
|  prefetch+reload, prefetch+prefetch [74] |  $R_{P}$,$R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 1
|  LeakingControlFlow [40] |  $R_{P}$,$R_{SC}$,$R_{TLB}$ | D/S/I [A] | D/S/A/I [V] | - | D/S/I [A] | 2,3
|  DMP [175, 146] |  $R_{P}$,$R_{SC}$ | D/S/I [V*/A] | D/S/A/I [V*/A] | - | D/S/I [A] | 2
|  Unveiling [158] |  $R_{P}$,$R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/I [A] | 1,2,3
|  FetchingTale [44] |  $R_{P}$,$R_{SC}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 2,3
Branch |  JumpOverASLR [49] | $R_{BTB}$ | D/S/I [A] | D/S/A/I [V] | - | D/S/I [A] | 2,3
prediction (BP) |  PredictingKeys [4, 5, 6, 49] | $R_{BTB}$ | D/S/I [A] | D/S/I [V] | - | D/S/I [A] | 2,3
|  BranchScope [51] | $R_{PHT}$ | D/S/I [A] | D/S/A/I [V] | - | D/S/I [A] | 2,3
|  BranchShadowing [109] |  $R_{PHT}$,$R_{LRB}$ | D/S/I [A] | D/S/A/I [V] | - | D/S/I [A] | 2,3
Computational |  Subnormal FP [16, 102] | $R_{FPU}$ |  (D/S/I)1 [A] |  D (S/I)1 [V] | - |  (D/S/I)1 [A] | -
simplification (CS) |  Early termination [63] | $R_{MUL}$ | \- [A] | D [V*] | - | \- [A] | 2,3
Transient attacks: |  Spectre v1 [100, 167], v1.1 [99] |  $R_{SC}$,$R_{PHT}$,$R_{BHB}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 1,2
Speculation-based |  Spectre v2 [100, 39, 20, 184] |  $R_{SC}$,$R_{BTB}$,$R_{BHB}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 1,2
|  Spectre v4 [124], LVI [171] |  $R_{SC}$,$R_{STL}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 2
|  Spectre v5 (ret2spec) [104, 121] |  $R_{SC}$,$R_{RSB}$,$R_{BTB}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 1,2
|  BranchSpec [90] | $R_{PHT}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 2,3
|  NetSpectre [151] |  $R_{PHT}$,$R_{AVX2}$/$R_{SC}$ | D/S/I [V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] |  -2
|  CROSSTALK [141] |  $R_{SC}$,$R_{LFB}$,$R_{staging\\_buf.}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 1
|  SMoTherSpectre [26] |  $R_{SC}$,$R_{PHT}$,$R_{ports^{T}}$ | D/S/I [A] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 3
|  SpectreRewind [52] |  $R_{SC}$,$R_{BTB}$,$R_{ports^{T}}$ | D/S/I [A] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 2,3
|  Speculative interference [22] |  $R_{SC}$,$R_{BTB}$,$R_{MSHR}$,$R_{RS}$,$R_{EU^{T}}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 1,2,3
|  ROB cont. [7] |  $R_{PHT}$,$R_{ROB}$ | D/S/I [A/V*] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 1,2,3
Transient attacks: |  Meltdown [114, 167] |  $R_{SC}$,$R_{BTB}$ [PF-US] | D/I [A] | D/S/A/I [A] | D/I [A] | D/I [A] | 4
Exception-based |  Foreshadow [170, 182] |  $R_{SC}$,$R_{TLB}$ [PF-P] | D/I [A] | D/S/A/I [A] | D/I [A] | D/I [A] | 4
|  Spectre1.2 [99] |  $R_{SC}$,$R_{TLB}$ [PF-RW] | D/I [A] | D/S/A/I [A] | D/I [A] | D/I [A] | 4
|  LazyFP [162] |  $R_{SC}$,$R_{FPU}$,$R_{SIMD}$ [#NM] | D/S/I [V] | D/S/A/I [A] | D/I [A] | D/I [A] | 2,3
|  Fallout [125] |  $R_{SC}$,$R_{SB}$ | D/S/I [A] | D/S/A/I [A&V] | D/I [A] | D/I [A] | 2,3
|  RIDL [173] ZombieLoad [149] |  $R_{SC}$,$R_{LFB}$ | D/S/I [A] | D/S/A/I [A&V] | D/I [A] | D/I [A] | 2,3
|  LVI [171] |  $R_{SC}$,$R_{FPU}$,$R_{SB}$,$R_{LFB}$ [PF] | D/S/I [A] | D/S/I [V*] | D/S/A/I [V*] | D/S/I [A] | 2,3,4

TABLE I: Attack systematization. Root causes: determinism (D), sharing (S),
access violation (A), information flow (I). Attack steps: setup ($A_{S}$),
interact ($A_{I}$), transmit ($A_{T}$), receive ($A_{R}$), performed by
adversary [A] or victim [V]. Gadget*. Threat models: 1) CrossCore, 2)
SameThread, 3) SMT, 4) Solo.1In SW.2Remote.TTemporal resource.

###  3.1 Non-transient attacks

####  3.1.1 Cache

The last-level cache is typically shared among cores to improve cache
utilization and to reduce costly off-chip accesses. The _SC_ is vulnerable to
side-channel attacks and is an attractive attack surface because of the
channel characteristics (i.e., low noise and high attack bandwidth [160]).
There exist three high-level attack categories: i) reuse-based [68, 188, 72,
89] where data is shared between adversary and victim allowing both to access
it, ii) conflict-based [136, 132, 88, 93, 133, 113], where an adversary
creates conflicts to evict target lines belonging to the victim, and iii)
observation-based [159, 69], i.e., brute-force conflicts. In observation-based
attacks the conflicts and observed behaviour relates to any cache line and is
not restricted to a selected target, as in conflict-based attacks. We note
that the same categories are common across attacks on other shared resources
and have implications for the defense strategies (see Section 4).

Prime+probe [136], a typical conflict-based attack [136, 132, 88, 93, 133,
113], is used in the absence of data sharing between an adversary and a
victim. The threat model is _CrossCore_ , since the _SC_ is shared between
cores. In the _setup_ step, the adversary first finds the set of cache lines
(eviction-set) which will create conflicts in the targeted index shared with
cache lines belonging to the victim and evict them from the cache. The state
changes to _MS P{RSC[[index]=Aadversary]}_. Next, in the _interact_ step, the
victim accesses the secret during execution which is in turn encoded in the
_SC_ state through the presence/absence of the specific target cache line(s).
The state changes to _MS E{RSC[[index]=Bvictim]}_. In the _receive_ step the
adversary accesses the target cache line(s) and based on the timing variations
infers the secret.

The root causes determinism, sharing and information flow enable the attack,
as shown in Table I. Determinism provides different guarantees in the three
steps of the attack. First, in the _setup_ step it ensures that conflicts can
be created at a specific index in the cache which causes an eviction of the
targeted cache line. Second, in the _interact_ step it ensures the secret is
encoded through the _MS_ of the _SC_. Third, it also causes timing variation
corresponding to the presence/absence of the cache line. Sharing and
information flow ensures that the secret is encoded and communicated, through
_MS_ of the _SC_ , from the victim to the adversary, across the different
steps.

Observation-based attacks [159, 69] work by observing set conflicts in all the
sets in the cache instead of actively causing them in a few sets like
prime+probe. These attacks leverage the observation that the same conflict
patterns will re-occur because the cache behavior of a program is
deterministic. An alternative _setup_ step is used, without relying on using
_clflush_ or a specific eviction-set, which involves accessing a large buffer
[159, 123, 151] to flush all cache lines in the _SC_ and creating conflicts
across all the sets in the cache. This approach, however, has the drawback of
a lower bandwidth since filling the _SC_ is time consuming. These observation-
based attacks are challenging to defend against since they rely on determinism
and the shared _MS_ of the _SC_ in the _interact_ and _receive_ steps. This
limits the defenses which can be used to avoid the attack (for details see
Section 4.1.1).

A number of attacks show that other state can also be used for attacks, such
as the state of replacement metadata [98], way prediction [113], interconnect
[178, 134], cache banks [189], translation lookaside buffer (_TLB_) [61, 3] or
memory management unit (_MMU_) [172]. Using other microarchitecture resource
state (related to _SC_) enables to circumvent defenses on the _SC_. Van Schaik
et al. [172] propose a prime+probe-like attack where an eviction-set is found
and used in the _MMU_ instead of the _SC_ to overcome defenses targeting
conflict-based attacks in the _SC_. Wan et al. [178] show an attack using
temporal contention on the mesh interconnect, while Paccagnella et al. [134]
show an attack on the ring interconnect. These attacks exploit determinism,
sharing and information flow as previously discussed in the _SC_ attacks.
However, the sharing is of other microarchitectural resources as the _MMU_ or
the mesh interconnect, instead of the _SC_. We do not exhaustively cover all
_SC_ related attacks since our goal is to discuss a representative set to
demonstrate the applicability of our framework.

####  3.1.2 Prefetching

Prefetchers predict addresses that will be used by a program and proactively
fetches them to help hide memory access latency. The attacks exploiting
prefetching can be broadly grouped into two fundamentally different
categories, 1) SW-based and 2) HW-based. Attacks that belong to the latter
category exploit the availability of a HW prefetcher (microarchitectural
resource) and specifically utilize the _MS_ of the prefetch tables and/or the
_SC_ as the side channel while attacks that belong to the former category
exploits different prefetch instructions directly which exhibits different
timing depending on the state of the _TLB_ and/or the _SC_. The attacks
exploiting SW-based and HW-based prefetching mechanisms can be further
subdivided into two categories, 1A and 2A) Attacks which exploit the lack of
permissions check and 1B and 2B) Attacks which exploit a secret-dependent
prefetching pattern.

One typical attack from category 1A, a SW-based attack that exploits the lack
of permissions check, is the address-translation attack by Gruss et al. [67]
where the goal of the full attack is to translate between virtual and physical
addresses from unprivileged user-space and overcome the protection provided by
user-space and kernel-space Address Space Layout Randomization (ASLR). We
focus on the first phase of the attack where the adversary searches through
possible addresses and tests if two virtual addresses, $a$ and $a^{\prime}$,
map to the same physical address by performing the attack. Here, address
$a^{\prime}$ can be a kernel address or a non-mapped address and not be
directly accessible to the adversary. In the _setup_ step the adversary
flushes the candidate collision address, $a$. The state changes to _MS
P{RSC[[indexa]=empty]}_. In the _interact_ step, the adversary prefetches the
address $a^{\prime}$, and performs an access violation. The access violation
is due to speculative dereferencing of kernel-space registers from user-space
[152], and not because of the prefetch instruction as suggested by Gruss et
al. [67]. The state changes to _MS E{RSC[[indexa]=a’]}_. In the _receive_ step
the adversary accesses address $a$ and based on the timing variations infers
if there is a match between $a$ and $a^{\prime}$.

The root causes exploited by the attack are determinism, sharing, access
violation and information flow, as shown in Table I. Determinism enables all
the three steps of the attack. First, in _setup_ step, it causes the cache
line corresponding to $a$ to be evicted. Second, in the _interact_ step, it
causes the prefetch of $a^{\prime}$ to be encoded through the _MS_ of the
_SC_. Third, it makes timing variation to be observed corresponding to the
presence/absence of the cache line. Access violation enables the attack by
permitting the adversary to prefetch inaccessible address(es). Sharing and
information flow guarantees that the secret is encoded and communicated,
through _MS_ of the _SC_.

In the second category in SW-based attacks, 1B, the attacks [74] use a SW-
controlled prefetch instruction (_PREFETCHW_), in the _setup_ and the
_receive_ , to reveal cryptographic keys through the data-dependent access
pattern of an application.

The attacks in category 2A, HW-based without permissions check, use HW
prefetchers to prefetch addresses outside of a sand-box [175] or in kernel-
space [40]. The prefetcher is trained in the _setup_ step, in order to issue a
prefetch to the target address in the _interact_ step. Chen et al. [40] show
that an adversary trained prefetcher can prefetch kernel addresses. In [175] a
data memory-dependent prefetcher (DMP) is trained to perform out-of-bounds
reads on pointers, since the prefetcher is allowed to use memory content to
prefetch irregular address patterns. The root causes exploited by the attacks
are determinism, sharing, access violation and information flow. In both the
attacks the state of the _SC_ is used to encode the accesses in the _interact_
step and to measure the timing difference in the _receive_ step. There is no
need of an additional _transmit_ step to encode the secret in the _SC_ , since
the prefetcher directly interacts with the _SC_ in the _interact_ step. Access
violation is exploited in the _interact_ step since the prefetch is issued
without permission checks.

Lastly, the attacks [158, 40] in category 2B, leak secrets through secret
data-dependent prefetching pattern(s). Shin et al. [158] show how data-
dependent prefetch activity can be used to leak secret keys through _MS_ in
the _SC_. Similar to the previously discussed attacks using SW-based
prefetching, which also leak secrets through data-dependent prefetch access
patterns, the root causes are determinism, sharing and information flow.

####  3.1.3 Branch prediction

Branch predictors record history of branch outcomes in order to predict the
direction of control flow after a branch instruction, to improve instruction
flow. There are two high-level strategies for attacks using the branch
predictor, reuse-based [51, 109, 100] where entries set by one process may
influence the other and conflict-based [49, 4, 6, 5] where contention is used
to evict the entry inserted by the other process.

A typical conflict-based attack is JumpOverASLR [49] where the goal of the
adversary is to determine the position of a code block in the address space of
a victim. Knowing the position of a code block can help break the protection
provided by ASLR since the randomization is based on an offset. The attack is
launched multiple times using different index values, searching for a
collision in the _BTB_. A collision in the _BTB_ can be used to infer the
address used by the victim and the offset used by ASLR. In the _setup_ step,
the adversary inserts an entry in the _BTB_ which might create a collision
with the entry later inserted by the victim code. This changes the _MS_ to
primed _MS P{RBTB[[indexI]=addr. A]}_. Next, in the _interact_ step the victim
executes and inserts a different target address at the same _BTB_ position,
creating a collision. The state transitions to _MS E{RBTB[[indexI]=addr. B]}_.
In the _receive_ step the adversary executes code which will trigger the _BTB_
entry at _index I_ and measures the execution time. If the _BTB_ entry was
changed by the victim it would result in a longer execution time since the
target address is incorrect ($B$ instead of $A$).

The root causes which enable this attack are determinism, sharing and
information flow, as shown in Table I. Determinism guarantees that, the
adversary can cause a _BTB_ state update in an intended entry, induce a
conflict on the same entry when the victim executes and measure timing
variations due to the conflict. Likewise, information flow and sharing
guarantees that the secret is encoded and communicated, through _MS_ of the
_BTB_ , from the victim to the adversary, across the different steps. Note
that this attack is restricted to the _SameThread_ threat model (although it
can be applied in _SMT_) and does not extend to _CrossCore_ because _BTB_
state is not shared across cores.

There also exist conflict-based attacks which exploit that the branch
predictions can reveal data-dependent control flow [4, 6, 5]. For example in
[5] secrets are inferred based on the predictions made in the _BTB_.

The reuse-based attack use the _PHT_ instead of the _BTB_ [51]. In BranchScope
[51], the branch predictor is manipulated into using only the directional
branch predictor, _PHT_ , where the directional prediction inserted by the
adversary is changed by the victim which reveal the direction of conditional
branches. The attack can also be used against SGX enclaves, since the _PHT_ is
shared between processes executing in SGX and outside. The same root causes as
in JumpOverASLR enable the attack.

####  3.1.4 Computational simplification

Computational simplification comprises techniques which eliminate or simplify
instruction execution. One example is the zero-skip multiplier and the same
principle can be applied on different instruction types as square root, AND/OR
and to different pipeline stages. Attacks on this type of optimizations have
been studied [43, 16, 63]. In [16] an attack is described using subnormals in
a floating-point division unit, to create visible timing differences.
Großschädl et al. [63] describe an attack using early-termination of
multiplication where the multiplication is terminated when all remaining
digits are zero, creating observable timing differences. The goal of the
attack is to leak secret keys from cryptographic SW such as RSA. There are two
prerequisites of the attack, firstly, that the adversary is able to control
the plaintext which will be encrypted and secondly, that the timing can be
observed on a side-channel. In the _setup_ the adversary calls the
cryptographic function on the victim with a plaintext. In the _interact_ step
the victim encrypts the plaintext and will experience different timings
depending on the values of the key. Großschädl et al. does not describe which
side-channel could be used in order to allow the adversary to observe the
timing difference. We note that either the _MS_ of the _SC_ or execution unit
contention could be used. A gadget is likely needed at the victim for re-
encoding of the secret to the side-channel.

The root cause exploited is determinism which enables the data-dependent
behaviour of the early-termination optimization and the timing variability. In
addition, the side-channel, which enables the adversary to observe the timing
differences, exploits sharing and information flow.

###  3.2 Transient attacks

We finally discuss transient execution attacks which exploit speculative out-
of-order (OoO) execution to execute code transiently (i.e. executed but never
committed). We use the categorization provided in related works [35], which
divide the transient attacks broadly into two groups, speculation-based [100,
39, 124, 121, 90, 151, 141, 26, 52, 22, 7] and exception-based [114, 167, 170,
99, 162, 171, 125, 173] attacks.

####  3.2.1 Speculation-based Attacks

The attacks that fall in this category exploit transient execution, due to
branch prediction and/or address/value speculation, to access the secret. An
overview of the attacks is shown in Table I. Spectre v2 [100] is a typical
speculation-based attack. The attack exploits an indirect branch to execute a
gadget which interacts with the secret in the victims protection domain,
leaving a trace in the _MS_. The prerequisites are an indirect branch that can
be (mis)trained and a known gadget in the victim’s binary that can be
manipulated to interact with the secret. The threat models are _SameThread_
and _SMT_ , since _BTB_ is a resource private to a core. However, _CrossCore_
can be used if a gadget is used to make the victim perform the (mis)training.
In the _setup_ step the adversary/victim (mis)trains the _BTB_ to insert a new
entry containing the address of the gadget for the indirect branch. The state
changes to _MS P{RBTB[[indextarget]=addr. Agadget]}_. The root causes in the
_setup_ step are determinism, sharing and information flow. Determinism
guarantees that the adversary can cause a _BTB_ state update in an intended
entry, while sharing and information flow enables the state change caused in
the _BTB_ to be observed by the victim. Note that setup of the _SC_ is also
performed, i.e. _clflush_ , since it will be used later in the _transmit_
step.

Next, in the _interact_ step the victim executes the gadget speculatively,
accesses the secret and changes the _MS_. The root causes are determinism,
access violation and information flow. Determinism guarantees that the
(mis)trained _BTB_ entry is used. Access violation enables access to the
secret through execution of the gadget which results in temporary violation of
program semantics, i.e., instructions that access the secret are executed and
are later squashed. In the _transmit_ step the secret is re-encoded in the
state of the _SC_ , by issuing load(s) to the target address(es) by the
victim. The root causes exploited are determinism, sharing and information
flow since the _SC_ contains the cache line(s) and the _MS_ of _SC_ is shared
between the adversary and the victim. Finally, in the _receive_ step the
adversary accesses the target cache line(s) and based on the timing variations
infers the secret. The root causes are the same as in the previous step, with
the difference that determinism ensures observable timing variations based on
the state of the _SC_ , i.e., the presence/absence of the target cache
line(s).

In contrast to Spectre v2, which uses the _BTB_ , other microarchitectural
resources have been used to manipulate the control flow, e.g., _PHT_ [100] or
the Return Stack Buffer (_RSB_) [104, 121]. In addition, address speculation
can be targeted for manipulating Store-To-Load (_STL_) forwarding that happens
in the Load Store Queue (_LSQ_) [124]. Many of these different attack variants
still use _SC_ as the side-channel for transmission.

Next, we discuss attacks which are more restrictive since other
microarchitectural resource(s) (not _SC_) is/are used for the transmission of
the secret. One example is BranchSpec [90] where the _PHT_ is used in the
_transmit_ and _receive_ step. The root causes exploited by the attack are the
same as in Spectre v2, while the threat model is more restrictive since the
_PHT_ , used as the side-channel, is not shared between cores. Another attack,
SMoTherSpectre [26], uses port contention to encode the secret and transmit to
a co-running SMT thread. Likewise, temporal contention in the floating-point
division unit is exploited in SpectreRewind [52]. Like SpectreRewind, the
attack proposed by Behnia et al. [22] shows that the secret can be encoded by
affecting the timing and order of older instructions, which are issued before
the secret dependent instruction(s) in program order. This is in contrast to
prior works [95, 186, 110] that focused on studying the secret-dependent
effect on younger instructions, issued after the secret dependent
instruction(s). In the attack, the non-speculative instructions timing is
affected either through the miss status handling register (_MSHR_) or
execution unit contention. As an example, let’s consider the attack using the
_MSHR_ described by Behnia et al. [22]. In the _setup_ step the adversary
evicts a number of cache lines $Y$. In the _interact_ step the a gadget,
depending on the secret value, either issues independent loads to the cache
lines $Y$ (filling up the _MSHR_ entries) or issues loads to the same cache
line (using one entry in the _MSHR_). When the target victim load occurs it
will experience different timing depending on the _MS_ of the _MSHR_.

####  3.2.2 Exception-based Attacks

The attacks that fall in this category exploit transient execution, due to
delayed exception handling to access the secret. Meltdown [114] is a typical
attack from this category where the adversary exploits transient execution due
to delayed exception handling, to read arbitrary kernel memory. In the _setup_
step the adversary causes an exception by accessing a kernel address that
resides in a kernel memory page without suitable permissions causing a page
fault, e.g., PF-US. Because of the deferred exception handling the execution
continues transiently. In the _interact_ step the adversary executes code that
uses the loaded value from the faulting kernel address. By suppressing the
exception can the transient execution continue [114]. In the _transmit_ step
the secret is encoded in the _MS_ of the _SC_ , through a load to the data
buffer, in order for the adversary to retain the information after the
transient execution is rolled back after exception handling. In the _receive_
step the secret is inferred from the state of the _SC_ , through the
presence/absence of cache line(s). Note that all the steps of the attack are
performed by the adversary.

The root causes enabling the attack are determinism, sharing, access violation
and information flow (Table I). Determinism ensures transient execution due to
delayed exception handling in the _setup_ step and that the secret is encoded
in the state of the _SC_ in the _interact_ step. Sharing enables the access
from the adversary to the victim kernel address in the _interact_ step.
Information flow enables the transiently accessed secrets to be communicated
to the non-transient execution, through the _MS_ of the _SC_. Access violation
enables the adversary, in the _interact_ step, to access kernel data which it
does not have the right privileges to access.

Attacks have shown that different types of exceptions, i.e., page fault (PF),
can be used in the _setup_ step. For instance, Foreshadow uses PF-P [170,
182], Spectre v1.2 [99] uses PF-RW while LazyFP [162] uses #NM (device not
available). Other types of page fault exceptions can also be used as shown by
Canella et al. [35]. Furthermore, in addition to reading from kernel memory,
attacks have also exploited delayed exception handling to leak data across
addresses spaces, virtual machines and even from secure enclaves [170, 182].

Another group of attacks, referred to as the microarchitectural data sampling
(MDS) attacks, exploit the state of internal buffers in the CPU, as the Line
Fill Buffers (_LFBs_) [173, 149] or the Store Buffer (_SB_) [125], in
conjunction with delayed exception handling. Specifically, the attacks
leverage the observation that values from these buffers can be leaked as a
consequence of accesses that trigger an exception. In the ZombieLoad v1 attack
[149] the adversary uses the kernel virtual address ($k$) corresponding to the
user-space address of the victim ($u$) where the secret resides. Both virtual
addresses $k$ and $u$ map to the same physical address $s$. In the _setup_
step, the adversary monitors the victim by performing repeated flush+reload
attacks on the address corresponding to the instruction just before the
loading of the secret. This enables the attacker to synchronize with the
victim and determine when it can start accessing the state of the buffers to
retrieve the secret. In addition, the contents of the data buffer are also
flushed from the _SC_. Next, in the _interact_ step, the victim performs the
load of the secret key, _load u_. This load operation will cause the secret to
be inserted in the _LFB_ (on a cache miss). The adversary performs a faulting
load i.e. the ZombieLoad, to the kernel address of the secret (_load k_),
which causes the adversary to retrieve the secret from the _LFB_. In the
_transmit_ step the adversary uses the secret as an index to a data buffer to
encode the secret into the _MS_ of the _SC_ , before the transient execution
is rolled back. In the _receive_ step the adversary accesses the data buffer
entries to infer the secret based on the timing variations arising due to _SC_
state. In contrast to Meltdown, victim’s accesses cause the secret to be
inserted in the internal buffers which are then leaked by loads that trigger
exceptions. All four root causes enable this attack. Determinism enables all
the steps of the attack while sharing the _MS_ of the _LFB_ allows for
information flow between the victim and the adversary. Access violation occurs
during transient execution when the adversary is allowed to read stale data
from the _LFB_. Unlike the MDS attacks discussed previously, Load Value
Injection (LVI) [171] uses the different types of exception-based
vulnerabilities to inject data/code and control victim’s execution by
controlling the values in the internal CPU buffers. This attack exploits the
same root causes as the MDS attacks discussed previously.

###  3.3 Vulnerable optimizations

Several microarchitectural optimizations available in literature have not been
reviewed in detail with an emphasis on security. We discuss possible attacks
using our framework for one such representative optimization, value
prediction. We also analysed vulnerabilities in a few other optimizations,
including the ones explored by Vicarte et al. [146], but omit them due to page
constraints.

Value prediction: This is a speculative optimization that aims to increase
instruction-level parallelism (ILP) and hide memory access latency by
predicting values for load misses and consequently breaking instruction
dependencies [111, 112, 135, 156, 154]. Accurate predictions can improve ILP
by increasing the overlap between memory access(es) and useful computation(s)
while mispredictions lead to pipeline squashes and re-execution of
instruction(s). In a nutshell, value prediction is implemented using table-
based structures and samples history to enable prediction.

Both reuse-based and conflict-based attacks are possible, similar to the
attacks described for the branch predictor. One possible attack that exploits
the reuse behavior is to let the victim train the predictor leading to the
secret being encoded in the predictor state. The adversary can then trigger a
prediction and use this to infer the secret. Another possible attack strategy
is to let the adversary (mis)train the predictor in order to induce the victim
to access a secret (cause an access violation) using a gadget, akin to
injection attacks. This can then be leaked to the adversary through a side-
channel, such as the _SC_. Finally, conflict-based attacks could also be
mounted by using secret dependent predictor use behavior and monitoring the
state of the prediction tables to infer secrets. The root causes exploited by
the aforementioned potential attacks are determinism, sharing and information
flow. Determinism permits the _MS_ of the prediction table to be accessed and
manipulated depending on the attack requirements. Sharing permits the _MS_ of
the prediction tables to be accessible to both the adversary and the victim
and enables information flow between adversary and victim. Access violation
could also be exploited if the predictions cause the adversary and/or the
victim to access data from outside the intended protection domain.

In summary, we observe that the necessary conditions for most attacks are
determinism, sharing and information flow and that there are few variations in
the combinations of root causes. We also note that the goal of the attacks is
either to i) exploit data-dependent implementations to leak encryption keys,
or ii) circumvent privilege checks to typically read kernel data. All attacks
in the later category exploit access violation.

##  4 Systematization of Defenses

We present a systematization of defenses against attacks targeting different
microarchitectural optimizations. We specifically discuss optimizations for
which several attacks and defenses exist in literature: cache, prefetching,
branch prediction, computational simplification and transient execution
attacks. For each of the defenses, we discuss which root cause(s) and the
attack step(s) the defenses target. Eliminating any of the root causes,
exploited in a specific attack, in any of the attack steps can provide
protection. Table I show the different root causes for each attack, which can
be targeted by a defence.  We categorize defenses into groups, wherever
possible, in case there are similarities. In addition, we also describe the
protection level offered against the discussed attacks using the optimization
and the threat model targeted by the defense. Our goal is not to exhaustively
cover defenses against all possible attacks targeting a microarchitectural
optimization. Rather, it is to explore broad defense strategies, in which
attack step and root cause they can be applied and their limitations.

###  4.1 Defenses against Non-transient attacks

####  4.1.1 Cache

Defense | Res. | Attack step | Threat | P
---|---|---|---|---
|  | $A_{S}$ | $A_{I}$ | $A_{T}$ | $A_{R}$ | model |
disable clflush [188, 187] | $R_{SC}$ | D/S/I | - | - | - | 1,2,3 | $\LEFTcircle$
part.: [46, 73, 180, 115] | $R_{SC}$ | D/S/I | D/S/I | - | D/S/I | 1,2 | $\LEFTcircle$
[96, 179, 147, 153] | $R_{SC}$ | D/S/I | D/S/I | - | D/S/I | 1,2 | $\LEFTcircle$
part.: static [98, 30, 131] | $R_{SC}$ | D/S/I | D/S/I | - | D/S/I | 1,2 | $\CIRCLE$
rand. [117, 139, 166, 140] | $R_{SC}$ | D/I | D/I | - | D/I | 1,2 | $\LEFTcircle$
[164, 183] | $R_{SC}$ | D/I | D/I | - | D/I | 1,2 | $\LEFTcircle$
repl. [92, 143, 116, 180, 94, 47] | $R_{SC}$ | D/I | D/I | - | D/I | 1,2 | $\LEFTcircle$
const. time [24, 25, 43] | - | - | D/I | - | - | 1,2,3 | $\CIRCLE$

TABLE II: Defenses for attacks using the _SC_. Protection (P):
full$\CIRCLE$/partial$\LEFTcircle$.

Several defenses have been proposed for securing the shared cache against
side-channel attacks. We have classified the different defenses for the _SC_
based on the root cause(s) and attack step(s) they target, into five broad
categories, see Table II. Each row in the table shows which root causes are
restricted by the defence, in which attacks step using which
microarchitectural resource.

Disabling _clflush_ [188, 187] only addresses reuse-based attacks which
typically uses the instruction in the _setup_ step. This affects the three
root causes determinism, sharing and information flow primarily in the _setup_
step.

The defenses in the next category, partitioning (part.), target sharing and
information flow, in all the attack steps, by providing isolation between
processes/threads in the _SC_ state using partitioning [180, 115, 96, 179,
147, 153, 98, 30, 131, 130, 75, 73]. Partitioning can, in principle, provide
full protection against reuse-based, conflict-based and observation-based
attacks where victim and adversary share the _SC_ state. However, the defenses
provide different levels of protection depending on the level of isolation,
i.e., whether all or only some of the data is partitioned. For example, MI6
and IRONHIDE [131, 30] statically partition both _SC_ and DRAM and can thereby
enable full protection of the _SC_ , albeit at a comparatively higher
performance cost. In contrast, STEALTHMEM [96] only provides partial
protection for a limited number of cache lines per core, which are not allowed
to be evicted. This will lead to higher performance but also a lower
protection level, since the state of the unprotected cache lines are shared.

The next category, randomization (rand.), targets conflict-based attacks and
is typically achieved by modifying the mapping of addresses to sets in the
_SC_ [117, 139, 166, 140, 164, 183]. Randomization target determinism and
information flow. The strategy affects determinism by complicating the process
of creating an eviction-set needed to evict a target cache line at a specific
address. The change in mapping leads to limited information flow. This makes
randomization effective especially against conflict-based attacks. However, in
spite of defense, the _SC_ is still shared and insertions by the adversary can
result in evictions for the victim process and vice versa. This limits the
effectiveness against observation-based attacks since the working-set size of
an application can be observed and can be leveraged by attacks [55].

The category replacement-based defenses (repl.) – insertion and/or eviction –
leverage randomization to provide protection [92, 143, 116, 180, 94, 47].
These proposals mainly target determinism and information flow through the
_SC_ state. Specifically, through randomising insertion and/or eviction, the
_SC_ do not react in the same way under the same preconditions. Information
flow is limited by reducing/avoiding set conflicts, i.e., by preventing an
adversary from evicting data inserted by the victim. These defenses offer
protection but eventually leak information since determinism, sharing and
information flow in the _SC_ are not completely eliminated [163].

Lastly, constant-time programming paradigm [24, 25, 43] can be used to avoid
data-dependent implementations which affects determinism and information flow.
However, this is challenging to utilize in practice since it cannot be
generically applied.

####  4.1.2 Prefetching

Existing defenses to protect against prefetch-based attacks can be categorized
broadly into five groups, as shown in Table III. Disabling the prefetcher
[158, 1, 44, 40] impacts determinism, sharing, access violation and
information flow, in all the attack steps. This strategy is equally applicable
to attacks using HW- or SW-based prefetching. However, the performance cost
can be high since prefetching can provide significant speedups.

The defense in the second group, by Gruss et al. [67], propose introducing
privilege checks on prefetch instructions. This would cause a segmentation
fault when there is an attempt to prefetch kernel data. This prevents access
violation in the _interact_ step and affect all SW- and HW-based attacks that
exploit the lack of permission checks [175, 146, 40, 67, 1].

Defense | Res. | Attack step | Threat | P
---|---|---|---|---
|  | $A_{S}$ | $A_{I}$ | $A_{T}$ | $A_{R}$ | model |
disable [158, 1, 44, 40] | $R_{Pref.}$ | D/S/I | D/S/A/I | - | D/S/A/I | 1,2,3 | $\CIRCLE$
privilege checks [67] | $R_{Pref.}$ | - | A | - | A | 1,2,3 | $\LEFTcircle$
kernel/user isol. [65] | $R_{TLB}$ | - | S/A/I | - | - | 2 | $\LEFTcircle$
flush [40, 44] | $R_{Pref.}$ | I | I | - | I | 2 | $\LEFTcircle$
replicate [40, 44] | $R_{Pref.}$ | S/I | S/I | - | S/I | 2 | $\LEFTcircle$
const. time [158, 60, 25, 43] | - | - | D/I | - | - | 1,2,3 | $\LEFTcircle$
_SC_ defenses | $R_{SC}$ | D/S/I | - | - | D/S/I | 1,2,3 | $\LEFTcircle$

TABLE III: Defenses for attacks using the prefetcher.

Another strategy is to provide stronger isolation between kernel and user-
space to protect against attacks that leverage the lack of permission checks
[65]. This approach has been adopted in both Linux [57] and Windows [91]. This
would provide protection against SW-based attacks using the prefetch
instruction [67, 1] and against HW-based attacks [175, 146, 40]. This approach
restricts sharing and information flow through the page tables (and TLB), in
the _interact_ step of the attack.

The next group of defenses target attacks that exploit the state of HW-based
prefetchers (prefetch tables). Specifically, these defenses replicate and
flush prefetcher state at context switches [40, 44]. This ensures that state
is no longer shared across context switches which restricts sharing and
information flow. This only affects the HW-based attacks which rely on _MS_ in
the prefetcher. Furthermore, the threat model targeted is limited to
_SameThread_ since the technique does not affect concurrently executing SMT
threads sharing prefetcher state.

Another strategy is to change the SW implementation to ensure that any
prefetch activity is not dependent on any secret. This would affect the
attacks relying on data-dependent execution paths and observing prefetch
patterns [158, 74, 40]. This can be achieved using constant-time programming
practices [158, 24], for example rewriting table based look-ups to be immune
to prefetches [158, 60]. This strategy affects determinism and information
flow and can theoretically protect against attacks that exploit prefetch
patterns. However, it is challenging to implement this broadly in practice.

Lastly, it should be noted that some of the attacks rely on the shared state
of the _SC_ [158, 40, 74, 175, 67]. The defenses proposed for the _SC_ could
be used to defend against these attacks as well.

####  4.1.3 Branch prediction

Defense | Resource | Attack step | Threat | P
---|---|---|---|---
|  | $A_{S}$ | $A_{I}$ | $A_{T}$ | $A_{R}$ | model |
if-conversion[41, 51] | - | D/S/I | D/S/I | - | D/S/I | 2,3 | $\CIRCLE$
enc.: [192, 108] |  $R_{BTB}$/$R_{PHT}$ | D/I | D/I | - | D/I | 2,3 | $\LEFTcircle$
[62, 50, 193] |  $R_{BTB}$/$R_{PHT}$ | D/I | D/I | - | D/I | 2,3 | $\LEFTcircle$
flush [177, 193] |  $R_{BTB}$/$R_{PHT}$/$R_{BHB}$ | I | I | - | I | 2 | $\CIRCLE$
part. [177, 193] |  $R_{BTB}$/$R_{PHT}$ | S/I | S/I | - | S/I | 2 | $\LEFTcircle$
rand. [191, 81] |  $R_{BTB}$/$R_{PHT}$ | D | D | - | D | 2,3 | $\LEFTcircle$

TABLE IV: Defenses for attacks using the branch predictor.

The defenses against branch prediction based attacks can be grouped into five
categories, see Table IV. The first group relies on SW-based techniques, as
if-conversion, where the compiler restructures code to avoid conditional
branches and use predication instead [41]. This restricts determinism, sharing
and information flow since branching is avoided and is akin to disabling the
direction prediction. However, the applicability to real-world code with
complex control flow is limited [51]. Furthermore, highly predictable branches
have been shown to perform poorly when if-converted [41].

The next category of defenses use randomization to thwart attacks.
Specifically, encryption of the _BTB_ /_BTB_ have been proposed [192, 108, 62,
50] to prevent the adversary from easily manipulating the branch prediction
logic. Encryption restricts determinism and information flow, in all the steps
of the attack. Determinism is affected in the _setup_ step because the target
is encrypted which makes manipulating collisions difficult. Information flow
is also hindered since a process can only access correct entries in the
presence of a valid key. The limitation of these encryption-based solutions is
that they cannot guarantee protection against brute-force approaches.

Defenses in the next category flush the state of the branch predictor i.e.
_BTB_ /_BTB_ /_BHB_ , on context switches [177, 193]. This would affect
information flow in the context of the _SameThread_ threat model. However, the
performance overhead is usually high [177] and the effectiveness is restricted
to the _SameThread_ model.

Partitioning has been shown to thwart attacks on the branch predictor [51,
193]. Partitioning affects sharing and information flow, in all the steps of
the attack, since the state of the _BTB_ /_BTB_ is isolated. HyBP [193]
combines isolation and encryption, and selectively replicates parts of the
predictor state, while using encryption for the larger tables. The focus of
these proposals is to use partitioning/replication to avoid the high
performance cost of flushing the entire branch prediction state upon a context
switch. Replicating the entire prediction state among SMT threads, although a
possibility, is prohibitively expensive.

The last category makes the state transition of the predictor probabilistic,
by affecting the saturating counters, as proposed by Zhao et al.[191]. This
defense restricts determinism in all the steps of the attack. However, the
protection offered by the technique is limited since an adversary, through
repeated measurements, can eventually infer the secret from the state of the
branch predictor.

####  4.1.4 Computational simplification

Defense | Resource | Attack step | Threat | P
---|---|---|---|---
|  | $A_{S}$ | $A_{I}$ | $A_{T}$ | $A_{R}$ | model |
disable [63, 43] |  $R_{MUL}$/$R_{FPU}$ | - | D | - | - | 2,3 | $\CIRCLE$
const. time: [43, 63, 17] |  $R_{MUL}$/$R_{FPU}$ | - | D | - | - | 2,3 | $\LEFTcircle$
[16, 24, 25, 142] |  $R_{MUL}$/$R_{FPU}$ | - | D | - | - | 2,3 | $\LEFTcircle$

TABLE V: Defenses for attacks using comp. simplification.

Two broad strategies have been proposed for protecting against attacks using
computational simplification, see Table V. One strategy is to selectively
disable the optimization for parts of the program which accesses sensitive
information [63, 43]. Disabling restricts determinism in the _interact_ step.

The other strategy is to change the implementation to avoid any data-dependent
timing variations, even for computational simplification. This strategy
targets determinism in the _interact_ step. One way to achieve data-
independent implementation is to use constant-time programming practices [16,
43, 24, 25]. In [16] a FP library (LibFTFP) is shown, providing a fixed-point
data type with all library operations executing in constant time.

Lastly, in the case of the browser-based attack [16] the SW-construct which
enables the sharing and information flow, can be disabled i.e. cross-origin
SVG-filters [102].

###  4.2 Defenses against Transient Attacks

Defense | Resource | Attack step | Threat | P
---|---|---|---|---
|  | $A_{S}$ | $A_{I}$ | $A_{T}$ | $A_{R}$ | model |
local: BPU |  $R_{BTB}$/$R_{PHT}$ | D/S/I | - | - | - | 2,3 | $\LEFTcircle$
_SC_ | $R_{SC}$ | D/S/I | - | - | D/S/I | 1,2 | $\LEFTcircle$
disable: IBPB [12], sb [18] |  $R_{BTB}$/$R_{PHT}$ | D/S/I | - | - | - | 1,2,3 | $\LEFTcircle$
SSBD [13, 12] | $R_{STL}$ | D/S/I | - | - | - | 1,2,3 | $\LEFTcircle$
SMT [59, 107, 76] | - | D/S/I | D/S/I | - | D/S/I | 3 | $\CIRCLE$
restrict: IBRS,STIBP [14, 12] |  $R_{BTB}$/$R_{PHT}$ | D/S/I | - | - | - | 1,2,3 | $\LEFTcircle$
retpoline [87, 15] | $R_{RSB}$ | I | - | - | - | 1,2,3 | $\LEFTcircle$
randpoline [31] | $R_{RSB}$ | D | - | - | - | 1,2,3 | $\LEFTcircle$
 _lfence_ , serial. [12] | - | - | D/I | - | - | 1,2,3 | $\LEFTcircle$
fence: [165, 174, 105] | $R_{\mu OP\\_Q}$ | - | D/I | - | - | 1,2,3 | $\LEFTcircle$
[157, 36, 129] | - | - | D/I | - | - | 1,2,3 | $\LEFTcircle$
delay: [181, 19, 148, 53] |  $R_{ROB}$, $R_{reg.}$ | - | D/I/A | - | - | 1,2,3 | $\LEFTcircle$
[190, 32] |  $R_{ROB}$, $R_{reg.}$ | - | D/I/A | - | - | 1,2,3 | $\LEFTcircle$
[110, 119, 145] |  $R_{ROB}$, $R_{reg.}$ | - | - | D/I | - | 1,2,3 | $\LEFTcircle$
rollback [144] | $R_{SC}$ | - | - | D/I | D/I | 1,2 | $\LEFTcircle$
isolate: [186, 95, 9, 8] |  $R_{buf.}$/$R_{L0}$ | - | - | D/S/I | - | 2 | $\LEFTcircle$

TABLE VI: Classification of defenses for transient attacks.

We describe defenses for transient execution attacks, where we first discuss
defenses for speculation-based attacks, and then defenses for exception-based
attacks.

####  4.2.1 Defenses against Speculation-based Attacks

The defenses against speculation-based attacks can be broadly grouped into
four high-level categories based on the defense strategy: localized defenses,
disabling defenses, restriction defenses and isolation defenses, see Table VI.

Localized defenses leverage the defenses available for individual
optimizations/resources that interact with speculative execution, such as the
BP and/or _SC_. Branch prediction can be targeted in the _setup_ step to stop
the adversary from being able to (mis)train the predictor, see Section 4.1.3.
The defense is only applicable for the attacks which uses the specific
predictor resource. Another approach is to target the side-channel that
permits information flow across protection domain through transient execution.
In most attacks the _SC_ is used since it can offer the highest bandwidth,
which makes the defenses in Section 4.1.1 applicable. However, studies have
demonstrated that a large variety of microarchitectural resources can be used,
such as execution units, ports, _PHT_ , _MSHR_ etc. This is a challenge
because multiple resources may need to be protected, since they can all act as
potential side-channels. By defending the resource which enables the easily
accessible (high bandwidth and low noise) side-channels, the attack bandwidth
can be reduced. In addition, limiting the threat model (for instance to
_CrossCore_) can restrict the number of resources which can be used as side-
channels.

The second category involves disabling the optimization. This approach has
been proposed in specific scenarios where other defenses are not applicable.
Support for disabling indirect branch predictions using a barrier, Indirect
Branch Predictor Barrier (IBPB) [14, 12], has been adopted in commodity HW.
Likewise, to thwart Spectre v4 attack, the STL mechanism can also be disabled
using Speculative Store Bypass Disable (SSBD) microcode updates from Intel and
AMD [13, 12]. These techniques affect the root causes determinism, sharing and
information flow in the predictor, in all the steps where it is used. However,
the performance cost is potentially high since the predictions are restricted.
Another defensive measure is to limit the threat model by disabling SMT [59,
107, 76]. However, disabling SMT comes at a potentially high performance cost.

The third category is restriction-based defences. Here, the high-level idea is
to restrict the speculative execution, selectively, to avoid the attacks.
Speculation restriction can be performed in the different steps of the attack
and using different mechanisms in HW and/or SW. One HW mechanism, adopted in
commodity HW to avoid (mis)training, is Indirect Branch Restricted Speculation
(IBRS) [14, 12], which affects the _setup_ step. Using IBRS restricts the
training of indirect targets inside an enclave. Likewise, using Thread
Indirect Branch Prediction (STIBP) restricts the use of prediction entries
trained in another SMT thread. Speculative execution have also been restricted
using micro-code updates [86]. SW-based defenses [87, 31, 15] also aim to
restrict speculation by avoiding the state transition _MS I_$\rightarrow$_MS
P_, and preventing the speculation triggered by the the branch prediction.
Here, the (exploitable) indirect branch is replaced by a different retpoline
sequence. This will cause the misspeculated code to execute a controlled loop
sequence until speculation has been resolved. To lower the performance cost of
the technique both a probabilistic variant, randpoline [31], and a HW variant
[15] have been proposed. The root cause exploited is information flow. A
recent paper, RETBLEED [184], have shown that the retpoline strategy only
provides partial protection, since it can be circumvented using manipulation
of return instructions.

Another mechanism to restrict speculation is to introduce fences to limit
transient execution. Many existing attack mitigations use the serializing
_lfence_ instruction before sensitive parts of the code. In order to improve
the usability and performance cost, defenses have been proposed which
selectively and automatically choose when to use fences, either in SW [165,
157, 174, 105] or in HW [165]. For example Shen et al. [157] split code into
small blocks and insert fences between the entry point and a potentially
leaking memory access to defend against Spectre attacks. The root causes
affected are determinism and information flow, depending on the solution.
Another example is Context-Sensitive Fencing (CSF) [165] which uses customized
decoding from instructions to micro-ops to insert fences after a conditional
branch instruction and before a subsequent load instruction. The root causes
affected by fences are determinism and information flow, in the _interact_
step. Another way similar to fences is Speculative Load Hardening (SLH) [36] a
compiler-level technique where the idea is to introduce a data dependency on
the condition, in order to guarantee that the control flow is valid. The
technique is supported in LLVM and GCC [48]. Oleksenko et al. [129] restrict
speculation by introducing a data dependency in order to guarantee that a load
will only start if the comparison is in registers or L1 cache. However, the
technique is only effective if the load is performed after the comparison.

Another method to restrict speculations is to wait for authorization or until
data is no longer transient [181, 53, 148, 110, 145, 119, 32] which affect the
execution in the _interact_ and/or _transmit_ steps. Here, the defenses delay
to avoid the access violation which leads to leakage (in _interact_) or stall
the load which would update _MS_ of _SC_ (in _transmit_). For example NDA
(Non-speculative Data Access) [181] provide different policies for controlling
control flow and data propagation in _interact_. The root causes affected are
determinism, sharing and information flow. SpectreGuard [53] also affects the
_interact_ step and proposes to mark secret data and selectively restrict
speculation only for data from sensitive pages. These defences affect the root
cause determinism, access violation and/or information flow in the _interact_
step. CondSpec [110] affects _transmit_ by handling loads differently, a load
that hits in the _SC_ can read the data and complete its execution while a
load that experience a cache miss will be stalled and re-issued later. This
affects the root cause access violation and/or information flow. CleanUpSpec
[144], on the contrary, restricts how speculative updates are encoded in the
_MS_ of the _SC_. Speculative accesses are allowed to progress and make
changes to the _SC_ but these are removed in case of miss-speculation. This
has been shown to be insufficient in certain conditions [22]. This defense
affects the root causes determinism and information flow, in the _transmit_
and _receive_ step of the attack.

The performance cost of the restriction-based defenses depends on how
restrictive the rule set is, i.e., how much execution differs from the
unconstrained speculation scenario. Introducing protections at a later attack
step generally leads to more flexibility, since more speculation can be
allowed, and comes at a lower performance cost [82]. The trade-off is that
more possible side-channels can be used for the state transitions _MS
I_$\rightarrow$_MS T_ and _MS T_$\rightarrow$_MS R_, which makes ensuring full
protection challenging.

The last category targets isolation by introducing a shadow structure to hold
the speculative _MS_ until it is deemed safe [186, 95, 9, 8]. For example, in
MounTrap [9] an L0 filter cache is used for speculative data, which is only
allowed to propagate to the rest of the cache hierarchy after commit. This
allows the speculation and potential access violation to occur but not affect
_MS_ of the _SC_ , for example. This restricts information flow from the
transient execution to the non-transient execution.

####  4.2.2 Defenses against Exception-based Attacks

Exception-based attacks typically exploit implementation oversights in HW. The
Meltdown attack exploits a race condition between authorization and access
[77] which enables transient execution to continue with an unauthorized value,
leading to access violation. Newer CPUs contain patches whereas existing ones
are mostly protected through microcode updates or other workarounds [33]. For
instance, the issue has been addressed on newer Intel microarchitectures [12],
Whiskey Lake and onward, by returning zero when accessing privileged memory
[34]. In the case of the MDS-attacks the leaks is attributed to a use-after-
free vulnerability where stale data is read in the internal registers [149],
allowing unintended information flow through shared CPU buffers. The issue is
solved by flushing the internal buffers to restrict the information flow.
Similarly, to defend against LazyFP, FPU registers are flushed on context
switches when changing protection domains with SGX, for hypervisors and for
logical cores. In addition, since Linux 4.6 eager FPU switching is used by
default [120]. This disables the fault since the FPU is always available.
Foreshadow has been mitigated on Intel CPUs through setting a physical page
number field of unmapped page-tables to refer to non-existing physical memory
[85, 182], thereby restricting access violation. The LVI attacks [171] are no
longer possible when the corresponding fault or microcode assist is mitigated.

Another defense strategy is to provide stronger address space isolation [65,
56, 84, 103], which mitigates or limits the possible access violation in the
attacks. For example MemoryRanger [103] isolates drivers, kernel and user
space into separate address spaces using Extended Page Table (EPT). This
defense restricts access violation in the _interact_ step, by providing
isolation.

###  4.3 System-level defenses

Broader system-level strategies for providing protection have also been
proposed. Leveraging constant-time programming paradigm is one such strategy
where the key idea is to rewrite the SW-implementation to avoid timing
variability. The challenge with constant-time programming is to provide
protection for all types of attacks. Another strategy is to decrease the
accuracy of timing measurement [83, 122, 101, 42].  This strategy affects
determinism in the _receive_ step, and can be used as a defense against
several attacks on different optimizations. The strategy leads to lower attack
bandwidth but has been shown to be ineffective in providing complete
protection since many attacks can amplify the timing difference [124] or use
other timer mechanisms [150]. Another strategy is to use formal models [38,
70, 77, 71, 127] in order to automatically synthesize vulnerabilities. This
strategy could potentially find all exploitable scenarios in the design phase
itself. However, identifying all vulnerabilities complicate the model building
process and current proposals therefore only target a limited set. Finally,
leveraging programming language based security [106] is another option wherein
defenses are co-designed leveraging programming language annotations to mark
sensitive parts of the programs, along with suitable HW primitives. However, a
recent analysis performed by Naseredini et al. [128] found that most
programming languages and their execution environments does not have support
for Spectre mitigations. This shows the challenge of relying on programming
languages and execution environments to provide complete protection.

##  5 Discussion

Commonalities: We have shown that the root causes that enable the attacks are
common, across a wide range of microarchitectural optimizations. Furthermore,
through our analysis of the proposed defenses, we have shown that these target
one or more root cause, across the different steps of an attack. There are
commonalities even in the defense strategies used to protect against attacks
on these diverse microarchitectural optimizations. Some of those include
disabling the optimization, to restrict all the root causes; isolating the
state related to the optimization, to restrict sharing; applying randomization
and/or restriction, to limit information flow and introducing permission
checks, to limit resources from, exposing/accessing state outside of the
intended domain.

Using these common strategies together with the root causes, enable us to
envision new defenses for vulnerable microarchitectural optimizations. We
apply these common strategies to defend against potential attacks exploiting
value prediction (Section 3.3). Possible defenses against those attacks could
involve flushing the table at context switches, isolating and/or partitioning
the table to avoid conflict and reuse-based attacks, introducing randomization
to limit information flow. Another option could involve introducing non-
determinism in the value prediction mechanisms. Lastly, the simplest
mitigation would be to provide mechanisms to selectively disable the
optimization when running sensitive parts of the program.

Observations: Firstly, the ease of exploiting a microarchitectural
optimization and the severity of the leak vary widely. There exist limiting
factors which are not easy to quantify, such as the availability and
capabilities of gadgets in the victim code [35]. The link between attack
bandwidth and effectiveness in practical scenarios is also difficult to
quantify.

Secondly, we observe that, in several cases, vulnerabilities are not due to
the fundamental behaviour of the microarchitectural optimization but are
rather a result of design and/or implementation. This points in the direction
of promoting a deeper understanding of the root causes of vulnerabilities and
the potential defense strategies in the design and implementation phases,
which we hope can be assisted by our framework, rather than as an
afterthought. We believe that microarchitectural optimizations can still be a
promising avenue to provide performance scalability in future technology nodes
without having to compromise on security.

Future work: Our focus, in this paper, has been on vulnerabilities in
microarchitectural optimizations that target performance. We have not
exhaustively covered all microarchitectural optimizations and/or resources,
for example the NoC and DRAM. However, we expect our framework to be easily
extended to cover attacks and defenses on other optimizations and resources.
We have not focused on SW vulnerabilities, such as buffer overflows, which
poses considerable security risks. Furthermore, we have not investigated
microarchitectural optimizations for security, such as Intel SGX, nor power-
based side channel attacks nor performance degradation attacks [64, 21, 11,
10]. Investigating and/or extending the root cause framework to include
optimizations for security and considering power-side channels is left for
future work.

##  6 Conclusions

We identify four root causes that enable timing-based side-channel attacks on
an extensive set of microarchitectural optimizations. We provide a framework
and systematize both transient and non-transient attacks and defenses,
highlighting the similarities and differences. Based on our analysis we
discuss potential attacks and defenses for vulnerable optimizations. We
believe our framework can assist computer architects in understanding the
landscape of attacks and defenses, and to provide guidance in designing secure
microarchitectural optimizations.

## References

  * [1] AMD prefetch attacks through power and time.  In 31st USENIX Security Symposium (USENIX Security 22), Boston, MA, August 2022. USENIX Association.
  * [2] SecSMT: Securing SMT processors against Contention-Based covert channels.  In 31st USENIX Security Symposium (USENIX Security 22), Boston, MA, August 2022. USENIX Association.
  * [3] TLB;DR: Enhancing TLB-based attacks with TLB desynchronized reverse engineering.  In 31st USENIX Security Symposium (USENIX Security 22), Boston, MA, August 2022. USENIX Association.
  * [4] Onur Aciiçmez, Çetin Kaya Koç, and Jean-Pierre Seifert.  On the power of simple branch prediction analysis.  In Proceedings of the 2nd ACM Symposium on Information, Computer and Communications Security, ASIACCS ’07, page 312–320, New York, NY, USA, 2007\. Association for Computing Machinery.
  * [5] Onur Acıiçmez, Çetin Kaya Koç, and Jean-Pierre Seifert.  Predicting secret keys via branch prediction.  In Proceedings of the 7th Cryptographers’ Track at the RSA Conference on Topics in Cryptology, CT-RSA’07, page 225–242, Berlin, Heidelberg, 2007. Springer-Verlag.
  * [6] Onur Acıiçmez, Shay Gueron, and Jean-Pierre Seifert.  New branch prediction vulnerabilities in openssl and necessary software countermeasures.  In Steven D. Galbraith, editor, Cryptography and Coding, pages 185–203, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.
  * [7] Pavlos Aimoniotis, Christos Sakalis, Magnus Själander, and Stefanos Kaxiras.  Reorder buffer contention: A forward speculative interference attack for speculation invariant instructions.  IEEE Computer Architecture Letters, 20(2):162–165, 2021.
  * [8] Sam Ainsworth.  Ghostminion: A strictness-ordered cache system for spectre mitigation.  In MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture, MICRO ’21, page 592–606, New York, NY, USA, 2021. Association for Computing Machinery.
  * [9] Sam Ainsworth and Timothy M. Jones.  Muontrap: Preventing cross-domain spectre-like attacks by capturing speculative state.  In Proceedings of the ACM/IEEE 47th Annual International Symposium on Computer Architecture, ISCA ’20, page 132–144. IEEE Press, 2020\.
  * [10] Alejandro Cabrera Aldaya and Billy Bob Brumley.  Hyperdegrade: From ghz to mhz effective cpu frequencies, 2021.
  * [11] Thomas Allan, Billy Bob Brumley, Katrina Falkner, Joop van de Pol, and Yuval Yarom.  Amplifying side channels through performance degradation.  In Proceedings of the 32nd Annual Conference on Computer Security Applications, ACSAC ’16, page 422–435, New York, NY, USA, 2016. Association for Computing Machinery.
  * [12] AMD.  Speculative execution side channel mitigations, 2018, 2018.
  * [13] AMD.  Amd speculative bypass store disable, technical report, 2022.
  * [14] AMD.  Software techniques for managing speculation on amd processors, 2022, 2022\.
  * [15] Nadav Amit, Fred Jacobs, and Michael Wei.  $\\{$JumpSwitches$\\}$: Restoring the performance of indirect branches in the era of spectre.  In 2019 USENIX Annual Technical Conference (USENIX ATC 19), pages 285–300, 2019.
  * [16] Marc Andrysco, David Kohlbrenner, Keaton Mowery, Ranjit Jhala, Sorin Lerner, and Hovav Shacham.  On subnormal floating point and abnormal timing.  In 2015 IEEE Symposium on Security and Privacy, pages 623–639, 2015\.
  * [17] Marc Andrysco, Andres Nötzli, Fraser Brown, Ranjit Jhala, and Deian Stefan.  Towards verified, constant-time floating point operations.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS ’18, page 1369–1382, New York, NY, USA, 2018. Association for Computing Machinery.
  * [18] ARM.  Arm architecture reference manual armv8, 2018, 2018.
  * [19] Kristin Barber, Anys Bacha, Li Zhou, Yinqian Zhang, and Radu Teodorescu.  Specshield: Shielding speculative data from microarchitectural covert channels.  In 2019 28th International Conference on Parallel Architectures and Compilation Techniques (PACT), pages 151–164, 2019.
  * [20] Enrico Barberis, Pietro Frigo, Marius Muench, Herbert Bos, and Cristiano Giuffrida.  Branch history injection: On the effectiveness of hardware mitigations against Cross-Privilege spectre-v2 attacks.  In 31st USENIX Security Symposium (USENIX Security 22), pages 971–988, Boston, MA, August 2022. USENIX Association.
  * [21] Michael G Bechtel and Heechul Yun.  Denial-of-service attacks on shared cache in multicore: Analysis and prevention, 2019.
  * [22] Mohammad Behnia, Prateek Sahu, Riccardo Paccagnella, Jiyong Yu, Zirui Neil Zhao, Xiang Zou, Thomas Unterluggauer, Josep Torrellas, Carlos Rozas, Adam Morrison, Frank Mckeen, Fangfei Liu, Ron Gabor, Christopher W. Fletcher, Abhishek Basak, and Alaa Alameldeen.  Speculative interference attacks: Breaking invisible speculation schemes.  In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS 2021, page 1046–1060, New York, NY, USA, 2021. Association for Computing Machinery.
  * [23] Daniel J. Bernstein.  Cache-timing attacks on aes.  2005\.
  * [24] Daniel J. Bernstein.  The poly1305-aes message-authentication code.  In Henri Gilbert and Helena Handschuh, editors, Fast Software Encryption, pages 32–49, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg.
  * [25] Daniel J. Bernstein.  Curve25519: New diffie-hellman speed records.  In Moti Yung, Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, editors, Public Key Cryptography - PKC 2006, pages 207–228, Berlin, Heidelberg, 2006. Springer Berlin Heidelberg.
  * [26] Atri Bhattacharyya, Alexandra Sandulescu, Matthias Neugschwandtner, Alessandro Sorniotti, Babak Falsafi, Mathias Payer, and Anil Kurmus.  Smotherspectre: Exploiting speculative execution through port contention.  In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS ’19, page 785–800, New York, NY, USA, 2019. Association for Computing Machinery.
  * [27] Rahul Bodduna, Vinod Ganesan, Patanjali SLPSK, Kamakoti Veezhinathan, and Chester Rebeiro.  Brutus: Refuting the security claims of the cache timing randomization countermeasure proposed in ceaser.  IEEE Computer Architecture Letters, 19(1):9–12, 2020.
  * [28] Pietro Borrello, Andreas Kogler, Martin Schwarzl, Moritz Lipp, Daniel Gruss, and Michael Schwarz.  ÆPIC leak: Architecturally leaking uninitialized data from the microarchitecture.  In 31st USENIX Security Symposium (USENIX Security 22), pages 3917–3934, Boston, MA, August 2022. USENIX Association.
  * [29] Thomas Bourgeat, Jules Drean, Yuheng Yang, Lillian Tsai, Joel Emer, and Mengjia Yan.  Casa: End-to-end quantitative security analysis of randomly mapped caches.  In 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 1110–1123, 2020.
  * [30] Thomas Bourgeat, Ilia Lebedev, Andrew Wright, Sizhuo Zhang, Arvind, and Srinivas Devadas.  Mi6: Secure enclaves in a speculative out-of-order processor.  In Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture, MICRO ’52, page 42–56, New York, NY, USA, 2019\. Association for Computing Machinery.
  * [31] Rodrigo Branco, Kekai Hu, Ke Sun, and Henrique Kawakami.  Efficient mitigation of side-channel based attacks against speculative execution processing architectures, September 14 2021.  US Patent 11,119,784.
  * [32] Gianpiero Cabodi, Paolo Camurati, Fabrizio Finocchiaro, and Danilo Vendraminetto.  Model checking speculation-dependent security properties: Abstracting and reducing processor models for sound and complete verification.  In Claude Carlet, Sylvain Guilley, Abderrahmane Nitaj, and El Mamoun Souidi, editors, Codes, Cryptology and Information Security, pages 462–479, Cham, 2019. Springer International Publishing.
  * [33] Claudio Canella, Sai Manoj Pudukotai Dinakarrao, Daniel Gruss, and Khaled N. Khasawneh.  Evolution of defenses against transient-execution attacks.  In Proceedings of the 2020 on Great Lakes Symposium on VLSI, GLSVLSI ’20, page 169–174, New York, NY, USA, 2020. Association for Computing Machinery.
  * [34] Claudio Canella, Michael Schwarz, Martin Haubenwallner, Martin Schwarzl, and Daniel Gruss.  Kaslr: Break it, fix it, repeat.  In Proceedings of the 15th ACM Asia Conference on Computer and Communications Security, ASIA CCS ’20, page 481–493, New York, NY, USA, 2020\. Association for Computing Machinery.
  * [35] 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 Proceedings of the 28th USENIX Conference on Security Symposium, SEC’19, page 249–266, USA, 2019. USENIX Association.
  * [36] Chandler Carruth.  Rfc: Speculative load hardening (a spectre variant1 mitigation), 2018, 2018.
  * [37] Sunjay Cauligi, Craig Disselkoen, Daniel Moghimi, Gilles Barthe, and Deian Stefan.  Sok: Practical foundations for software spectre defenses, 2021.
  * [38] Kevin Cheang, Cameron Rasmussen, Sanjit Seshia, and Pramod Subramanyan.  A formal approach to secure speculation.  In 2019 IEEE 32nd Computer Security Foundations Symposium (CSF), pages 288–28815, 2019.
  * [39] Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, and Ten H. Lai.  Sgxpectre: Stealing intel secrets from sgx enclaves via speculative execution.  In 2019 IEEE European Symposium on Security and Privacy (EuroS P), pages 142–157, 2019.
  * [40] Yun Chen, Lingfeng Pei, and Trevor E. Carlson.  Leaking control flow information via the hardware prefetcher, 2021.
  * [41] Youngsoo Choi, Allan Knies, Luke Gerke, and Tin-Fook Ngai.  The impact of if-conversion and branch prediction on program execution on the intel® itanium™ processor.  In Proceedings of the 34th Annual ACM/IEEE International Symposium on Microarchitecture, MICRO 34, page 182–191, USA, 2001. IEEE Computer Society.
  * [42] Jack Cook, Jules Drean, Jonathan Behrens, and Mengjia Yan.  There’s always a bigger fish: A clarifying analysis of a machine-learning-assisted side-channel attack.  In Proceedings of the 49th Annual International Symposium on Computer Architecture, ISCA ’22, page 204–217, New York, NY, USA, 2022. Association for Computing Machinery.
  * [43] Bart Coppens, Ingrid Verbauwhede, Koen De Bosschere, and Bjorn De Sutter.  Practical mitigations for timing-based side-channel attacks on modern x86 processors.  In 2009 30th IEEE Symposium on Security and Privacy, pages 45–60, 2009.
  * [44] Patrick Cronin and Chengmo Yang.  A fetching tale: Covert communication with the hardware prefetcher.  In 2019 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pages 101–110, 2019.
  * [45] Miles Dai, Riccardo Paccagnella, Miguel Gomez-Garcia, John McCalpin, and Mengjia Yan.  Don’t mesh around: Side-Channel attacks and mitigations on mesh interconnects.  In 31st USENIX Security Symposium (USENIX Security 22), pages 2857–2874, Boston, MA, August 2022. USENIX Association.
  * [46] Ghada Dessouky, Tommaso Frassetto, and Ahmad-Reza Sadeghi.  HYBCACHE: Hybrid Side-Channel-Resilient Caches for Trusted Execution Environments.  USENIX Association, USA, 2020.
  * [47] Leonid Domnitser, Aamer Jaleel, Jason Loew, Nael Abu-Ghazaleh, and Dmitry Ponomarev.  Non-monopolizable caches: Low-complexity mitigation of cache side channel attacks.  ACM Trans. Archit. Code Optim., 8(4), January 2012.
  * [48] R Earnshaw.  Mitigation against unsafe data speculation (cve-2017-5753, 2018.
  * [49] Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh.  Jump over aslr: Attacking branch predictors to bypass aslr.  In 2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 1–13, 2016.
  * [50] Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh.  Understanding and mitigating covert channels through branch predictors.  ACM Trans. Archit. Code Optim., 13(1), mar 2016.
  * [51] Dmitry Evtyushkin, Ryan Riley, Nael CSE Abu-Ghazaleh, ECE, and Dmitry Ponomarev.  Branchscope: A new side-channel attack on directional branch predictor.  SIGPLAN Not., 53(2):693–707, mar 2018.
  * [52] Jacob Fustos, Michael Bechtel, and Heechul Yun.  Spectrerewind: Leaking secrets to past instructions.  In Proceedings of the 4th ACM Workshop on Attacks and Solutions in Hardware Security, ASHES’20, page 117–126, New York, NY, USA, 2020. Association for Computing Machinery.
  * [53] Jacob Fustos, Farzad Farshchi, and Heechul Yun.  Spectreguard: An efficient data-centric defense mechanism against spectre attacks.  In 2019 56th ACM/IEEE Design Automation Conference (DAC), pages 1–6, 2019.
  * [54] Qian Ge, Yuval Yarom, David Cock, and Gernot Heiser.  A survey of microarchitectural timing attacks and countermeasures on contemporary hardware.  J. Cryptogr. Eng., 8(1):1–27, 2018.
  * [55] Daniel Genkin, William Kosasih, Fangfei Liu, Anna Trikalinou, Thomas Unterluggauer, and Yuval Yarom.  Cachefx: A framework for evaluating cache security, 2022.
  * [56] David Gens, Orlando Arias, Dean Sullivan, Christopher Liebchen, Yier Jin, and Ahmad-Reza Sadeghi.  Lazarus: Practical side-channel resilient kernel-space randomization.  In Marc Dacier, Michael Bailey, Michalis Polychronakis, and Manos Antonakakis, editors, Research in Attacks, Intrusions, and Defenses, pages 238–258, Cham, 2017. Springer International Publishing.
  * [57] Thomas Gleixner.  x86/kpti: Kernel page table isolation (was kaiser), 2017, 2017.
  * [58] Enes Göktas, Kaveh Razavi, Georgios Portokalidis, Herbert Bos, and Cristiano Giuffrida.  Speculative Probing: Hacking Blind in the Spectre Era, page 1871–1885.  Association for Computing Machinery, New York, NY, USA, 2020.
  * [59] Google.  Product status: Microarchitectural data sampling (mds), 2022.
  * [60] Vinodh Gopal, James Guilford, Erdinç Öztürk, Wajdi Feghali, Gil Wolrich, and Martin Dixon.  Fast and constant-time implementation of modular exponentiation.  01 2009.
  * [61] Ben Gras, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida.  Translation leak-aside buffer: Defeating cache side-channel protections with TLB attacks.  In 27th USENIX Security Symposium (USENIX Security 18), pages 955–972, Baltimore, MD, August 2018. USENIX Association.
  * [62] Brian Grayson, Jeff Rupley, Gerald Zuraski Zuraski, Eric Quinnell, Daniel A. Jiménez, Tarun Nakra, Paul Kitchin, Ryan Hensley, Edward Brekelbaum, Vikas Sinha, and Ankit Ghiya.  Evolution of the samsung exynos cpu microarchitecture.  In 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA), pages 40–51, 2020.
  * [63] Johann Großschädl, Elisabeth Oswald, Dan Page, and Michael Tunstall.  Side-channel analysis of cryptographic software via early-terminating multiplications.  In Donghoon Lee and Seokhie Hong, editors, Information, Security and Cryptology – ICISC 2009, pages 176–192, Berlin, Heidelberg, 2010. Springer Berlin Heidelberg.
  * [64] D. Grunwald and S. Ghiasi.  Microarchitectural denial of service: insuring microarchitectural fairness.  In 35th Annual IEEE/ACM International Symposium on Microarchitecture, 2002. (MICRO-35). Proceedings., pages 409–418, 2002.
  * [65] Daniel Gruss, Moritz Lipp, Michael Schwarz, Richard Fellner, Clémentine Maurice, and Stefan Mangard.  Kaslr is dead: Long live kaslr.  In Eric Bodden, Mathias Payer, and Elias Athanasopoulos, editors, Engineering Secure Software and Systems, pages 161–176, Cham, 2017. Springer International Publishing.
  * [66] Daniel Gruss, Clémentine Maurice, Anders Fogh, Moritz Lipp, and Stefan Mangard.  Prefetch side-channel attacks: Bypassing smap and kernel aslr.  In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, page 368–379, New York, NY, USA, 2016. Association for Computing Machinery.
  * [67] Daniel Gruss, Clémentine Maurice, Anders Fogh, Moritz Lipp, and Stefan Mangard.  Prefetch side-channel attacks: Bypassing smap and kernel aslr.  In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, page 368–379, New York, NY, USA, 2016. Association for Computing Machinery.
  * [68] Daniel Gruss, Clémentine Maurice, Klaus Wagner, and Stefan Mangard.  Flush+flush: A fast and stealthy cache attack.  In Juan Caballero, Urko Zurutuza, and Ricardo J. Rodríguez, editors, Detection of Intrusions and Malware, and Vulnerability Assessment, pages 279–299, Cham, 2016. Springer International Publishing.
  * [69] Daniel Gruss, Raphael Spreitzer, and Stefan Mangard.  Cache template attacks: Automating attacks on inclusive Last-Level caches.  In 24th USENIX Security Symposium (USENIX Security 15), pages 897–912, Washington, D.C., August 2015. USENIX Association.
  * [70] Marco Guarnieri, Boris Köpf, José F. Morales, Jan Reineke, and Andrés Sánchez.  SPECTECTOR: principled detection of speculative information flows.  CoRR, abs/1812.08639, 2018.
  * [71] Marco Guarnieri, Boris Köpf, Jan Reineke, and Pepe Vila.  Hardware/software contracts for secure speculation.  In Proceedings of the 42nd IEEE Symposium on Security and Privacy, S&P 2021. IEEE, 2021.
  * [72] David Gullasch, Endre Bangerter, and Stephan Krenn.  Cache games – bringing access-based cache attacks on aes to practice.  In 2011 IEEE Symposium on Security and Privacy, pages 490–505, 2011\.
  * [73] Yanan Guo, Andrew Zigerelli, Youtao Zhang, and Jun Yang.  IVcache: Defending Cache Side Channel Attacks via Invisible Accesses, page 403–408.  Association for Computing Machinery, New York, NY, USA, 2021.
  * [74] Yanan Guo, Andrew Zigerelli, Youtao Zhang, and Jun Yang.  Adversarial prefetch: New cross-core cache side channel attacks.  In 2022 IEEE Symposium on Security and Privacy (SP), pages 1458–1473, 2022.
  * [75] S. Kariyappa Gururaj Saileshwar and Moinuddin Qureshi.  Bespoke cache enclaves: Fine-grained and scalable isolation from cache side-channels via flexible set-partitioning.  2021\.
  * [76] Red Hat.  Simultaneous multithreading in red hat enterprise linux, 2022.
  * [77] Zecheng He, Guangyuan Hu, and Ruby Lee.  New models for understanding and reasoning about speculative execution attacks, 2020.
  * [78] Zecheng He, Guangyuan Hu, and Ruby Lee.  New models for understanding and reasoning about speculative execution attacks.  In 2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA), pages 40–53, 2021.
  * [79] John L. Hennessy and David A. Patterson.  A new golden age for computer architecture.  Commun. ACM, 62(2):48–60, jan 2019.
  * [80] Mark D. Hill.  Technical perspective: Why ’correct’ computers can leak your information.  Commun. ACM, 63(7):92, jun 2020.
  * [81] Shohreh Hosseinzadeh, Hans Liljestrand, Ville Leppänen, and Andrew Paverd.  Mitigating branch-shadowing attacks on intel sgx using control flow randomization.  In Proceedings of the 3rd Workshop on System Software for Trusted Execution, SysTEX ’18, page 42–47, New York, NY, USA, 2018. Association for Computing Machinery.
  * [82] Guangyuan Hu, Zecheng He, and Ruby B. Lee.  Sok: Hardware defenses against speculative execution attacks.  In 2021 International Symposium on Secure and Private Execution Environment Design (SEED), pages 108–120, 2021.
  * [83] W.-M. Hu.  Reducing timing channels with fuzzy time.  In Proceedings. 1991 IEEE Computer Society Symposium on Research in Security and Privacy, pages 8–20, 1991.
  * [84] Zhichao Hua, Dong Du, Yubin Xia, Haibo Chen, and Binyu Zang.  EPTI: Efficient defence against meltdown attack for unpatched VMs.  In 2018 USENIX Annual Technical Conference (USENIX ATC 18), pages 255–266, Boston, MA, July 2018. USENIX Association.
  * [85] INTEL.  L1 terminal fault, 2018, 2018.
  * [86] INTEL.  Affected processors: Transient execution attacks & related security issues by cpu, 2022.
  * [87] Intel.  Retpoline: A branch target injection mitigation, technical report, 2022\.
  * [88] Gorka Irazoqui, Thomas Eisenbarth, and Berk Sunar.  S$a: A shared cache attack that works across cores and defies vm sandboxing – and its application to aes.  In 2015 IEEE Symposium on Security and Privacy, pages 591–604, 2015\.
  * [89] Gorka Irazoqui, Mehmet Sinan Inci, Thomas Eisenbarth, and Berk Sunar.  Wait a minute! a fast, cross-vm attack on aes.  In Angelos Stavrou, Herbert Bos, and Georgios Portokalidis, editors, Research in Attacks, Intrusions and Defenses, pages 299–319, Cham, 2014\. Springer International Publishing.
  * [90] Md Hafizul Islam Chowdhuryy, Hang Liu, and Fan Yao.  Branchspec: Information leakage attacks exploiting speculative branch instruction executions.  In 2020 IEEE 38th International Conference on Computer Design (ICCD), pages 529–536, 2020.
  * [91] Ken Johnson.  Kva shadow: Mitigating meltdown on windows, 2018, 2018.
  * [92] Mehmet Kayaalp, Khaled N. Khasawneh, Hodjat Asghari Esfeden, Jesse Elwell, Nael Abu-Ghazaleh, Dmitry Ponomarev, and Aamer Jaleel.  Ric: Relaxed inclusion caches for mitigating llc side-channel attacks.  In 2017 54th ACM/EDAC/IEEE Design Automation Conference (DAC), pages 1–6, 2017.
  * [93] Mehmet Kayaalp, Dmitry Ponomarev, Nael Abu-Ghazaleh, and Aamer Jaleel.  A high-resolution side-channel attack on last-level cache.  In 2016 53nd ACM/EDAC/IEEE Design Automation Conference (DAC), pages 1–6, 2016.
  * [94] Georgios Keramidas, Alexandros Antonopoulos, Dimitrios N. Serpanos, and Stefanos Kaxiras.  Non deterministic caches: a simple and effective defense against side channel attacks.  Des. Autom. Embed. Syst., 12(3):221–230, 2008.
  * [95] Khaled N. Khasawneh, Esmaeil Mohammadian Koruyeh, Chengyu Song, Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh.  Safespec: Banishing the spectre of a meltdown with leakage-free speculation.  In 2019 56th ACM/IEEE Design Automation Conference (DAC), pages 1–6, 2019.
  * [96] Taesoo Kim, Marcus Peinado, and Gloria Mainar-Ruiz.  STEALTHMEM: System-level protection against cache-based side channel attacks in the cloud.  In 21st USENIX Security Symposium (USENIX Security 12), pages 189–204, Bellevue, WA, August 2012. USENIX Association.
  * [97] Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu.  Flipping bits in memory without accessing them: An experimental study of dram disturbance errors.  SIGARCH Comput. Archit. News, 42(3):361–372, jun 2014.
  * [98] Vladimir Kiriansky, Ilia Lebedev, Saman Amarasinghe, Srinivas Devadas, and Joel Emer.  Dawg: A defense against cache timing attacks in speculative execution processors.  In 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 974–987, 2018.
  * [99] Vladimir Kiriansky and Carl Waldspurger.  Speculative buffer overflows: Attacks and defenses, 2018.
  * [100] 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 2019 IEEE Symposium on Security and Privacy (SP), pages 1–19, 2019.
  * [101] David Kohlbrenner and Hovav Shacham.  Trusted browsers for uncertain times.  In 25th USENIX Security Symposium (USENIX Security 16), pages 463–480, Austin, TX, August 2016. USENIX Association.
  * [102] David Kohlbrenner and Hovav Shacham.  On the effectiveness of mitigations against floating-point timing channels.  In 26th USENIX Security Symposium (USENIX Security 17), pages 69–81, Vancouver, BC, August 2017. USENIX Association.
  * [103] Igor Korkin.  Divide et impera: Memoryranger runs drivers in isolated kernel spaces, 2018.
  * [104] Esmaeil Mohammadian Koruyeh, Khaled N. Khasawneh, Chengyu Song, and Nael Abu-Ghazaleh.  Spectre returns! speculation attacks using the return stack buffer.  In Proceedings of the 12th USENIX Conference on Offensive Technologies, WOOT’18, page 3, USA, 2018. USENIX Association.
  * [105] Esmaeil Mohammadian Koruyeh, Shirin Haji Amin Shirazi, Khaled N Khasawneh, Chengyu Song, and Nael Abu-Ghazaleh.  Speccfi: Mitigating spectre attacks using cfi informed speculation.  In 2020 IEEE Symposium on Security and Privacy (SP), pages 39–53. IEEE, 2020.
  * [106] Dexter Kozen.  Language-based security.  In International Symposium on Mathematical Foundations of Computer Science, pages 284–298. Springer, 1999.
  * [107] M. Larabel.  Openbsd disabling smt/hyper threading due to security concerns, 2022.
  * [108] Jaekyu Lee, Yasuo Ishii, and Dam Sunwoo.  Securing branch predictors with two-level encryption.  ACM Trans. Archit. Code Optim., 17(3), aug 2020.
  * [109] Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, Hyesoon Kim, and Marcus Peinado.  Inferring fine-grained control flow inside sgx enclaves with branch shadowing.  In Proceedings of the 26th USENIX Conference on Security Symposium, SEC’17, page 557–574, USA, 2017. USENIX Association.
  * [110] Peinan Li, Lutan Zhao, Rui Hou, Lixin Zhang, and Dan Meng.  Conditional speculation: An effective approach to safeguard out-of-order execution against spectre attacks.  In 2019 IEEE International Symposium on High Performance Computer Architecture (HPCA), pages 264–276, 2019.
  * [111] M.H. Lipasti and J.P. Shen.  Exceeding the dataflow limit via value prediction.  In Proceedings of the 29th Annual IEEE/ACM International Symposium on Microarchitecture. MICRO 29, pages 226–237, 1996.
  * [112] Mikko H. Lipasti, Christopher B. Wilkerson, and John Paul Shen.  Value locality and load value prediction.  In Proceedings of the Seventh International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS VII, page 138–147, New York, NY, USA, 1996. Association for Computing Machinery.
  * [113] Moritz Lipp, Vedad Hadžić, Michael Schwarz, Arthur Perais, Clémentine Maurice, and Daniel Gruss.  Take a way: Exploring the security implications of amd’s cache way predictors.  In Proceedings of the 15th ACM Asia Conference on Computer and Communications Security, ASIA CCS ’20, page 813–825, New York, NY, USA, 2020\. Association for Computing Machinery.
  * [114] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, Mike Hamburg, and Raoul Strackx.  Meltdown: Reading kernel memory from user space.  Commun. ACM, 63(6):46–56, may 2020.
  * [115] Fangfei Liu, Qian Ge, Yuval Yarom, Frank Mckeen, Carlos Rozas, Gernot Heiser, and Ruby B. Lee.  Catalyst: Defeating last-level cache side channel attacks in cloud computing.  In 2016 IEEE International Symposium on High Performance Computer Architecture (HPCA), pages 406–418, 2016.
  * [116] Fangfei Liu and Ruby B. Lee.  Random fill cache architecture.  In 2014 47th Annual IEEE/ACM International Symposium on Microarchitecture, pages 203–215, 2014.
  * [117] Fangfei Liu, Hao Wu, Kenneth Mai, and Ruby B. Lee.  Newcache: Secure cache architecture thwarting cache side-channel attacks.  IEEE Micro, 36(5):8–16, 2016.
  * [118] Xiaoxuan Lou, Tianwei Zhang, Jun Jiang, and Yinqian Zhang.  A survey of microarchitectural side-channel vulnerabilities, attacks, and defenses in cryptography.  ACM Comput. Surv., 54(6), jul 2021.
  * [119] Kevin Loughlin, Ian Neal, Jiacheng Ma, Elisa Tsai, Ofir Weisse, Satish Narayanasamy, and Baris Kasikci.  Dolma: Securing speculation with the principle of transient non-observability.  In USENIX Security Symposium, 2021.
  * [120] A. Lutomirski.  x86/fpu: Hard-disable lazy fpu mode, june 2018., 2018.
  * [121] Giorgi Maisuradze and Christian Rossow.  Ret2spec: Speculative execution using return stack buffers.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS ’18, page 2109–2122, New York, NY, USA, 2018. Association for Computing Machinery.
  * [122] Robert Martin, John Demme, and Simha Sethumadhavan.  Timewarp: Rethinking timekeeping and performance monitoring mechanisms to mitigate side-channel attacks.  In 2012 39th Annual International Symposium on Computer Architecture (ISCA), pages 118–129, 2012.
  * [123] Clémentine Maurice, Christoph Neumann, Olivier Heen, and Aurélien Francillon.  C5: Cross-cores cache covert channel.  In Magnus Almgren, Vincenzo Gulisano, and Federico Maggi, editors, Detection of Intrusions and Malware, and Vulnerability Assessment, pages 46–64, Cham, 2015. Springer International Publishing.
  * [124] Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer, and Toon Verwaest.  Spectre is here to stay: An analysis of side-channels and speculative execution, 2019.
  * [125] Marina Minkin, Daniel Moghimi, Moritz Lipp, Michael Schwarz, Jo Van Bulck, Daniel Genkin, Daniel Gruss, Frank Piessens, Berk Sunar, and Yuval Yarom.  Fallout: Reading kernel writes from user space, 2019.
  * [126] Ahmad Moghimi, Jan Wichelmann, Thomas Eisenbarth, and Berk Sunar.  Memjam: A false dependency attack against constant-time crypto implementations.  Int. J. Parallel Program., 47(4):538–570, aug 2019.
  * [127] Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel.  Axiomatic hardware-software contracts for security.  In Proceedings of the 49th Annual International Symposium on Computer Architecture, ISCA ’22, page 72–86, New York, NY, USA, 2022. Association for Computing Machinery.
  * [128] Amir Naseredini, Stefan Gast, Martin Schwarzl, Pedro Miguel Sousa Bernardo, Amel Smajic, Claudio Canella, Martin Berger, and Daniel Gruss.  Systematic analysis of programming languages and their execution environments for spectre attacks, 2021.
  * [129] Oleksii Oleksenko, Bohdan Trach, Tobias Reiher, Mark Silberstein, and Christof Fetzer.  You shall not bypass: Employing data dependencies to prevent bounds check bypass.  arXiv preprint arXiv:1805.08506, 2018.
  * [130] Hamza Omar, Brandon D’Agostino, and Omer Khan.  Optimus: A security-centric dynamic hardware partitioning scheme for processors that prevent microarchitecture state attacks.  IEEE Transactions on Computers, 69(11):1558–1570, 2020.
  * [131] Hamza Omar and Omer Khan.  Ironhide: A secure multicore that efficiently mitigates microarchitecture state attacks for interactive applications.  In 2020 IEEE International Symposium on High Performance Computer Architecture (HPCA), pages 111–122, 2020.
  * [132] Yossef Oren, Vasileios P. Kemerlis, Simha Sethumadhavan, and Angelos D. Keromytis.  The spy in the sandbox: Practical cache attacks in javascript and their implications.  In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, CCS ’15, page 1406–1418, New York, NY, USA, 2015. Association for Computing Machinery.
  * [133] Dag Arne Osvik, Adi Shamir, and Eran Tromer.  Cache attacks and countermeasures: The case of aes.  In David Pointcheval, editor, Topics in Cryptology – CT-RSA 2006, pages 1–20, Berlin, Heidelberg, 2006. Springer Berlin Heidelberg.
  * [134] Riccardo Paccagnella, Licheng Luo, and Christopher W. Fletcher.  Lord of the ring(s): Side channel attacks on the cpu on-chip ring interconnect are practical, 2021.
  * [135] Arthur Perais and André Seznec.  Eole: Combining static and dynamic scheduling through value prediction to reduce complexity and increase performance.  ACM Trans. Comput. Syst., 34(2), apr 2016.
  * [136] C. Percival.  Cache missing for fun and profit.  In http://www.daemonology.net/papers/ htt.pdf, pages 974–987, 2005\.
  * [137] A. Purnal, L. Giner, D. Gruss, and I. Verbauwhede.  Systematic analysis of randomization-based protected cache architectures.  In 2021 2021 IEEE Symposium on Security and Privacy (SP), pages 987–1002, Los Alamitos, CA, USA, may 2021. IEEE Computer Society.
  * [138] Antoon Purnal and Ingrid Verbauwhede.  Advanced profiling for probabilistic prime+probe attacks and covert channels in scattercache.  CoRR, abs/1908.03383, 2019.
  * [139] Moinuddin K. Qureshi.  Ceaser: Mitigating conflict-based cache attacks via encrypted-address and remapping.  In 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 775–787, 2018.
  * [140] Moinuddin K. Qureshi.  New attacks and defense for encrypted-address cache.  In Proceedings of the 46th International Symposium on Computer Architecture, ISCA ’19, page 360–371, New York, NY, USA, 2019. Association for Computing Machinery.
  * [141] Hany Ragab, Alyssa Milburn, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida.  Crosstalk: Speculative data leaks across cores are real.  In 2021 IEEE Symposium on Security and Privacy (SP), pages 1852–1867, 2021.
  * [142] Ashay Rane, Calvin Lin, and Mohit Tiwari.  Secure, precise, and fast Floating-Point operations on x86 processors.  In 25th USENIX Security Symposium (USENIX Security 16), pages 71–86, Austin, TX, August 2016. USENIX Association.
  * [143] Gururaj Saileshwar and Moinuddin Qureshi.  MIRAGE: Mitigating conflict-based cache attacks with a practical fully-associative design.  In 30th USENIX Security Symposium (USENIX Security 21). USENIX Association, August 2021.
  * [144] Gururaj Saileshwar and Moinuddin K. Qureshi.  Cleanupspec: An ”undo” approach to safe speculation.  In Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture, MICRO ’52, page 73–86, New York, NY, USA, 2019\. Association for Computing Machinery.
  * [145] Christos Sakalis, Stefanos Kaxiras, Alberto Ros, Alexandra Jimborean, and Magnus Själander.  Efficient invisible speculative execution through selective delay and value prediction.  In Proceedings of the 46th International Symposium on Computer Architecture, ISCA ’19, page 723–735, New York, NY, USA, 2019. Association for Computing Machinery.
  * [146] Jose Rodrigo Sanchez Vicarte, Pradyumna Shome, Nandeeka Nayak, Caroline Trippel, Adam Morrison, David Kohlbrenner, and Christopher W. Fletcher.  Opening pandora’s box: A systematic study of new ways microarchitecture can leak private data.  In 2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA), pages 347–360, 2021.
  * [147] Sercan Sari, Onur Demir, and Gurhan Kucuk.  Fairsdp: Fair and secure dynamic cache partitioning.  In 2019 4th International Conference on Computer Science and Engineering (UBMK), pages 469–474, 2019.
  * [148] Michael Schwarz, Moritz Lipp, Claudio Canella, Robert Schilling, Florian Kargl, and Daniel Gruss.  Context: A generic approach for mitigating spectre.  In NDSS, 2020.
  * [149] Michael Schwarz, Moritz Lipp, Daniel Moghimi, Jo Van Bulck, Julian Stecklina, Thomas Prescher, and Daniel Gruss.  Zombieload: Cross-privilege-boundary data sampling.  In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS ’19, page 753–768, New York, NY, USA, 2019. Association for Computing Machinery.
  * [150] Michael Schwarz, Clémentine Maurice, Daniel Gruss, and Stefan Mangard.  Fantastic timers and where to find them: High-resolution microarchitectural attacks in javascript.  In Aggelos Kiayias, editor, Financial Cryptography and Data Security, pages 247–267, Cham, 2017. Springer International Publishing.
  * [151] Michael Schwarz, Martin Schwarzl, Moritz Lipp, Jon Masters, and Daniel Gruss.  Netspectre: Read arbitrary memory over network.  In Computer Security – ESORICS 2019: 24th European Symposium on Research in Computer Security, Luxembourg, September 23–27, 2019, Proceedings, Part I, page 279–299, Berlin, Heidelberg, 2019. Springer-Verlag.
  * [152] Martin Schwarzl, Thomas Schuster, Michael Schwarz, and Daniel Gruss.  Speculative dereferencing: Reviving foreshadow.  2021\.  25th International Conference on Financial Cryptography and Data Security : FC 2021 ; Conference date: 01-03-2021 Through 05-03-2021.
  * [153] Brian C. Schwedock and Nathan Beckmann.  Jumanji: The case for dynamic nuca in the datacenter.  In 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 665–680, 2020.
  * [154] André Seznec.  Exploring value prediction with the eves predictor.  2018\.
  * [155] Hovav Shacham.  The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86).  In Proceedings of the 14th ACM Conference on Computer and Communications Security, CCS ’07, page 552–561, New York, NY, USA, 2007. Association for Computing Machinery.
  * [156] Rami Sheikh, Harold W. Cain, and Raguram Damodaran.  Load value prediction via path-based address prediction: Avoiding mispredictions due to conflicting stores.  In Proceedings of the 50th Annual IEEE/ACM International Symposium on Microarchitecture, MICRO-50 ’17, page 423–435, New York, NY, USA, 2017. Association for Computing Machinery.
  * [157] Zhuojia Shen, Jie Zhou, Divya Ojha, and John Criswell.  Restricting control flow during speculative execution.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 2297–2299, 2018.
  * [158] Youngjoo Shin, Hyung Chan Kim, Dokeun Kwon, Ji Hoon Jeong, and Junbeom Hur.  Unveiling hardware-based data prefetcher, a hidden source of information leakage.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS ’18, page 131–145, New York, NY, USA, 2018. Association for Computing Machinery.
  * [159] Anatoly Shusterman, Lachlan Kang, Yarden Haskal, Yosef Meltser, Prateek Mittal, Yossi Oren, and Yuval Yarom.  Robust website fingerprinting through the cache occupancy channel.  In 28th USENIX Security Symposium (USENIX Security 19), pages 639–656, Santa Clara, CA, August 2019. USENIX Association.
  * [160] Olin Sibert, Phillip A. Porras, and Robert Lindell.  The intel 80x86 processor architecture: Pitfalls for secure systems, 1995\.
  * [161] W. Song, B. Li, Z. Xue, Z. Li, W. Wang, and P. Liu.  Randomized last-level caches are still vulnerable to cache side-channel attacks! but we can fix it.  In 2021 2021 IEEE Symposium on Security and Privacy (SP), pages 955–969, Los Alamitos, CA, USA, may 2021. IEEE Computer Society.
  * [162] Julian Stecklina and Thomas Prescher.  Lazyfp: Leaking fpu register state using microarchitectural side-channels, 2018.
  * [163] Jakub Szefer.  Survey of Microarchitectural Side and Covert Channels, Attacks, and Defenses.  J. Hardw. Syst. Secur., 3(3):219–234, 2019.
  * [164] Qinhan Tan, Zhihua Zeng, Kai Bu, and Kui Ren.  Phantomcache: Obfuscating cache conflicts with localized randomization.  In NDSS, 2020.