proper format; strip unfinished content

src/docs/parts/research_and_development/research_and_development.tex

@@ -349,10 +349,11 @@ The results are summarized in \cref{enc}.
 \section{Porting \glsentrytext{C} Vulnerabilities}
 \label{rnd::weakness-mitig-prev::porting-c-vulns}
 
-In this chapter, the weakness manifestations given in \cref{context::weaknesses-mem-safety::manifestations} are rewritten in \gls{Rust} to examine if these are mitigated just by porting them.
-This is done incrementally by first porting the vulnerability to unsafe Rust, followed by a rewrite to drop all unsafe code but keeping the intended functionality.
+Unlike originally anticipated, the vulnerabilities were not manually ported to Rust.
+Instead, the investigation of \cnameref{rnd::weakness-mitig-prev::stack-protection} and \cnameref{rnd::imezzos-preemptive-multitasking} was extended.
+
+However, \citeauthor{Beingessner2015} was able to identify an underlying pattern of the violation of implicitly trusted invariants a common cause for same-type weaknesses as listed in \cnameref{context::weaknesses-mem-safety::manifestations::cwe-ex}.
 
-- TODO official CWE-119 examples
 
 \section{Stack Protection}
 \label{rnd::weakness-mitig-prev::stack-protection}
@@ -432,14 +433,15 @@ ret
 \label{code::context::examples::sf-modification-simple-c-asm}
 \end{figure}
 
-\Cref{TODO-callstack-manipulation} is an attempt to visualize what happens in memory and with the \gls{stack} and the \gls{cpu}'s RIP {64-Bit Instruction Pointer} register.
-
-\begin{figure}
-    \includegraphics[width=\textwidth]{gfx/TODO-callstack-manipulation}
-    \caption{TODO-callstack-manipulation}
-    \label{TODO-callstack-manipulation}
-\end{figure}
-\FloatBarrier
+% \Cref{fig:callstack-manipulation} is an attempt to visualize what happens in memory and with the \gls{stack} and the \gls{cpu}'s RIP {64-Bit Instruction Pointer} register.
+% 
+% \begin{figure}
+% TODO
+%     \includegraphics[width=\textwidth]{gfx/TODO-callstack-manipulation}
+%     \caption{fig:callstack-manipulation}
+%     \label{fig:callstack-manipulation}
+% \end{figure}
+% \FloatBarrier
 
 \paragraph{Compiler Hardening - Placing A Canary Value}
 The manipulation can be mitigated on \gls{C} using the \code{-fstack-protection-all} option with the \gls{clang}.
@@ -795,11 +797,11 @@ This one includes the previous findings and suggestions on how this information
 Dynamically sized stack variables have been omitted from the table since they are irrelevant.
 On stack variable-length-arrays and variadic arguments are not supported by \gls{Rust}, and there is no indication of other use-cases.
 
-\chapter{\glsentrytext{LX} Modules Written In \glsentrytext{Rust}}
-The numerous \gls{LX} vulnerabilities are a great motivator for using \gls{Rust} for \gls{LX} drivers.
-This chapter presents the attempt to use \gls{Rust} for a simple buffer that is presented to userspace as a character device.
-
-- TODO: explain the difficulty to use the Kernel's C Macros, which are required to expose a character device
+% \chapter{\glsentrytext{LX} Modules Written In \glsentrytext{Rust}}
+% The numerous \gls{LX} vulnerabilities are a great motivator for using \gls{Rust} for \gls{LX} drivers.
+% This chapter presents the attempt to use \gls{Rust} for a simple buffer that is presented to userspace as a character device.
+% 
+% - TODO: explain the difficulty to use the Kernel's C Macros, which are required to expose a character device
 
 \chapter{Existing \glsentrytext{os}-Development Projects Based On Rust}
 \label{rnd::existing-os-dev-with-rust}
@@ -811,49 +813,43 @@ In addition to presenting their content, the author's tangible influence on the
 As Rust is a relatively young language, the selection of research papers relevant for this study is limited.
 This is likely due to the fact that Rust hasn't been stabilized until May 15, 2015\footnote{\url{May 15, 2015}}, and relied on a runtime gargabe-collector for a long time of it's pre-stable existence.
 
