|
|
|
|
@ -2,6 +2,12 @@
|
|
|
|
|
|
|
|
|
|
\chapter{Background}
|
|
|
|
|
\label{cha:background}
|
|
|
|
|
In this chapter we provide some necessary background.
|
|
|
|
|
We start with memory management and \ac{os}-related topics, namely memory addressing in \autoref{subsec:memoryAddressing}, the kernel (\ref{subsec:kernel}), and the interplay of kernel and user space and how that can lead to \acp{pf} (\ref{subsec:kernelUserSpacePageFault}).
|
|
|
|
|
We continue with caches, their vulnerabilities, and attacks on them in \autoref{sec:cache}, followed by speculative execution (\ref{sec:specularExecution}) and a discussion of various \techterm{transient execution attacks}.
|
|
|
|
|
Emphasis is put on \retbleed{} (\ref{subsubsec:retbleed}).
|
|
|
|
|
|
|
|
|
|
\todo{Make sure all changes are reflected in overview!}
|
|
|
|
|
|
|
|
|
|
\section{Kernel, Address Space and Page Faults}
|
|
|
|
|
\label{sec:kernelAddressSpacePageFault}
|
|
|
|
|
@ -9,58 +15,66 @@
|
|
|
|
|
\subsection{Memory Addressing}
|
|
|
|
|
\label{subsec:memoryAddressing}
|
|
|
|
|
An address space is an ordered set of contiguous, non-negative integer addresses ranging from $0$ to some $2^{N - 1}$.
|
|
|
|
|
\Acp{va} address the virtual memory while \acp{pa} address the physical memory.
|
|
|
|
|
For \acp{va}, $N$ is equal to the bit width of the CPU.\footnote{Which is commonly $64$ \si{\bit}}
|
|
|
|
|
\Acp{pa} addresses physical memory, and therefore, the size of the \ac{pa} space is given by the size of the system's memory.
|
|
|
|
|
\Acp{va} address the virtual memory, while \acp{pa} address the physical memory.
|
|
|
|
|
For \acp{va}, $N$ is equal to the bit width of the CPU.\footnote{Which is commonly \SI{48}{\bit}}
|
|
|
|
|
\Acp{pa} address physical memory, and therefore, the size of the \ac{pa} space is given by the size of the system's memory.
|
|
|
|
|
Addresses are mapped back and forth between \acp{va} and \acp{pa} at a granularity of pages.
|
|
|
|
|
A page is a fixed size and is commonly \SI{4096}{\byte}.
|
|
|
|
|
A page is of fixed size, which is commonly \SI{4096}{\byte}.
|
|
|
|
|
This translation is done using page tables by the \ac{mmu}.
|
|
|
|
|
When referring to ``address'' in this thesis, unless stated explicitly, we are talking about \acp{va}.
|
|
|
|
|
|
|
|
|
|
\subsection{Kernel}
|
|
|
|
|
\label{subsec:kernel}
|
|
|
|
|
The kernel is the core part of each \ac{os} and facilitates the interactions between hardware and software components.
|
|
|
|
|
It can be thought of as a special program that has control over all hardware.
|
|
|
|
|
When some software needs something from hardware, it asks the kernel to do it for them.
|
|
|
|
|
It can be thought of as a special program controlling all hardware.
|
|
|
|
|
When software and hardware need to communicate, the kernel serves as a middleman.
|
|
|
|
|
The kernel has full read and write, but not execute, access to all the system's memory.
|
|
|
|
|
The kernel is given this access via the \techterm{physmap}, a large, contiguous region in the kernel's address space that maps to all the system's physical memory.~\cite{ret2dir}
|
|
|
|
|
|
|
|
|
|
For this thesis, we consider the Linux Kernel\cite{linuxKernel} as it is \ac{foss}, meaning we can freely download, inspect and modify it.
|
|
|
|
|
For this thesis, we consider the Linux Kernel~\cite{linuxKernel} as it is \ac{foss}, meaning we can freely download, inspect and modify it.
|
|
|
|
|
However, \retbleed{} exploits features implemented in hardware, and therefore, other kernels are also applicable/vulnerable.
|
|
|
|
|
|
|
|
|
|
\subsection{Kernel/User Space and Page Faults}
|
|
|
|
|
\label{subsec:kernelUserSpacePageFault}
|
|
|
|
|
Virtual memory is split into kernel and user space to provide memory protection and enforce privilege boundaries.
|
|
|
|
|
Kernel space is strictly reserved for running kernel-related processes, while applications and the like are run in user space.
|
|
|
|
|
As the kernel needs full access over all hardware and software, it runs in unrestricted privilege mode.
|
|
|
|
|
A user, however, has only full access to everything belonging to the user space.
|
|
|
|
|
Kernel space is strictly reserved for running kernel-related processes, while applications are run in user space.
|
|
|
|
|
The kernel needs full access to all hardware and software, so it runs in unrestricted privilege mode.
|
|
|
|
|
A user, in contrast, has only full access to everything belonging to the user space.
|
|
|
|
|
|
|
|
|
|
When a process, no matter if running in user or kernel space, accesses a (virtual) address, the \ac{mmu} needs to translate it to the corresponding \ac{pa}.
|
|
|
|
|
The \ac{mmu} then tries to access the data, which is already in memory in the best case.
|
|
|
|
|
When a process, whether running in user or kernel space, accesses an address, the \ac{mmu} must translate it to the corresponding \ac{pa}.
|
|
|
|
|
The \ac{mmu} walks the \techterm{page table} so check if a mapping from \ac{va} to \ac{pa} exists.
|
|
|
|
|
If a valid mapping is found, the \ac{mmu} tries to access the data at the given \ac{pa}.
|
|
|
|
|
In the best case, the data is already in memory.
|
|
|
|
|
If the data is not in memory or no mapping exists in the first place, a \ac{pf} is raised.
|
|
|
|
|
The kernel's \ac{pf} handler gets active to resolve the matter.
|
|
|
|
|
If the mapping exists but the data is not present in memory, the data is loaded into memory at a granularity of a page.
|
|
|
|
|
If no mapping exists, the kernel has to find a free \ac{pf} and create a mapping for it.
|
|
|
|
|
Then the faulty instruction is re-executed.
|
|
|
|
|
When a process in user space references an address that lies on a page to which the user has no access, the type of the \ac{pf} is \techterm{invalid}.
|
|
|
|
|
The handler informs the user about the privilege boundary breach by sending the \verb+SIGSEGV+ signal.
|
|
|
|
|
An invalid \ac{pf} should never be raised in the absence of bugs in the user process except if the user process has malicious intentions.\footnote{When talking about \acp{pf} in the remainder of this paper, we refer to \techterm{invalid} \acp{pf}.}
|
|
|
|
|
The kernel's \ac{pf} handler gets invoked to resolve it.
|
|
|
|
|
If the mapping exists, but the data is not present in memory, the \ac{pf} handler loads the data, at a granularity of a page, into memory.
|
|
|
|
|
If no mapping exists, the kernel must find a free page and create a mapping for it in the page table.
|
|
|
|
|
Then the faulting instruction is re-executed.
|
|
|
|
|
|
|
|
|
|
Before creating a new mapping, it is always verified whether the subject\footnote{Which is a specific user or the kernel itself.} is allowed to access that particular memory address.
|
|
|
|
|
If the subject references a page that he is not allowed to access, the type of the \ac{pf} is \techterm{invalid}.
|
|
|
|
|
The handler informs the subject about the privilege boundary breach by sending the \verb+SIGSEGV+ signal.
|
|
|
|
|
An invalid \ac{pf} should never be raised in the absence of bugs in the kernel/user process except if the user process has malicious intentions.
|
|
|
|
|
When talking about \acp{pf} in the remainder of this thesis, we refer to \techterm{invalid} \acp{pf}.
|
|
|
|
|
|
|
|
|
|
\section{Stack}
|
|
|
|
|
\label{sec:stack}
|
|
|
|
|
The \techterm{stack} is part of the virtual address space of each process.
|
|
|
|
|
Since the number of registers is limited, the stack is used to store data temporarily.
|
|
|
|
|
Data is pushed and popped from the stack in a \ac{lifo} manner.
|
|
|
|
|
The top of the stack is appointed by the register \verb+%rsp+.
|
|
|
|
|
The register \verb+%rsp+ appoints the top of the stack.
|
|
|
|
|
It grows from high addresses to lower ones.
|
|
|
|
|
Therefore, when pushing a value to the stack, the \verb+%rsp+ is decreased.
|
|
|
|
|
|
|
|
|
|
When a function is called, a \techterm{frame} is allocated on the stack.
|
|
|
|
|
In that process, the function return address, and some bookkeeping data is pushed to the stack.
|
|
|
|
|
In addition, arguments can be passed to the function via the stack.
|
|
|
|
|
Additionally, arguments may be passed to the function via the stack.
|
|
|
|
|
During the function's execution, temporary data may be pushed to the stack.
|
|
|
|
|
Once the function is completed and calls \verb+return+, the return address is loaded from the stack, the whole stack frame gets deallocated, and execution continues at the return address.
|
|
|
|
|
|
|
|
|
|
\section{Cache Structure}
|
|
|
|
|
\label{sec:cache}
|
|
|
|
|
\todo{Correct whole Cache Structure section.}
|
|
|
|
|
CPUs got faster and faster over time.
|
|
|
|
|
While memory also got faster, the pace was slower than for CPUs.
|
|
|
|
|
This gap widened over time.
|
|
|
|
|
@ -117,55 +131,59 @@ The attacker uses a so-called \techterm{convert channel} to make this inference.
|
|
|
|
|
\subsection{Pipelining}
|
|
|
|
|
\label{subsec:pipelining}
|
|
|
|
|
Code is a sequence of instructions.
|
|
|
|
|
To ``execute'' an instruction, the CPU has to do multiple things.
|
|
|
|
|
The CPU must do multiple steps to ``execute'' an instruction.
|
|
|
|
|
At first, the CPU must load the instruction itself from memory.
|
|
|
|
|
This process is called \techterm{fetching}.
|
|
|
|
|
Before being able to \techterm{execute} it, it needs to figure out what kind of instruction it has just fetched and what its operands are.
|
|
|
|
|
This is called \techterm{decoding}.
|
|
|
|
|
Instructions usually affect the system's state, like calculating some value and storing it to someplace.
|
|
|
|
|
This process is called \techterm{decoding}.
|
|
|
|
|
Instructions usually affect the system's state, like calculating some value and storing it someplace.
|
|
|
|
|
We say an instruction \techterm{retires} when these effects are made visible to the system.
|
|
|
|
|
Before retiring, the induced changes are only visible internally to the micro-architecture.
|
|
|
|
|
Before retiring, the induced changes are only visible internally to the microarchitecture.
|
|
|
|
|
|
|
|
|
|
The aforementioned tasks are implemented as hardware units and instructions ``flow'' from one stage to the next.
|
|
|
|
|
The aforementioned tasks are implemented as hardware units, and instructions ``flow'' from one stage to the next.
|
|
|
|
|
Since these stages are independent circuits, the next instruction can already be fetched when the first one gets passed on to the decode stage.
|
|
|
|
|
Since these stages are independent circuits, when one instruction is in the \techterm{decode stage}, the next instruction can already be \techterm{fetched}.
|
|
|
|
|
An internal clock clocks these stages, and each stage has precisely one clock cycle time to finish its work before the results have to be passed to the next stage and information from the lower stage is received.
|
|
|
|
|
An internal clock orchestrates these stages.
|
|
|
|
|
This way, each stage knows when it receives new input from the lower stage and when the results must be ready to be passed to the next stage.
|
|
|
|
|
One says that such a CPU is \techterm{pipelined}.
|
|
|
|
|
|
|
|
|
|
Different micro-architectures have different types and numbers of stages.
|
|
|
|
|
Intel Haskell has, for example, over 14 stages\cite{haswellChipWiki}.
|
|
|
|
|
Different microarchitectures have different types and numbers of stages.
|
|
|
|
|
Intel Haswell has, for example, over 14 stages~\cite{haswellChipWiki}.
|
|
|
|
|
|
|
|
|
|
\subsection{Speculation}
|
|
|
|
|
\label{subsec:speculation}
|
|
|
|
|
While pipelining increases throughput and hence the overall performance of the CPU, it happens that the CPU \techterm{execute} instructions which it should never have.
|
|
|
|
|
While pipelining increases throughput and hence the overall performance of the CPU, it happens that the CPU \techterm{executes} instructions that it should never have.
|
|
|
|
|
Multiple cases can lead to that.
|
|
|
|
|
|
|
|
|
|
When a pipeline stage cannot complete within one cycle, which may happen when an operand needs to be fetched from memory, the whole pipeline comes naturally to a halt, called \techterm{stalling}.
|
|
|
|
|
Since this is very costly, the CPU tries to prevent that by executing instructions \techterm{out-of-order}.
|
|
|
|
|
Meaning, architecturally, the instructions are ``executed'' in the instruction order, which is achieved by retiring them in that order.
|
|
|
|
|
However, the CPU may internally execute them in any order suitable to it.
|
|
|
|
|
When a pipeline stage cannot complete within the given timeframe, which may happen when an operand needs to be fetched from memory, the whole pipeline comes naturally to a halt.
|
|
|
|
|
One says that the pipeline is \techterm{stalling}.
|
|
|
|
|
Since this is very costly, the CPU tries to prevent that by executing instructions \ac{ooo}, which means that when an instruction is not yet ready to be executed, a subsequent instruction may already be executed.
|
|
|
|
|
Obviously, the CPU needs to respect dependencies.
|
|
|
|
|
For example, it cannot execute an instruction whose operand depends on the result of the paused instruction.
|
|
|
|
|
For example, it cannot execute any instructions whose operand depends on the result of a not yet executed instruction.
|
|
|
|
|
In addition, the system must give the illusion that the ``execution'' follows the \techterm{program order}.
|
|
|
|
|
This is achieved by retiring the instruction in the program order.
|
|
|
|
|
|
|
|
|
|
\techterm{Out-of-order} execution leads to \techterm{speculation}, as at the time of the execution, it is unclear if the instruction lies on the architectural path.
|
|
|
|
|
The paused instruction may, for example, introduce a branch that jumps to an arbitrary location in code, or the instruction may even introduce an unrecoverable fault or an abort.
|
|
|
|
|
Attacks exploiting the later case are generally referred to as \techterm{Meltdown}\cite{meltdown} vulnerabilities.
|
|
|
|
|
\ac{ooo} execution leads to \techterm{speculation}, as it is potentially unclear if an \ac{ooo} executed instruction lies on the architectural path.
|
|
|
|
|
Speculation happens if the execution of a branching instruction gets delayed while further downstream instructions are already executed.
|
|
|
|
|
Alternatively, speculation can be caused if an instruction whose execution gets delayed, introduces an unrecoverable fault or an abort, once it is executed.
|
|
|
|
|
Attacks exploiting the later case are generally referred to as \techterm{Meltdown}~\cite{meltdown} vulnerabilities.
|
|
|
|
|
|
|
|
|
|
Speculatively executed instructions that should not have been executed and therefore need to be ``undone'' are called \techterm{transient instructions}.
|
|
|
|
|
|
|
|
|
|
\subsection{Branch Prediction}
|
|
|
|
|
\label{subsec:pranchPrediction}
|
|
|
|
|
Branching instructions are different to deal with.
|
|
|
|
|
As they may jump to an arbitrary location in code, the CPU is most wrong when assuming that subsequent instruction is executed.
|
|
|
|
|
Branching instructions are different from non-branching instruction as they affect the control flow.
|
|
|
|
|
By potentially jumping to an arbitrary location in code, the CPU is primarily wrong when assuming that subsequent instruction is executed.
|
|
|
|
|
Therefore, the CPU tries to predict the target for branching instruction.
|
|
|
|
|
Misprediction of branch targets leads to much work needing to be undone, incurring substantial performance penalties.
|
|
|
|
|
Therefore, good branch target prediction is inevitable for modern and performant CPUs.
|
|
|
|
|
Therefore, good branch target prediction is essential for modern and performant CPUs.
|
|
|
|
|
|
|
|
|
|
This prediction is made by the \ac{bpu}, a little hardware unit located in the instruction pipeline.
|
|
|
|
|
When the CPU notices a branching instruction, which it does after decoding it, it predicts where the branch leads.\footnote{Actually, there are prediction mechanisms to guess if a not yet decoded instruction could be a branching instruction, but that is not of relevance to us.}
|
|
|
|
|
When the CPU detects a branching instruction, which it does after decoding the instruction, it predicts where the branch leads.\footnote{Actually, there are prediction mechanisms to guess if a not yet decoded instruction could be a branching instruction, but that is not of relevance to us.}
|
|
|
|
|
The \ac{bpu} consists of multiple predictors, and the one to use for a particular instruction is chosen based on the type of the instruction.
|
|
|
|
|
|
|
|
|
|
In the following, we will look at the two predictors relevant for this thesis.
|
|
|
|
|
Due to the proprietary nature of CPUs, only very little is officially communicated about the \ac{bpu}'s internals, and researchers have to rely on reverse-engineering efforts.\cite{projectZero}
|
|
|
|
|
Due to the proprietary nature of CPUs, only very little is officially communicated about the \ac{bpu}'s internals, and researchers have to rely on reverse-engineering efforts.~\cite{projectZero}
|
|
|
|
|
|
|
|
|
|
\subsubsection{Direct/Indirect Branch Prediction}
|
|
|
|
|
\label{subsubsec:dirIndirBranchPrediction}
|
|
|
|
|
@ -175,201 +193,211 @@ Furthermore, branches are either \techterm{conditional} or \techterm{uncondition
|
|
|
|
|
As the name indicates, the destination for \techterm{conditional} branches depends on a condition, while \techterm{unconditional} branches are always taken.
|
|
|
|
|
|
|
|
|
|
The prediction has two aspects.
|
|
|
|
|
When a branch is \techterm{conditional}, the \ac{bpu} needs to predict if the branch is taken or not, while the destination must be predicted for a \techterm{indirect} branch.
|
|
|
|
|
When a branch is \techterm{conditional}, the \ac{bpu} needs to predict if the branch is taken or not, and where does the branch lead to, while for \techterm{indirect} branches, only the destination needs to be predicted.
|
|
|
|
|
\techterm{Direct + unconditional} branches are the easiest to deal with as they do not require any prediction.
|
|
|
|
|
However, predicting \techterm{indirect + conditional} requires two predictions; is the branch taken or not, and if it is taken, what is its destination?
|
|
|
|
|
They have the highest risk of misprediction.
|
|
|
|
|
However, they do not exist in the x86\_64 \ac{isa}.
|
|
|
|
|
Happily, they do not exist in the x86\_64 \ac{isa}.
|
|
|
|
|
|
|
|
|
|
This predictor works by the assumption that when a branch is reencountered, it behaves similarly to the previous case.
|
|
|
|
|
The direct/indirect branch predictors works by the assumption that when a branch is reencountered, it behaves similarly to the previous encounter.
|
|
|
|
|
A cache-like structure called \ac{btb} stores targets of previously encountered branches.
|
|
|
|
|
When the predictor has to make a prediction for a particular branching instruction, the \ac{btb} is indexed to see if the branch has previously been encountered.
|
|
|
|
|
If there is an entry for the branch, was it taken, and where did it go?
|
|
|
|
|
The \ac{btb} is similarly structured as caches in the way that they are also composed of sets.
|
|
|
|
|
If there is an entry for this branch, was it taken, and if so, where did it go?
|
|
|
|
|
|
|
|
|
|
The \ac{btb} is similarly structured to caches in the way that they are also composed of sets.
|
|
|
|
|
Similar to data in a cache, a branch always maps to exactly one set.
|
|
|
|
|
A set is composed of multiple possible targets, which allows for predicting branches with more complex taken/not-taken patterns and multiple destinations.
|
|
|
|
|
The indexing of the \ac{btb} is microarchitecture dependent but generally done using machine states like the current \ac{pc}.
|
|
|
|
|
In addition, auxiliary data structures may be used.
|
|
|
|
|
Some Intel microarchitectures use the branch history, condensed in a hash-like format, stored in the \ac{bhb}, for the indexing.
|
|
|
|
|
It allows for efficient representation of the $N$ last encountered branches.
|
|
|
|
|
For Intel Haswell for example, $N = 29$.
|
|
|
|
|
For Intel Haswell, for example, $N = 29$.~\cite{projectZero,spectre}
|
|
|
|
|
|
|
|
|
|
When we have two different branching instructions which map to the same \ac{btb} set, we say that they collide.
|
|
|
|
|
It has been shown that for Intel Haswell, two branches collide if bit \numrange{6}{11} are equivalent\cite{retbleed}.
|
|
|
|
|
Unlike caches, the ways of the \ac{btb} have much smaller tags, which results in \techterm{collisions}.
|
|
|
|
|
A collision is when two different branching instructions map to the same \ac{btb} set.
|
|
|
|
|
It has been shown that for Intel Haswell, two branches collide if bits \numrange{6}{11} are equivalent.~\cite{retbleed}
|
|
|
|
|
On AMD, it is a bit more complicated.
|
|
|
|
|
Two addresses collide if the address bits are permutated according to a specific schema.
|
|
|
|
|
While the collision works for Intel across privilege domains, for AMD, it depends on the microarchitecture.
|
|
|
|
|
For Zen 1, it always works.
|
|
|
|
|
For Zen 2, only if \ac{smap} and \ac{smep} are disabled or some specific condition is fulfilled \todo{what is this condition?}.
|
|
|
|
|
Lastly, for Zen 3 it does not work across privilege domains.\cite{retbleed}
|
|
|
|
|
Two addresses collide if the address bits are permuted according to a specific schema.
|
|
|
|
|
While the collision works for Intel across privilege domains, for AMD, it only works for Zen 1 and Zen 2.
|
|
|
|
|
For Zen 3, \citeauthor{retbleed} could not detect collisions across privilege boundaries.~\cite{retbleed}
|
|
|
|
|
|
|
|
|
|
\subsubsection{Function Return Prediction}
|
|
|
|
|
\label{subsubsec:funcReturnPrediction}
|
|
|
|
|
This predictor is used for return instructions.
|
|
|
|
|
It works by assuming that a function always returns to the place it was called from.
|
|
|
|
|
It uses a stack-like cache called \ac{rsb} to support multiple nested function calls.
|
|
|
|
|
When encountering a call, the expected return address, which is for a x86\_64 \ac{isa} system $\ac{pc} + 4$, is pushed to the \ac{rsb}.
|
|
|
|
|
Once we return, the top address of the \ac{rsb} is popped, and we speculatively execute that path.
|
|
|
|
|
When encountering a call, the expected return address is pushed to the \ac{rsb}.\footnote{For the x86\_64 \ac{isa}, a function residing at \ac{pc} is expected to return to $\ac{pc} + 4$.}
|
|
|
|
|
Once we return, the top address of the \ac{rsb} is popped, and we speculatively execute the path starting at the retrieved address.
|
|
|
|
|
|
|
|
|
|
The capacity of the \ac{rsb} is somewhat limited with, for example, $16$ entries for Haswell or $22$ for Ice Lake.
|
|
|
|
|
The capacity of the \ac{rsb} is limited, with, for example, $16$ entries for Haswell or $22$ for Ice Lake.~\cite{agnerFogManual}
|
|
|
|
|
In case of an overflow, the \ac{rsb} wraps around and overwrites the oldest element.
|
|
|
|
|
About the behavior of an underflow is not much known.
|
|
|
|
|
Johannes Wikner et al.\cite{retbleed} have shown that certain microarchitectures fall back on using the \ac{btb}.
|
|
|
|
|
\citeauthor{retbleed} have shown that certain microarchitectures fall back on using the \ac{btb}.~\cite{retbleed,rsbUnderflow}
|
|
|
|
|
We will look more closely at this behavior in \autoref{subsubsec:retbleed}.
|
|
|
|
|
|
|
|
|
|
\subsection{Spectre Attacks}
|
|
|
|
|
\label{subsec:spectreAttacks}
|
|
|
|
|
While speculatively executed instructions do not retire and hence, they do not affect the architectural state, they leave traces to the micro-architectural state, which can be exploited using \techterm{side-channel attacks}.
|
|
|
|
|
Since the publication of \techterm{spectre}\cite{spectre} in 2018, new versions of \techterm{spectre}, or more generally referred to as \techterm{transient execution attacks}, were discovered.
|
|
|
|
|
While speculatively executed instructions do not retire and hence, they do not affect the architectural state, they leave traces in the microarchitectural state.
|
|
|
|
|
Using \techterm{side-channel attacks}, these trances can be used to infer information about the operants of the speculatively executed instructions.
|
|
|
|
|
Since the publication of \techterm{Spectre}~\cite{spectre} in 2018, new versions of \techterm{Spectre}, more generally referred to as \techterm{transient execution attacks}, were discovered.
|
|
|
|
|
|
|
|
|
|
By influencing the \techterm{transient code}, attackers can control what data to leak.
|
|
|
|
|
That is not just limited to data of the current user, but a wide variety of attacks work across privilege boundaries.
|
|
|
|
|
This allows for the leakage of data of other users.
|
|
|
|
|
To achieve the desired speculation, attackers often manipulate the \ac{bpu} in carefully selected ways.
|
|
|
|
|
To achieve the desired speculation, attackers often manipulate the \ac{bpu} in carefully selected ways.~\cite{spectre,meltdown,retbleed}
|
|
|
|
|
|
|
|
|
|
For a \techterm{spectre attack} to be successful, three things are needed:
|
|
|
|
|
\begin{enumerate}
|
|
|
|
|
\item \textbf{Speculation Primitive.} Causes the speculation and makes the \techterm{disclosure gadget} to get executed \techterm{speculatively}.
|
|
|
|
|
\item \textbf{Disclosure Gadget.} Is executed speculatively and causes the leakage.
|
|
|
|
|
\item \textbf{Convert Channel.} Is used to read out the micro-architectural traces left over by the \techterm{transient execution}.
|
|
|
|
|
\item \textbf{Convert Channel.} Is used to read out the microarchitectural traces left over by the \techterm{transient execution}.
|
|
|
|
|
\end{enumerate}
|
|
|
|
|
|
|
|
|
|
Mitigate \techterm{spectre attacks} is non-trivial as speculation is a core principle of modern CPUs.
|
|
|
|
|
Moreover, since there are a whole range of \techterm{spectre} attacks, there is also no single patch to fix them all, but rather for each, an individual mitigation has to be found.
|
|
|
|
|
Mitigating a \techterm{spectre attack} can go one of three routes:
|
|
|
|
|
Mitigating Spectre attacks is non-trivial as speculation is a core principle of modern CPUs.
|
|
|
|
|
Moreover, since there is a whole range of Spectre attacks, there is also no single patch to fix them all, but rather for each, an individual mitigation has to be found.
|
|
|
|
|
Spectre attacks can be mitigated in three different ways:~\cite{retbleed}
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item \techterm{Isolation}: Privilege boundaries are enforced such that an attacker cannot influence a victim acting in a different privilege domain. $\Rightarrow$ No leakage of sensitive information.
|
|
|
|
|
\item \techterm{Isolation}: Privilege boundaries are enforced such that an attacker cannot influence a victim process acting in a different privilege domain. $\Rightarrow$ No leakage of sensitive information.
|
|
|
|
|
\item \techterm{Prevention of speculation}: $\Rightarrow$ \techterm{Disclosure gadget} cannot be executed speculatively.
|
|
|
|
|
\item \techterm{Prevention of convert channel}: $\Rightarrow$ Stop leakage of micro-architectural traces.
|
|
|
|
|
\item \techterm{Prevention of convert channel}: $\Rightarrow$ Stop leakage of microarchitectural traces.
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
\item This is not feasible for the Linux Kernel\cite{retbleed}.
|
|
|
|
|
\item This is not feasible for the Linux Kernel.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
Next, we will look at a few relevant \techterm{transient execution attacks}.
|
|
|
|
|
We start by looking at \techterm{spectre v1} which should serve as a simple introductory example.
|
|
|
|
|
\techterm{Spectre v2} shares some similarities with \retbleed{}, that is why we will discuss that after.
|
|
|
|
|
\techterm{Spectre\acs{rsb}} is relevant, because we use it to craft our speculative version of \retbleed.
|
|
|
|
|
We start by looking at \techterm{Spectre~V1}, which should serve as a simple introductory example.
|
|
|
|
|
As \techterm{Spectre V2} shares some similarities with \retbleed, we will discuss that after.
|
|
|
|
|
\techterm{Spectre\acs{rsb}} is relevant because we use it to craft our speculative version of \retbleed.
|
|
|
|
|
Lastly, we will have an in-depth view on \retbleed, such that we have all the knowledge required to build the speculative version on top of it.
|
|
|
|
|
|
|
|
|
|
For each of these vulnerabilities, we will quickly discuss what they are, how they work, what makes them feasible, and possibly how they are mitigated.
|
|
|
|
|
|
|
|
|
|
\subsubsection{Spectre V1}
|
|
|
|
|
\techterm{Spectre Variant 1}\cite{spectre} is also referred to as \techterm{Spectre \ac{bcb}} and targets conditional branching instruction.
|
|
|
|
|
\techterm{Spectre Variant 1}~\cite{spectre} is also referred to as \techterm{Spectre \ac{bcb}} and targets conditional branching instruction.
|
|
|
|
|
When evaluating the condition takes time, the CPU guesses which branch is more likely to be taken and speculatively executes it.
|
|
|
|
|
The attacker can steer the (speculative) branch's target by mistraining the branch predictor.
|
|
|
|
|
For example, when placing the conditional inside a for loop where the branch is taken each iteration except for the last one, the branch predictor would ``learn'' that the branch is always taken and, therefore, mispredict in the last iteration.
|
|
|
|
|
The attacker can steer the speculative control flow by mistraining the branch predictor.
|
|
|
|
|
For example, when placing the conditional inside a for loop where the branch is taken each iteration except for the last one, the branch predictor would ``learn'' that the branch is always taken, and therefore, mispredict in the last iteration.
|
|
|
|
|
|
|
|
|
|
To make the speculation work reliable, the \techterm{speculation window} has to be large enough.
|
|
|
|
|
This is achieved by ensuring that evaluating the condition takes a reasonable amount of time to get evaluated, which can be caused by an uncached memory access.
|
|
|
|
|
To make the speculation work reliable, the \techterm{speculation window}, which is the timeframe in which instructions are executed speculatively, has to be large.
|
|
|
|
|
A large speculation window is achieved by ensuring that evaluating the condition takes a reasonable amount of time.
|
|
|
|
|
This can be caused, for example, by an uncached memory access.
|
|
|
|
|
|
|
|
|
|
If a gadget, as in \autoref{lst:condBranchEx}, is executed speculatively, data outside the array is accessed.
|
|
|
|
|
The value can then be inferred using a \techterm{side-channel}.
|
|
|
|
|
|
|
|
|
|
\begin{lstlisting}[style=CStyle,caption={Conditional Branch Example},label={lst:condBranchEx}]
|
|
|
|
|
for (int i = 0; i < array_size + 1; i++) {
|
|
|
|
|
\begin{lstlisting}[style=CStyle,caption={The for loop trains the \ac{bpu} to make it belief that the branch induced by the if statement in line $6$ is always taken. In the last iteration, this causes the \ac{bpu} to misspredict. To cause the speculation window, \texttt{array\_size} is uncached prior to the branch. Using a suitable convert channel, which is not depicted in this snipped, the value of \texttt{y} can be leaked.},label={lst:condBranchEx}]
|
|
|
|
|
for (int i = 0; i <= array_size; i++) {
|
|
|
|
|
// Make sure that array_size is uncached
|
|
|
|
|
doUncache(array_size);
|
|
|
|
|
|
|
|
|
|
// Misprdicts for x = array_size
|
|
|
|
|
if (x < array_size) {
|
|
|
|
|
y = array[x];
|
|
|
|
|
// Misprdicts for i = array_size
|
|
|
|
|
if (i < array_size) {
|
|
|
|
|
y = array[i];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
\end{lstlisting}
|
|
|
|
|
|
|
|
|
|
By using \verb+lfence+ instruction or creating data dependencies, the speculative out-of-bounds access can be prevented.\cite{amdSpectreMitigation}
|
|
|
|
|
Compilers, such as GCC, have been patched to do that automatically\cite{spectreV1Mitigation}.
|
|
|
|
|
To mitigate Spectre V1, one can use the \verb+lfence+ instruction or create data dependencies, to prevent the speculative out-of-bounds access.~\cite{amdSpectreMitigation}
|
|
|
|
|
Compilers, such as GCC, have been patched to be able to do that automatically.~\cite{spectreV1Mitigation}
|
|
|
|
|
Therefore, by recompilation, Spectre V1 can be mitigated.
|
|
|
|
|
|
|
|
|
|
This attack is often employed with array out-of-bounds accesses, as in our example.
|
|
|
|
|
Nevertheless, even if called \ac{bcb}, it is not limited to them and can be used to exploit any kind of conditional branch.
|
|
|
|
|
Nevertheless, even if called \ac{bcb}, it is not limited to them and can be used to exploit any kind of conditional branches.
|
|
|
|
|
|
|
|
|
|
\subsubsection{Spectre V2}
|
|
|
|
|
\label{subsec:spectreV2}
|
|
|
|
|
\techterm{Spectre Variant 2}\cite{spectre} is also referred to as \techterm{Spectre \acs{bti}} (\acl{bti}) and takes advantage of speculative execution of indirect branches.
|
|
|
|
|
As we have seen in \autoref{subsubsec:dirIndirBranchPrediction}, indirect branches are predicted based on the \ac{btb}.
|
|
|
|
|
\techterm{Spectre Variant 2}~\cite{spectre} is also referred to as \techterm{Spectre \acs{bti}} and takes advantage of speculative execution of indirect branches.
|
|
|
|
|
As seen in \autoref{subsubsec:dirIndirBranchPrediction}, indirect branches are predicted based on the \ac{btb}.
|
|
|
|
|
An attacker can hijack an indirect branch by injecting a branch target into the \ac{btb}, which the predictor uses to predict the destination of the victim branch.
|
|
|
|
|
This causes the victim branch to speculatively executed the injected target, where the gadget of the attacker resides.
|
|
|
|
|
This injection causes the victim branch to speculatively executed the injected target, where the gadget of the attacker resides.
|
|
|
|
|
As the \ac{btb} is not flushed on transitions of privilege domains, this \ac{bti} works across privilege boundaries.
|
|
|
|
|
|
|
|
|
|
To hijack an indirect branch instruction residing at \verb+VICTIM+, the attacker looks for a colliding address \verb+VICTIM'+.
|
|
|
|
|
By jumping from \verb+VICTIM'+ to \verb+GADGET+, a corresponding entry is created in the \ac{btb}.
|
|
|
|
|
When the branch at \verb+VICTIM+ is encountered, as the address collides with \verb+VICTIM'+, the target \verb+GADGET+ is used for the speculation.
|
|
|
|
|
By jumping from \verb+VICTIM'+ to \verb+GADGET+, a corresponding entry in the \ac{btb} is created.
|
|
|
|
|
When the victim encounters the branch at \verb+VICTIM+, the \ac{btb} will use the injected target for the prediction.
|
|
|
|
|
This steers the speculative control flow to \verb+GADGET+.
|
|
|
|
|
|
|
|
|
|
Intel proposed \ac{ibrs} that would prevent the predictor from using branch predictions from lower privilege levels on higher ones, as an mitigation for Spectre V2.
|
|
|
|
|
In the end a different mitigation, called \techterm{retpoline}\cite{retpolineIntel,retpolineGoogle}, was used due to its lower overhead.\cite{retpolineOverIbrs}
|
|
|
|
|
Intel proposed \ac{ibrs}~\cite{ibrs} as a possible mitigation for Spectre V2.
|
|
|
|
|
\ac{ibrs} prevents the predictor from using branch prediction resolutions from lower privilege levels on higher ones.
|
|
|
|
|
This measure prevents the hijack of a victim process across privilege boundaries.
|
|
|
|
|
In the end, a different mitigation, called \techterm{retpoline}~\cite{retpolineIntel,retpolineGoogle}, was used due to its lower overhead.~\cite{retpolineOverIbrs}
|
|
|
|
|
\techterm{Retpoline} prevents speculative execution from using the indirect branch predictor.
|
|
|
|
|
|
|
|
|
|
\subsubsection{Spectre\acs{rsb}}
|
|
|
|
|
\label{subsubsec:spectreRsb}
|
|
|
|
|
\techterm{Spectre\acs{rsb}}\cite{spectreRsb} is another spectre attack.
|
|
|
|
|
It targets return instructions and by exploiting the \ac{rsb}, an attacker can create a speculation window, where arbitrary code can be executed.
|
|
|
|
|
\techterm{Spectre\acs{rsb}}~\cite{spectreRsb} is another Spectre attack.
|
|
|
|
|
It targets return instructions, and by exploiting the \ac{rsb}, it can create a speculation window where arbitrary code can be executed.
|
|
|
|
|
However, it is only feasible if the attacker can modify the executed code.
|
|
|
|
|
|
|
|
|
|
When encountering a return instruction, the return instruction predictor assumes that the return leads back to where the function was called from.
|
|
|
|
|
By changing the architectural return address, which is done by modifying the stack, the predicted return address differs from the architectural return address and hence, a speculation window is created.
|
|
|
|
|
When encountering a return instruction, the return instruction predictor thinks that the return leads back to where the function was called from.
|
|
|
|
|
By modifying the stack, an attacker can change the architectural return address.
|
|
|
|
|
The discrepancy between the actual and expected return address causes the return instruction predictor to mispredict, which creates a speculation window.
|
|
|
|
|
|
|
|
|
|
Spectre\acs{rsb} works quite reliably and the speculations windows created are rather large.
|
|
|
|
|
In \autoref{lst:roguePrimitive}, we have used this method to cause a speculation.
|
|
|
|
|
In \autoref{lst:roguePrimitive}, we have used this method to cause speculation.
|
|
|
|
|
|
|
|
|
|
\subsubsection{Retbleed}
|
|
|
|
|
\label{subsubsec:retbleed}
|
|
|
|
|
\retbleed\cite{retbleed} is a \techterm{transient execution attack}, sharing many similarities with Spectre V2.
|
|
|
|
|
\retbleed~\cite{retbleed} is a \techterm{transient execution attack}, sharing many similarities with Spectre V2.
|
|
|
|
|
It also hijacks branches by poisoning \ac{btb}, but in contrast to Spectre V2, it targets return instructions.
|
|
|
|
|
While Spectre\acs{rsb}\cite{spectreRsb} and Ret2Spec\cite{ret2spec} both are return-based spectre attacks, they target the \ac{rsb}, while \retbleed{} targets the \ac{btb}.
|
|
|
|
|
While Spectre\acs{rsb}~\cite{spectreRsb}, Ret2Spec~\cite{ret2spec}, and Spring~\cite{spring} all are return-based Spectre attacks, they target the \ac{rsb}, while \retbleed{} targets the \ac{btb}.
|
|
|
|
|
|
|
|
|
|
By reverse-engineering aspects of the \ac{bpu}, they gained new insights on the behavior of the \ac{bpu} under certain micro-architectural-dependant conditions.
|
|
|
|
|
This has led to the creation of the spectre exploit \retbleed{}, that leaks arbitrary kernel memory at a rate \SI{219}{\byte\per\second} for Intel Coffee Lake and \SI{3.9}{\kilo\byte\per\second} for AMD Zen 2.
|
|
|
|
|
By reverse-engineering aspects of the \ac{bpu}, \citeauthor{retbleed} gained new insights on the behavior of the \ac{bpu} under certain microarchitectural-dependant conditions.
|
|
|
|
|
These findings have led them the creation of the Spectre exploit \retbleed, that leaks arbitrary kernel memory at a rate of \SI{219}{\byte\per\second} for Intel Coffee Lake and \SI{3.9}{\kilo\byte\per\second} for AMD Zen 2.
|
|
|
|
|
|
|
|
|
|
\retbleed{} relies on two exploitation primitives, which need to be present in a susceptible system; exploitable return instructions and \ac{bti} on kernel memory.
|
|
|
|
|
\retbleed{} relies on two exploitation primitives, which must be present in a susceptible system; exploitable return instructions and \ac{bti} on kernel memory.
|
|
|
|
|
We will discuss what both of them mean before wrapping up with the end-to-end \retbleed{} exploit.
|
|
|
|
|
|
|
|
|
|
\paragraph{Exploitable Return Instructions.}
|
|
|
|
|
\label{para:exploitRetInstr}
|
|
|
|
|
Using their reverse-engineering, they showed that in some instances, the \acs{rsb}-based return instruction predictor falls back to using the \ac{btb}.
|
|
|
|
|
For Intel CPUs, like Haskwell and Coffee Lake, this happens for \ac{rsb} underflows.
|
|
|
|
|
AMD falls back to using the \ac{btb} without the \ac{rsb} underflowing.
|
|
|
|
|
Instead, they observe this behavior whenever the return instruction's address collides with the address of a previously encountered indirect branch.
|
|
|
|
|
This means that under these conditions, return instructions behave as indirect branches.
|
|
|
|
|
This fallback is referred to as \ac{rsb}-to-\ac{btb}.
|
|
|
|
|
When the fallback happens, return instruction behave as indirect branches.
|
|
|
|
|
For Intel microarchitectures, like Haswell and Coffee Lake, this happens for \ac{rsb} underflows.
|
|
|
|
|
AMD falls back to using the \ac{btb} without the \ac{rsb} needing to underflow.
|
|
|
|
|
Instead, they observe the fallback whenever the return instruction's address collides with the address of a previously encountered indirect branch.
|
|
|
|
|
|
|
|
|
|
This findings mean that for Intel all return instructions which follow a \emph{sufficiently-deep} \techterm{call stack} (i.e. one such that the \ac{rsb} underflows) can be hijacked, while for AMD \emph{any} return instruction can be hijacked.
|
|
|
|
|
These findings mean that for Intel, all return instructions which follow a \emph{sufficiently-deep} \techterm{call stack} (i.e., one such that the \ac{rsb} underflows) can be hijacked, while for AMD, any return instruction can be hijacked.
|
|
|
|
|
|
|
|
|
|
\retbleed{} has released \retbti, a PoC exploit for Intel and AMD, which shows if a computer system is susceptible to this primitive.
|
|
|
|
|
\retbti{} is a \ac{poc}, released as part of \retbleed~\cite{retbleedRepo}, that demonstrates if a system is susceptible to this primitive.
|
|
|
|
|
The \ac{poc} was released for both, AMD and Intel.
|
|
|
|
|
|
|
|
|
|
\paragraph{\acs{bti} on Kernel Returns.}
|
|
|
|
|
\label{para:btiOnKernelRet}
|
|
|
|
|
After the predictor falls back from using the \ac{rsb} to the \ac{btb}, the attacker can now poison the \ac{btb} such that a return instruction gets hijacked, and the attacker's gadget gets executed speculatively.
|
|
|
|
|
While the \ac{bti} allows for the injection of arbitrary targets, \ac{smap} and \ac{smep} limit the target to be in kernel space as they prevent the kernel from jumping and executing code in user space.
|
|
|
|
|
Therefore, the gadget has to reside in kernel space.
|
|
|
|
|
The \ac{btb} can be poisoned by utilizing colliding branch sources, similarly to Spectre V2, discussed in \autoref{subsec:spectreV2}.
|
|
|
|
|
Johannes Wikner et al.\cite{retbleed} were able to show that illegal branches, which cross privilege boundaries and cause a \ac{pf}, are also taken up by the \ac{btb}.
|
|
|
|
|
But that is not an issue, as the \ac{btb} can be poisoned by utilizing colliding branch sources, similarly as with Spectre V2.
|
|
|
|
|
\citeauthor{retbleed} showed that branches that cross privilege boundaries, and hence, cause a \ac{pf}, are still taken up by the \ac{btb}.
|
|
|
|
|
|
|
|
|
|
The \cpbti, also referred to as \ac{utk}, PoC demonstrates if the employed computer system is vulnerable to this second primitive.
|
|
|
|
|
A system on which both, the \retbti{} and \cpbti{} PoC work\footnote{It is actually sufficient if \cpbti{} works, as the second PoC can only work if the first one works.}, is susceptible to \retbleed.
|
|
|
|
|
The \cpbti{} \ac{poc}\footnote{Which is also referred to as \ac{utk} \ac{poc}.}~\cite{retbleedRepo} shows if a system is vulnerable to the second primitive.
|
|
|
|
|
A system where both \acp{poc} works successfully, is susceptible by \retbleed.\footnote{As the \cpbti{} \ac{poc} is based on \retbti, it is sufficient if the \cpbti{} \ac{poc} works.}
|
|
|
|
|
|
|
|
|
|
\paragraph{\retbleed{} End-to-End Attack.}
|
|
|
|
|
\label{para:rebleedE2E}
|
|
|
|
|
The acrual \retbleed{} attack it is able to leaks arbitrary privileged memory at a rate of \SI{219}{\byte\per\second} for Intel Coffee Lake and \SI{3.9}{\kilo\byte\per\second} for AMD Zen 2.
|
|
|
|
|
The actual \retbleed{} attack can leak arbitrary privileged memory at a rate of \SI{219}{\byte\per\second} for Intel Coffee Lake and \SI{3.9}{\kilo\byte\per\second} for AMD Zen 2.
|
|
|
|
|
All systems susceptible to both mentioned primitives are vulnerable to \retbleed.
|
|
|
|
|
AMD Zen 1, Zen 1+ and Zen 2, as well as Intel Kaby Lake and Coffee Lake, are among the vulnerable microarchitectures.\cite{retbleed}
|
|
|
|
|
AMD Zen 1, Zen 1+ and Zen 2, as well as Intel Kaby Lake and Coffee Lake, are among the vulnerable microarchitectures.~\cite{retbleed}
|
|
|
|
|
|
|
|
|
|
To make this attack work, multiple preliminary steps are required.
|
|
|
|
|
They are: detecting and identifying vulnerable and exploitable return instructions, finding suitable disclosure gadgets, and detecting the branch history at the victim return.
|
|
|
|
|
During the attack, \ac{kaslr} needs to be broken and the branch history needs to be set up appropriately, before the victim return can be executed.
|
|
|
|
|
To make this attack work, an attacker must overcome multiple challenges.
|
|
|
|
|
Firstly, vulnerable and exploitable return instructions must be detected and identified.
|
|
|
|
|
Next, a suitable disclosure gadget must be found, and the branch history of the victim return must be reconstructed.
|
|
|
|
|
During the attack, \ac{kaslr} needs to be broken, to get the address of the disclosure gadget and relevant parts of the convert channel.
|
|
|
|
|
Before the \ac{bti} can be done, the branch history needs to be setup.
|
|
|
|
|
Only then the victim return can be executed using a system call.
|
|
|
|
|
|
|
|
|
|
\paragraph{Mitigation}
|
|
|
|
|
\label{para:retbleedMitigation}
|
|
|
|
|
In an early version of the \retbleed{} paper\cite{retbleed}, a mitigation called \ac{ibpb}-on-\ac{pf} was proposed.
|
|
|
|
|
It enforces isolation by preventing \ac{bti} from user to kernel space, using \ac{ibpb}.
|
|
|
|
|
As discusses in \autoref{para:btiOnKernelRet} and as we will see in more detail in \autoref{para:whyPf}, the mistraining causes a \ac{pf}.
|
|
|
|
|
As such \acp{pf} are not caused during normal execution, it is a reliable indication for such an attack\footnote{It seemed to be a good indication, however in this thesis we will show that this is not the case.}.
|
|
|
|
|
We have already introduced \ac{ibpb}-on-\ac{pf} as a possible mitigation in \autoref{sec:motivation} and \ref{sec:researchQuestions}.
|
|
|
|
|
While it enforces isolation by preventing \ac{bti} from user to kernel space, it is said to be incomplete.
|
|
|
|
|
|
|
|
|
|
It was shown that \ac{eibrs} mitigate \retbleed{}.
|
|
|
|
|
\ac{eibrs} was shown to mitigate \retbleed.
|
|
|
|
|
Therefore, more recent microarchitectures like Coffe Lake Refresh and Alder Lake are secure.
|
|
|
|
|
On older microarchitecture, where \ac{rsb}-to-\ac{btb} can be observed, and which do not support \ac{eibrs}, \ac{ibrs} is enabled.\cite{retbleedIntelMitigation,retbleed},
|
|
|
|
|
On older microarchitectures, where \ac{rsb}-to-\ac{btb} can be observed and which do not support \ac{eibrs}, \ac{ibrs} is enabled.~\cite{retbleedIntelMitigation,retbleed}
|
|
|
|
|
|
|
|
|
|
While Intel takes the route of isolation, AMD prevents the speculation from happening altogether.
|
|
|
|
|
Their mitigation, called \techterm{jmp2ret}, replaces all return instructions in the kernel with jumps to a return thunk.
|
|
|
|
|
The last remaining return instruction is secured by an \techterm{untrain} procedure.\cite{retbleedAmdMitigation,retbleed}
|
|
|
|
|
An \techterm{untrain} procedure secures the last remaining return instruction.~\cite{retbleedAmdMitigationI,retbleedAmdMitigationII,retbleed}
|
|
|
|
|
|
|
|
|
|
\todo{Abgleichen mit Discussion at the end}
|
|
|
|
|
\todo{How does AMD mitigate the issue}
|
|
|
|
|
|
