IMPROVE: many minor things

chapters/10-introduction.tex

@@ -62,5 +62,3 @@ Preliminary information is given in \autoref{cha:background}.
 In \autoref{cha:specRetbleed}, we try to answer \rqref{rq1} by developing \speccpbti.
 In \autoref{cha:retbleedMitigation}, we evaluate the overhead for the in-depth mitigation to answer \rqref{rq2}.
 We present related work in \autoref{cha:relatedWork} and conclude the thesis in \autoref{cha:conclusion}.
-
-\todo{Make sure all changes are reflected in overview!}

chapters/20-background.tex

@@ -4,11 +4,9 @@
 \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}.
+We continue with caches, their vulnerabilities, and attacks on them in \autoref{sec:cache}, followed by speculative execution and a discussion of various transient execution attacks (\ref{sec:specularExecution}).
 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}
 
@@ -257,7 +255,7 @@ Moreover, since there is a whole range of Spectre attacks, there is also no sing
 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 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 speculation}: $\Rightarrow$ Disclosure gadget cannot be executed speculatively.
     \item \techterm{Prevention of convert channel}: $\Rightarrow$ Stop leakage of microarchitectural traces.
         \begin{itemize}
             \item This is not feasible for the Linux Kernel.
@@ -282,7 +280,7 @@ To make the speculation work reliable, the \techterm{speculation window}, which
 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.
+If a disclosure 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={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}]
@@ -309,7 +307,7 @@ Nevertheless, even if called \ac{bcb}, it is not limited to them and can be used
 \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 injection 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 disclosure 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'+.
@@ -364,9 +362,9 @@ 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.
+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 disclosure 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.
+Therefore, the disclosure gadget has to reside in kernel space.
 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}.
 
@@ -398,6 +396,4 @@ On older microarchitectures, where \ac{rsb}-to-\ac{btb} can be observed and whic
 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.
 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}
+Some more details on the mitigation is given in \autoref{sec:discussion}, where we discuss mitigation overheads.

chapters/34-specRetBti.tex

@@ -79,7 +79,7 @@ It allows us to modify the stack depending on whether we are in the training or
 The rogue function is displayed in \autoref{lst:roguePrimitive}, and the control flow of both, training and speculation phase, are depicted in \autoref{fig:specRetbti}.
 
 When returning to \verb+BR1+ from the rogue function, the \ac{pc} and \ac{bhb} are equal to the ones of the training phase.
-Therefore, the predictor will use the malicious entry to guide the speculative control flow of the return instruction to the gadget at \verb+TRAIN+.
+Therefore, the predictor will use the malicious entry to guide the speculative control flow of the return instruction to the disclosure gadget at \verb+TRAIN+.
 
 \begin{lstlisting}[style=CStyle,caption={Rogue function, causing a speculation window by employing SpectreRSB. This function must be executed in both phases to maintain a consistent branch history. Depending on the state of \lstinline+\%rsi+ the \lstinline+cmove+ instruction increments the \lstinline+\%rsp+ by $8$, skipping the actual return address. The speculation window is enlarged by using the \lstinline+clflush+ instruction.},label={lst:roguePrimitive}]
 asm(

chapters/35-specCpBti.tex

@@ -17,7 +17,7 @@ A return cycle is set up to spin on \verb+KBR_SRC'+.
 The final return leads to \verb+KBR_DST+.
 \verb+KBR_DST+ is the location of the disclosure gadget stored in the kernel space.
 Since a jump to an arbitrary location in kernel space is prohibited, the \ac{pf} handler takes over, raises a \ac{pf}, and informs the user.
-Even if the branch to the gadget was unsuccessful, it has still influenced the \ac{btb} by injecting an entry.
+Even if the branch to the disclosure gadget was unsuccessful, it has still influenced the \ac{btb} by injecting an entry.
 \autoref{fig:cpBtiTrain} shows the training phase which we have just described.
 The speculation phase, which we will discuss next, is depicted in \autoref{fig:cpBtiSpec}.
 
@@ -76,7 +76,7 @@ To make the branch history similar to the one of the training phase, we need to
 This is done by the ``dummy'' function at \verb+FAKE_ROGUE+, which does nothing but returning back to \verb+KBR_SRC+.
 Here, we encounter the victim return.
 Since the return target predictor has fallen back to the \ac{btb}, the \ac{pc} collides with the source of the injected branch, and the history is similar to the one during training, the injected \ac{btb} entry will be used for the branch prediction resolution.
-Therefore, the gadget stored at \verb+KBR_DST+ is executed speculatively.
+Therefore, the disclosure gadget stored at \verb+KBR_DST+ is executed speculatively.
 The training phase is shown in \autoref{fig:specCpBtiSpec}.
 
 We have developed a \speccpbti{} version for AMD too.

preamble.tex

@@ -25,7 +25,7 @@
 \usepackage[margin=1in]{geometry}
 \newcommand{\hint}[1]{{\color{blue} \em #1}}
 
-%\newcommand*{\PRINTTODO}{}
+\newcommand*{\PRINTTODO}{}
 
 \newcommand{\todo}[1]{
     \textcolor{red}{TODO: #1}