-\subsection{
-    \citetitle{Levy2015a}
-%    \cite{Levy2015a}
-}
-\citeauthor{Levy2015a} have been using Rust to develop a new embedded system \gls{os} for microcontrollers called Tock.
-They describe to find Rust's ownership model restricting by preventing safe resource sharing in embedded-typical event-based scenarios.
-They made suggestions to extend the langauge with Execution Contexts, which would "allow programs to mutably borrow values multiple times as long as those borrows are never shared between threads. Execution contexts allow the compiler to distinguish such sharing from actual errors using only local analysis."
-
-On their website the authors recently made the following statement:
-"After feedback from the Rust developers and the community, we were able to overcome those challanges without modifications to the language. We also learned that we understated how disruptive some of the changes we proposed would be to the language and do not believe they are worthwhile. This has been discussed extensively now in the Rust community. You should read this paper critically, not as conclusive scientific findings, but as the perspectives of the authors during a particular point in the development of Tock."\cite[/papers]{TockOS}
-
-\subsection{
-    \citetitle{Beingessner2015}
-%    \cite{Beingessner2015}
-}
-Covered in \cref{rnd::rust}
-
-\subsection{
-    \citetitle{Reed2015}
-%    \cite{Reed2015}
-}
-\subsection{
-    \citetitle{Getreu2016}
-    \cite{Getreu2016}
-}
-\subsection{
-    \citetitle{Balasubramanian2017}
-%    \cite{Balasubramanian2017}
-}
-\subsubsection{Software Fault Isolation}
-- TODO: content from \cite{Balasubramanian2017}
-\subsection{
-    \citetitle{Nilsson2017}
-%    \cite{Nilsson2017}
-}
+It was decided not to summarize the references, but rather explain the gained insight in particular detail at each relevant occurence.
 
 
-\section{Libraries}
+% \subsection{
+%     \citetitle{Levy2015a}
+%     \cite{Levy2015a}
+% }
 
-\subsection{Libfringe}
-% TODO: https://github.com/edef1c/libfringe
+% \paragraph{
+%     \citetitle{Beingessner2015}
+%     \cite{Beingessner2015}
+% }
+% 
+% \paragraph{
+%     \citetitle{Reed2015}
+%     \cite{Reed2015}
+% }
+% \paragraph{
+%     \citetitle{Getreu2016}
+%     \cite{Getreu2016}
+% }
+% \paragraph{
+%     \citetitle{Balasubramanian2017}
+%     \cite{Balasubramanian2017}
+% }
+% \paragraph{
+%     \citetitle{Nilsson2017}
+%     \cite{Nilsson2017}
+% }
 
 
+% \section{Libraries}
+% 
+% \subsection{Libfringe}
+% % TODO: https://github.com/edef1c/libfringe
+% 
+% 
 \section{Systems}
 Most of the presented systems target the \gls{amd64} architecture; Tock OS, which is targeted towards an ARM variant, is the only exception.
 The interesting parts of each \gls{os} are their origin, intentions, their current state, the level of memory-safety, and what design or language features made this level possible.
@@ -986,8 +982,15 @@ The main author of Redox OS has become an active contributor to the Rust languag
 The biggest achievement from the perspective of this study is the successful integration into Rust's libstd, which happened continuously and cannot be referenced easily.
 This allows programmers to use Rust with all it's features to develop programs for Redox OS.
 
-% \subsection{Tock OS}
-% Tock OS is "an embedded operating system designed for running multiple concurrent, mutually distrustful applications on low-memory and low-power microcontrollers."\cite{TockOS}
+\subsection{Tock OS}
+Tock OS is "an embedded operating system designed for running multiple concurrent, mutually distrustful applications on low-memory and low-power microcontrollers."\cite{TockOS}
+
+\citeauthor{Levy2015a} have been using Rust to develop a new embedded system \gls{os} for microcontrollers called Tock.
+They describe to find Rust's ownership model restricting by preventing safe resource sharing in embedded-typical event-based scenarios.
+They made suggestions to extend the langauge with Execution Contexts, which would "allow programs to mutably borrow values multiple times as long as those borrows are never shared between threads. Execution contexts allow the compiler to distinguish such sharing from actual errors using only local analysis."
+
+On their website the authors recently made the following statement:
+"After feedback from the Rust developers and the community, we were able to overcome those challanges without modifications to the language. We also learned that we understated how disruptive some of the changes we proposed would be to the language and do not believe they are worthwhile. This has been discussed extensively now in the Rust community. You should read this paper critically, not as conclusive scientific findings, but as the perspectives of the authors during a particular point in the development of Tock."\cite[/papers]{TockOS}
 % 
 % \subsubsection{Task Model}
 % \subsubsection{Memory Management}
@@ -1095,7 +1098,7 @@ Any stack overflowing task is not scheduled anymore.
 The stack size is statically defined and is allocated globally by the compiler.
 
 The implementation uses no dynamic memory allocations, thus there was no experience gathered with managing dynamic memory within the \gls{os}.
-The global state references might be accessed by any defined task, e.g. allowing TODO
+The global state references might be accessed by any defined task, and require prohibition of unwanted access by at least making them \code{unsafe} mandatory.
 
 
 \section{System Clock Driver}