IMPROVE: Related Work, Conclusion and more

acronyms.tex

@@ -6,6 +6,10 @@
     short = BHB,
     long = \techterm{Branch History Buffer}
 }
+\DeclareAcronym{bhi}{
+    short = BHI,
+    long = \techterm{Branch History Injection}
+}
 \DeclareAcronym{bpu}{
     short = BPU,
     long = \techterm{Branch Prediction Unit}

chapters/00-abstract.tex

@@ -11,16 +11,16 @@
 Speculation and branch prediction are inevitable design principles for modern and fast processors.
 However, Spectre and an ever-increasing number of Spectre-like attacks have shown the security vulnerabilities induced by these features.
 \retbleed{} has recently been added to the list of such vulnerabilities.
-As \retbleed's \ac{bti} method triggers \aclp{pf}, \retbleed{} was considered detectable and mitigatable in the system's \acl{pf} handler.\todo{Does mitigatable exists?}
+As \retbleed's \ac{bti} method triggers \aclp{pf}, \retbleed{} was considered detectable and mitigatable in the system's \acl{pf} handler.
 
-In this thesis, we evaluate speculative \ac{bti} on various microarchitectures.
-We show that it can be used to poison the \acl{btb} across privilege boundaries without raising any \aclp{pf}.
-Based on these insights, we introduce a new variant of \retbleed{} that uses speculative \ac{bti}, resulting in a \acl{pf}-free variant of \retbleed. \todo{PF-free how to format?}
+In this thesis, we evaluate speculative \ac{bti} on various microarchitectures and show that it can be used to poison the \acl{btb} across privilege boundaries without raising any \aclp{pf}.
+To the best of our knowledge, this has never been explicitly shown before.
+Based on these insights, we introduce a new variant of \retbleed{} that uses speculative \ac{bti}, resulting in a \acl{pf}-free variant of \retbleed.
 The successful development of this variant confirms that \retbleed{} cannot be mitigated in the \acl{pf} handler of the system and that more in-depth solutions are required.
 
 In-depth mitigations are necessary to secure the CPU, which will likely affect performance significantly.
 We have benchmarked the patches to evaluate the induced overhead.
-While the overhead depends on the microarchitectures, it lies in the range of \SIrange{999}{999}{\percent}.\todo{Add correct overhead}
+While the overhead depends on the microarchitectures, it lies in the range of \SIrange{13}{37}{\percent}.
 
 \vfil
 \clearpage

chapters/20-background.tex

@@ -232,7 +232,7 @@ Once we return, the top address of the \ac{rsb} is popped, and we speculatively
 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.
-\citeauthor{retbleed} have shown that certain microarchitectures fall back on using the \ac{btb}.~\cite{retbleed,rsbUnderflow}
+\citeauthor{retbleed} have shown that certain microarchitectures fall back on using the \ac{btb}~\cite{retbleed}.
 We will look more closely at this behavior in \autoref{subsubsec:retbleed}.
 
 \subsection{Spectre Attacks}
@@ -245,7 +245,7 @@ By influencing the \techterm{transient code}, attackers can control what data to
 That is not just limited to data of the current user, but a wide variety of attacks work across privilege boundaries.
 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:
+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.

chapters/32-overview.tex

@@ -22,6 +22,8 @@ As a user is not allowed to jump to an arbitrary location in kernel space, a \ac
 \paragraph{The Plan.}
 As stated in \rqref{rq1}, we want to create a speculation primitive which does the described \ac{bti} without causing a \ac{pf}.
 Our idea is to do speculative \ac{bti}, meaning that the poisonous branch of the speculation primitive is itself executed speculatively.
-If speculative \ac{bti} works\footnote{To the best of our knowledge, this has never been explicitly shown before.}, the speculatively executed branch is picked up by the \ac{btb} without raising any \acp{pf}.
+To the best of our knowledge, this has never been explicitly shown before.
+Therefore, we need to verify its operability first.
+We expect from speculative \ac{bti} that it poisons the \ac{btb}, however, without raising any \acp{pf}, even for branches crossing privilege boundaries.
 This leads us to the development of a speculative version of the \cpbti{} \ac{poc}.
 We will discuss the creation of the \acp{poc} for both Intel and AMD in the next section.

chapters/70-relatedWork.tex

@@ -6,26 +6,35 @@
 %It is often a good idea to categorize previous work in different topics that relate to your work.
 %If we refer to another paper, book, website, \dots we add a citation~\cite{Lamport:LaTeX}.
 
-This thesis builds on top of the results and findings of various papers.
+This thesis builds on the results and findings of various papers.
 They are all cited in the appropriate places.
-Most notably, it was influenced by the work of \retbleed\cite{retbleed} as it laid the foundation for this thesis and inspired us to evaluate speculative \ac{bti} in the first place.
+First and foremost, this paper builds on the discoveries of Spectre~\cite{spectre}.
+However, \retbleed~\cite{retbleed} has inspired us to evaluate speculative \ac{bti}.
 
-We want to use this section to allude to a few papers we have not had the chance to introduce yet and which we find interesting or relevant.
+We want to use this section to comment on a few papers we have not had the chance to introduce yet and which we find interesting or relevant.
 
-During the research on \retbleed{}, Johannes Wikner et al. discovered a new class of speculative executing attacks, which they refer to as \textsc{Phantom} JMPs\cite{retbleedAddendum}.
-\textsc{Phantom} JMPs are speculative branches triggered by a non-branching instruction, like, for example, an arithmetic instruction.
-They are exploited due to a prediction mechanism that predicts before the instruction is decoded if it is a branching instruction.
-By tricking that mechanism into believing that at a specific location, there is a branch, a speculative branch can be triggered.
+\paragraph{Phantom JMPs.}
+During the research on \retbleed, \citeauthor{retbleed} discovered a new class of speculative executing attacks, which they refer to as \textsc{Phantom} JMPs~\cite{retbleedAddendum}.
+\textsc{Phantom} JMPs are speculative branches triggered by a non-branching instruction, such as an arithmetic instruction.
+They exploit a prediction mechanism that prediction, before the instruction has been decoded, if the instruction is a branching instruction and where it possibly jumps to.
+By tricking that predictor into assuming that at a particular location, there is a branch, the speculative control flow can be hijacked.
 They showed that AMD Zen 1, Zen 1+ and Zen 2 are affected.
-\textsc{Phantom} JMPs were mitigated with the same patches that mitigate \retbleed.\cite{retbleedAmdMitigation,retbleedAddendum}
+\textsc{Phantom} JMPs were mitigated with the same patches that mitigate \retbleed~\cite{retbleedAmdMitigationI,retbleedAddendum}.
 
-Another interesting spectre attack, targeting solely Arm CPUs, is \ac{sls}\cite{straightLineSpeculation}.
-\ac{sls} differs from \retbleed{} and most spectre vulnerabilities we have looked at in the way that it does not rely on misprediction of the branch prediction unit but exploits a strange behavior of the \ac{bpu} itself.
+\paragraph{Straight Line Speculation.}
+Another interesting Spectre vulnerability, targeting Arm and AMD CPUs, is \ac{sls}~\cite{straightLineSpeculation}.
+\ac{sls} differs from \retbleed{} and most Spectre vulnerabilities we have looked at in that it does not rely on misprediction of the branch prediction unit but exploits a strange behavior of the \ac{bpu} itself.
 When encountering an unconditional branching instruction, the \ac{bpu} predicts that the control flow continues as there was no branching instruction.
-This also applies to return instructions.
-When an attacker can control the executed code, it can place gadget code after such an instruction.
-If successfully, the gadget gets executed speculatively.
+This behavior also appears for return instructions.
+When an attacker can control the executed code, it can place a disclosure gadget after such an instruction.
+If successful, the disclosure gadget gets executed speculatively, causing the possible leakage of data.
 While hard to exploit, it has been mitigated.
-First compilers like GCC\cite{straightLineSpeculationMitigationGcc} and LLVM\cite{straightLineSpeculationMitigationLlvm} were patched, and later on also in the Linux kernel\cite{straightLineSpeculationMitigationKernel}.
+First compilers like GCC~\cite{straightLineSpeculationMitigationGcc} and LLVM~\cite{straightLineSpeculationMitigationLlvm} were patched, and later on, the Linux kernel~\cite{straightLineSpeculationMitigationKernel}.
 The idea of the mitigation is simple.
-A speculation barrier, for example, the debug instruction \verb+int3+, is added after affected branching instruction.
+A speculation barrier, for example, the debug instruction \verb+int3+, is added after an affected branching instruction.
+
+\paragraph{Branch History Injection.}
+\ac{bhi}~\cite{bhi}, an extension of Spectre V2, has recently been published.
+\citeauthor{bhi} have shown that hardware mitigation employed specifically for Spectre attacks, like \ac{eibrs}~\cite{ibrs} and CSV2~\cite{armFeatures}, can be circumvented, enabling an attacker to conduct Spectre V2 attacks.
+These hardware mitigations work by keeping track of the privilege level where a branch is executed, using global history.
+However, an attacker is can tamper with the history from user space to cause speculative execution of a disclosure gadget.

chapters/80-conclusion.tex

@@ -6,15 +6,15 @@
 %Think about why the world is a better place after your work.
 
 We have developed a version of \retbleed's \cpbti{} primitive for Intel, which does not rely on \ac{pf}.
-By doing that, we have shown that the \ac{ibpb}-on-\ac{pf} mitigation is insufficient in fixing the vulnerability and that in-depth patches are appropriate.
+This \ac{poc} demonstrates that the \ac{ibpb}-on-\ac{pf} mitigation is insufficient in fixing the vulnerability and that in-depth patches are required.
 In the course of developing the \ac{pf}-free primitive, we have shown that speculative \ac{bti} works.
-We have developed PoCs for both Intel and AMD, which demonstrate that Spec \ac{bti} works in the same privilege domain, and for Intel, we were also able to show it is working across privilege boundaries.
-We could not get the speculative \cpbti{} to work for AMD.
-The confirmation if speculative \ac{bti} works for AMD across privilege boundaries too, may serve as a good starting point for future research.
+We have developed \acp{poc} for both Intel and AMD, which demonstrate that Spec \ac{bti} works in the same privilege domain, and for Intel, we were also able to show it is working across privilege boundaries.
+The \speccpbti{} \ac{poc} for AMD did not perform as expected.
+Further investigation is needed to know whether our findings based on the Intel microarchitecture transfer to AMD microarchitectures.
 
 To the best of our knowledge, the idea of using speculation to cause another speculation is new.
-Therefore, we regard it as inevitable to further reason about the possible consequence this principle may induce, as it may lead to the discovery of new vulnerabilities of the \ac{bpu} are flaws with preexisting patches.
+We believe this novel approach might prove useful in the discovery of unknown vulnerabilities of the \ac{bpu}.
 
 By benchmarking the mitigation, we were able to show that common microarchitectures suffer from \SIrange{13}{37}{\percent} performance penalty when ultimately mitigating \retbleed.
-As this is substantial overhead, we support the development of alternative mitigations like the ones from Thomas Gleixner et al.\cite{retbleedNewMitigation}.
-Alternatively, one might consider a different mitigation techniques like preventing convert channels altogether\cite{preventConvertChannel}.
+As this is substantial overhead, we support the development of alternative mitigations like the ones from \citeauthor{retbleedNewMitigation}~\cite{retbleedNewMitigation}.
+Alternatively, one might consider different mitigation techniques like preventing convert channels altogether~\cite{preventConvertChannel}.

chapters/89-acknowledgements.tex

@@ -6,11 +6,17 @@
 \thispagestyle{plain}
 \begin{center}\textbf{Acknowledgements}\end{center}
 
-I want to thank all the people who have supported me during the course of writing this bachelor thesis.
-
-My tutor, \tutorName, who introduced me to the topic and guided me along the way. For his support and the sharing of insight and knowledge on the matter.
-
-My supervisor, \supervisorName, to enable to me to work on this exciting thesis at his group\cite{ComSec}, and for his suggestions, hints and explanations at the regular meeting.
+\begin{flushleft}
+    I want to thank all the people who have supported me while writing my bachelor thesis.
+    \medbreak
+    My tutor, \tutorName, who introduced me to the topic and guided me along the way.
+    For his support and the sharing of insight and knowledge on the matter.
+    \medbreak
+    My supervisor, \supervisorName, to enable to me to work on this exciting thesis at his group~\cite{comSec}.
+    For his suggestions, hints and explanations at the regular meeting.
+    \medbreak
+    Dr. Hendrik Dietrich for proofreading and feedback on the thesis.
+\end{flushleft}
 
 \vfil
 \clearpage

refs.bib

@@ -151,6 +151,7 @@
   urldate      = "2022-07-26",
 }
 
+%% Revers engineering related to spectre
 @Online{projectZero,
   author       = "{Project Zero Team}",
   title        = "Reading privileged memory with a side-channel",
@@ -159,6 +160,19 @@
   urldate      = "2022-07-26",
 }
 
+@InProceedings{bhi,
+  author       = "Enrico Barberis and Pietro Frigo and Marius Muench and
+                 Herbert Bos and Cristiano Giuffrida",
+  title        = "Branch {History} {Injection}: {On} the {Effectiveness}
+                 of {Hardware} {Mitigations} {Against}
+                 {Cross}-{Privilege} {Spectre}-v2 {Attacks}",
+  URL          = "Paper=http://download.vusec.net/papers/bhi-spectre-bhb_sec22.pdf
+                 Web=https://www.vusec.net/projects/bhi-spectre-bhb
+                 Code=https://github.com/vusec/bhi-spectre-bhb",
+  booktitle    = "{USENIX} {Security}",
+  date         = "2022-08",
+}
+
 %%%
 % Retbleed
 %%%
@@ -246,6 +260,15 @@ https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1037
   urldate      = "2022-07-25",
 }
 
+%% ARM hardware mitigation mechanisms
+@Manual{armFeatures,
+  author       = "{Arm}",
+  title        = "Feature names in A-profile architecture",
+  date         = "2021",
+  URL          = "https://developer.arm.com/downloads/-/exploration-tools/feature-names-for-a-profile",
+  urldate      = "2022-08-20",
+}
+
 %%%
 % Cache Attacks
 %%%