proper format; strip unfinished content

This commit is contained in:
steveej 2017-09-29 18:09:13 +02:00
parent 427ef068c5
commit cae041727d
10 changed files with 291 additions and 331 deletions

View file

@ -79,54 +79,6 @@ fn passthrough(a: isize) -> isize {
} }
#[inline(never)] #[inline(never)]
fn caller() { fn r();
let a = passthrough(1); println!("main exiting")
let b = a * 2; }
printer(&a, &b);
}
#[inline(never)]
fn printer(a: &isize, b: &isize) {
println!("2*{}={}", a, b)
}
#[inline(never)]
fn modifier() {
let v: usize = 0;
let v_addr = (&v as *const usize) as usize;
unsafe {
*((v_addr + 1 * 8) as *mut usize) = simple_printer as usize;
}
}
#[naked]
fn simple_printer() {
eprint!("I wonder who called me?");
}
#[inline(never)]
fn huge_stack() {
const SLICE_LENGTH: usize = 0x100000000;
let slice: [u64; SLICE_LENGTH] = [0xdeadbeef; SLICE_LENGTH];
let slice_start_addr = &slice[0] as *const u64;
let slice_end_addr = &slice[SLICE_LENGTH - 1] as *const u64;
println!("{:?} - {:?} = {:?}",
slice_start_addr,
slice_end_addr,
(slice_end_addr as usize - slice_start_addr as usize) / std::mem::size_of::<usize>());
}
// fn recurse(n: u64) {
// recurse(n + 1);
// }
fn a() { a(); }
fn main() { a(); }
// fn main() {
// // modifier();
// huge_stack();
// println!("main exiting")
// }

View file

@ -1,3 +1,4 @@
% // vim: set ft=tex:
\begin{center} \begin{center}
{\Large \textbf{Abstract}} {\Large \textbf{Abstract}}
\end{center} \end{center}
@ -13,9 +14,9 @@
Supervisors: & \supervisorOne \\[.5ex] Supervisors: & \supervisorOne \\[.5ex]
& \supervisorTwo\\ & \supervisorTwo\\
& \\ & \\
Submition: & \submitdate \\ Submission: & \submitdate \\
& \\ & \\
Buzzwords: & \buzzwords \\ Categories: & \buzzwords \\
& \\ & \\
\end{tabular} \end{tabular}
\end{center} \end{center}
@ -23,4 +24,4 @@
\bigskip \bigskip
\noindent \noindent
TODO: abstract goes here \abstract

26
src/docs/affidavit.tex Normal file
View file

@ -0,0 +1,26 @@
% // vim: set ft=tex:
\chapter*{Ehrenwörtliche Erklärung}
Hiermit erkläre ich, {\authorOne}, geboren am {\authorOneBirthDate} in {\authorOneBirthCity},
\begin{enumerate}
\item{
dass ich meine Masterarbeit mit dem Titel:
{"\topic"}
in der Fakultät Informatik unter Anleitung von Professor {\supervisorOne} und ohne fremde Hilfe angefertigt habe und keine anderen als die angeführten Hilfen benutzt habe;
}
\item{
dass ich die Übernahme wörtlicher Zitate, von Tabellen, Zeichnungen, Bildern und Programmen aus der Literatur oder anderen Quellen (Internet) sowie die Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen innerhalb der Arbeit gekennzeichnet habe;
}
\item{
dass die eingereichten Abgabe-Exemplare in Papierform und im PDF-Format vollständig übereinstimmen.
}
\end{enumerate}
Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
\vspace{4cm}
Konstanz, 29.9.2017\hspace{5cm} \authorOne

26
src/docs/cover.tex Normal file
View file

@ -0,0 +1,26 @@
\begin{titlepage}
\vspace*{-1.0cm}
\begin{centering}
\includegraphics[width=\textwidth]{gfx/htwg-logo.pdf}
\end{centering}
\vspace{1.5cm}
\begin{center}
\huge{
\textbf{\topic} \\[4cm]
}
\Large{
\textbf{\authorOne}} \\[5.5cm]
\large{
\textbf{Konstanz, \submitdate} \\[2.3cm]
}
\Huge{
\textbf{{\textsf Masterarbeit}}
}
\end{center}
\end{titlepage}

BIN
src/docs/gfx/htwg-logo.pdf Normal file

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

View file

@ -405,90 +405,62 @@ Therefore most systems use a hierarchy of page tables.
Using a hierarchical translation structure allows to save significant amounts of memory, as not every page-table of every level in the address space has to be allocated and present in main memory. Using a hierarchical translation structure allows to save significant amounts of memory, as not every page-table of every level in the address space has to be allocated and present in main memory.
% TODO picture this % TODO picture this
\begin{figure} % \begin{figure}
\centering % \centering
\includegraphics[width=\textwidth]{gfx/TODO-nlevel-paging} % \includegraphics[width=\textwidth]{gfx/TODO-nlevel-paging}
\begin{tikzpicture} % \begin{tikzpicture}
\def\x{9ex} % \def\x{9ex}
% memory cells % % memory cells
\path[draw,font=\small] % \path[draw,font=\small]
% cells % % cells
(0,0) % (0,0)
rectangle ++(\x, 1) % rectangle ++(\x, 1)
rectangle ++(\x,-1) % rectangle ++(\x,-1)
rectangle ++(\x, 1) % rectangle ++(\x, 1)
rectangle ++(\x,-1) % rectangle ++(\x,-1)
rectangle ++(\x, 1) % rectangle ++(\x, 1)
% cell text % % cell text
(0.5*\x,0.5) % (0.5*\x,0.5)
node(text-a){idx$_n$} ++(\x,0) % node(text-a){idx$_n$} ++(\x,0)
node(text-b){idx$_{n-1}$} ++(\x,0) % node(text-b){idx$_{n-1}$} ++(\x,0)
node(text-c){...} ++(\x,0) % node(text-c){...} ++(\x,0)
node(text-d){idx$_1$} ++(\x,0) % node(text-d){idx$_1$} ++(\x,0)
node(text-e){offset$_{page}$}++(\x,0) % node(text-e){offset$_{page}$}++(\x,0)
% bit numbers % % bit numbers
(0,1) % (0,1)
node[anchor=south]{63} % node[anchor=south]{63}
(5*\x,1) % (5*\x,1)
node[anchor=south]{0} % node[anchor=south]{0}
; % ;
% braces % % braces
\foreach \y in {1,...,5} { % \foreach \y in {1,...,5} {
\pgfmathparse{\y-1} % \pgfmathparse{\y-1}
\draw[decorate,decoration={brace,mirror}] % \draw[decorate,decoration={brace,mirror}]
($(\pgfmathresult*\x,-1ex)!0.1!(\y*\x,-1ex)$) -- node[shape=coordinate](brace-\y){} % ($(\pgfmathresult*\x,-1ex)!0.1!(\y*\x,-1ex)$) -- node[shape=coordinate](brace-\y){}
($(\pgfmathresult*\x,-1ex)!0.9!(\y*\x,-1ex)$); % ($(\pgfmathresult*\x,-1ex)!0.9!(\y*\x,-1ex)$);
} % }
%
\draw % \draw
% cells % % cells
(0*\x,-1*\x) % (0*\x,-1*\x)
rectangle ++( \x, 0.5*-1) % rectangle ++( \x, 0.5*-1)
rectangle ++(-\x,-1) % rectangle ++(-\x,-1)
rectangle ++( \x, 0.5*-1) % rectangle ++( \x, 0.5*-1)
(1*\x,-3*\x) % (1*\x,-3*\x)
rectangle ++( \x, 0.5*-1) % rectangle ++( \x, 0.5*-1)
rectangle ++(-\x,-1) % rectangle ++(-\x,-1)
rectangle ++( \x, 0.5*-1) % rectangle ++( \x, 0.5*-1)
(2*\x,-5*\x) % (2*\x,-5*\x)
rectangle ++( \x, 0.5*-1) % rectangle ++( \x, 0.5*-1)
rectangle ++(-\x,-1) % rectangle ++(-\x,-1)
rectangle ++( \x, 0.5*-1) % rectangle ++( \x, 0.5*-1)
; % ;
%
% cell text % \end{tikzpicture}
% (0.5*\x,0.5) % \caption{Hierarchical Virtual Paging}
% node(text-a){idx$_n$} ++(\x,0) % \label{fig:paging-hierarchy-abstract}
% node(text-b){idx$_{n-1}$} ++(\x,0) % \end{figure}
% node(text-c){...} ++(\x,0) % \FloatBarrier
% node(text-d){idx$_1$} ++(\x,0)
% node(text-e){offset$_{page}$}++(\x,0)
% % bit numbers
% (0,1)
% node[anchor=south]{63}
% (5*\x,1)
% node[anchor=south]{0}
% ;
% \def\y{1}
% \pgfmathparse{\y-1}
% \draw[decorate,decoration={brace,mirror}]
% ($(\pgfmathresult,-1ex)!0.1!(\y*\x,-1ex)$) -- node[shape=coordinate](brace-\y){}
% ($(\pgfmathresult,-1ex)!0.9!(\y*\x,-1ex)$);
% \def\y{2}
% \pgfmathparse{\y-1}
% \draw[decorate,decoration={brace,mirror}]
% ($(\pgfmathresult*\x,-1ex)!0.1!(\y*\x,-1ex)$) -- node[shape=coordinate](brace-\y){}
% ($(\pgfmathresult*\x,-1ex)!0.9!(\y*\x,-1ex)$);
% \draw[decorate,decoration={brace,mirror}]
% ($(1*\x,-1ex)!0.1!(\x*2,-1ex)$) -- node[shape=coordinate](brace-2){}
% ($(1*\x,-1ex)!0.9!(\x*2,-1ex)$);
\end{tikzpicture}
\caption{Hierarchical Virtual Paging}
\label{fig:paging-hierarchy-abstract}
\end{figure}
\FloatBarrier
\subsection{Multi-Level Paging on AMD64} \subsection{Multi-Level Paging on AMD64}
\label{context::os-dev-concepts::hw-supported-mm::multilevel-paging-amd64} \label{context::os-dev-concepts::hw-supported-mm::multilevel-paging-amd64}
@ -623,7 +595,7 @@ Between properly cleaning up and loosing memory allocations is a whole range of
\label{context::os-dev-concepts::sf-handling-amd64} \label{context::os-dev-concepts::sf-handling-amd64}
The usage of the \gls{stack} is tightly coupled with control flow instructions in conjunction with two registers, the Stack-Frame Base Pointer (RBP) and the Stack Pointer (RSP). The usage of the \gls{stack} is tightly coupled with control flow instructions in conjunction with two registers, the Stack-Frame Base Pointer (RBP) and the Stack Pointer (RSP).
The instructions that use these registers and explicitly or implicitly work with the stack\cite[p.~83]{AMD64Vol1} can be grouped into the following categories. The instructions that use these registers and explicitly or implicitly work with the stack\cite[p.~83]{AMD64Vol1} can be grouped into the following categories.
Together they can be used to perform \gls{stack} based procedure calls, as demonstrated in the following \cref{context::os-dev-concepts::sf-handling-amd64::procedure-call-example}. Together they can be used to perform \gls{stack} based procedure calls, in \cref{context::stack-frame-management-instructions}.
\subsection{Direct Stack Data Management Instructions} \subsection{Direct Stack Data Management Instructions}
\code{push} a takes value operand which is to be pushed onto the stack. \code{push} a takes value operand which is to be pushed onto the stack.
@ -650,6 +622,7 @@ As \code{push} and \code{pop} use the RSP register, the called procedure is resp
For example, \code{push}ing some value onto the stack before the end of the function would cause the \code{ret} to jump to that address instead of returning to the caller. For example, \code{push}ing some value onto the stack before the end of the function would cause the \code{ret} to jump to that address instead of returning to the caller.
\subsection{Stack Frame Management Instructions} \subsection{Stack Frame Management Instructions}
\label{context::stack-frame-management-instructions}
When a procedure is called, the stack is set up with the \gls{sf}, the four components listed in \cref{lst:amd64-stack-frame-components}. When a procedure is called, the stack is set up with the \gls{sf}, the four components listed in \cref{lst:amd64-stack-frame-components}.
\cite[p.~48]{AMD64Vol1}: \cite[p.~48]{AMD64Vol1}:
@ -683,96 +656,93 @@ Instead, these \glspl{compiler} generate a sequence of \code{push}, \code{mov} a
There are instructions before and after the procedure's logic, taking care of the technicalities of \gls{stack} management. There are instructions before and after the procedure's logic, taking care of the technicalities of \gls{stack} management.
These instruction groups within the called procedure are called prologue and epilogue. These instruction groups within the called procedure are called prologue and epilogue.
\subsection{Full Procedure Call Example} % \subsection{Full Procedure Call Example}
\label{context::os-dev-concepts::sf-handling-amd64::procedure-call-example} % \label{context::os-dev-concepts::sf-handling-amd64::procedure-call-example}
This section combines the separate categories into one complete example that shows how the \gls{stack} is used by various \gls{cpu} instructions to perform procedure calls. % This section combines the separate categories into one complete example that shows how the \gls{stack} is used by various \gls{cpu} instructions to perform procedure calls.
The following code samples are extracted from a disassembled binary which was originally created using \gls{Rust}. % The following code samples are extracted from a disassembled binary which was originally created using \gls{Rust}.
The Assembler that's shown uses Intel Mnemonic, which generally operates from right to left. % The Assembler that's shown uses Intel Mnemonic, which generally operates from right to left.
For example, \code{mov a, b} copies b to a. % For example, \code{mov a, b} copies b to a.
%
% \cref{code::context::examples::func-callee-rust} shows the \gls{Rust} source code of the function \textit{sum}.
%
% \begin{listing}[htb]
% \tikzset{/minted/basename=callee-rust}
% \begin{minted}[autogobble,linenos,breaklines=true]{rust}
% TODO
% \end{minted}
% \caption{Procedure Call Example: Callee in Rust}
% \label{code::context::examples::func-callee-rust}
% \end{listing}
%
% \begin{listing}[htb]
% \tikzset{/minted/basename=callee-rust}
% \begin{minted}[autogobble,linenos,breaklines=true]{nasm}
% TODO
% \end{minted}
% \caption{Procedure Call Example: Callee in Assembly}
% \label{code::context::examples::func-callee-assembly}
% \end{listing}
%
% \Cref{code::context::examples::func-caller-asm} shows a snippet of the calling function.
% It stores the arguments within the registers according to the calling convention.
% The caller doesn't alter the stack-frame pointer (RBP) or the stack pointer (RSP) registers before call, hence the called function must restore these if it alters them.
%
% \begin{listing}
% \begin{minted}[escapeinside=??,highlightlines={},autogobble,linenos,breaklines=true]{nasm}
% TODO
% \end{minted}
% \caption{Procedure Call Example: Caller Assembly}
% \label{code::context::examples::func-caller-asm}
% \end{listing}
%
% \begin{listing}
% \begin{minted}[escapeinside=??,highlightlines={},autogobble,linenos,breaklines=true]{rust}
% \end{minted}
% TODO
% \caption{Procedure Call Example: Caller in Rust}
% \label{code::context::examples::func-caller-rust}
% \end{listing}
%
% % \balloon{comment}{
%
% % RDI, RSI, RDX, RCX, R8, R9, XMM07
%
% \begin{table}[ht!]
% \centering
% \begin{tabular}{ r | >{\columncolor{YellowGreen}}c | l }
% \multicolumn{1}{r}{RBP offset} & \multicolumn{1}{c}{Content} & \\
% $\uparrow$ & \cellcolor{white} & \\
% & \cellcolor{white} \dots \textit{beyond current stack} \dots & \\
% \hhline{~-~}
% 0 & \textit{Previous RSP} & $\leftarrow$ RBP \\
% \hhline{~-~}
% \vdots & \dots~~\textit{local variables}~~\dots & \\
% \hhline{~-~}
% -0x30 & 3rd arg & \\
% \hhline{~|-|~}
% -0x38 & 2nd arg & \\
% \hhline{~-~}
% -0x40 & 1st arg & \\
% \hhline{~-~}
% \vdots & \dots~~\textit{local variables}~~\dots & \\
% \hhline{~-~}
% -0x60 & rdi & \\
% \hhline{~-~}
% & \dots~~\textit{local variables}~~\dots & \\
% \hhline{~-~}
% $RBP-RSP$ & \textit{unknown} & $\leftarrow$ RSP \\
% \hhline{~-~}
% & \cellcolor{white} & \\
% $\downarrow$ & \cellcolor{white} & \\
% \end{tabular}
% \end{table}
%
% \cref{code::context::examples::func-prologue} shows \textit{sum}'s prologue.
% The corresponding epilogue is displayed in \cref{code::context::examples::func-epilogue}.
% The comments explain the code line by line, please read them to understand what exactly happens at each instruction.
\cref{code::context::examples::func-callee-rust} shows the \gls{Rust} source code of the function \textit{sum}. \Cref{code::context::examples::func-prologue,code::context::examples::func-epilogue} show assembly code of a callee's procedure pro- and epilogue.
Respectively, they show how the arguments are copied from the CPU registers onto the stack on entry, and the return value copied from the stack to the CPU register before return.
% \subsubsection{Top-Level Page Table Self-Reference}
% \subsubsection{Caching Lookups}
% \subsubsection{Full Example}
% * http://taptipalit.blogspot.de/2013/10/theory-recursive-mapping-page.html
% * https://www.coresecurity.com/blog/getting-physical-extreme-abuse-of-intel-based-paging-systems-part-2-windows
\begin{listing}[htb]
\tikzset{/minted/basename=callee-rust}
\begin{minted}[autogobble,linenos,breaklines=true]{rust}
TODO
\end{minted}
\caption{Procedure Call Example: Callee in Rust}
\label{code::context::examples::func-callee-rust}
\end{listing}
\begin{listing}[htb]
\tikzset{/minted/basename=callee-rust}
\begin{minted}[autogobble,linenos,breaklines=true]{nasm}
TODO
\end{minted}
\caption{Procedure Call Example: Callee in Assembly}
\label{code::context::examples::func-callee-assembly}
\end{listing}
\Cref{code::context::examples::func-caller-asm} shows a snippet of the calling function.
It stores the arguments within the registers according to the calling convention.
The caller doesn't alter the stack-frame pointer (RBP) or the stack pointer (RSP) registers before call, hence the called function must restore these if it alters them.
\begin{listing}
\begin{minted}[escapeinside=??,highlightlines={},autogobble,linenos,breaklines=true]{nasm}
TODO
\end{minted}
\caption{Procedure Call Example: Caller Assembly}
\label{code::context::examples::func-caller-asm}
\end{listing}
\begin{listing}
\begin{minted}[escapeinside=??,highlightlines={},autogobble,linenos,breaklines=true]{rust}
\end{minted}
TODO
\caption{Procedure Call Example: Caller in Rust}
\label{code::context::examples::func-caller-rust}
\end{listing}
% \balloon{comment}{
% RDI, RSI, RDX, RCX, R8, R9, XMM07
\begin{table}[ht!]
\centering
\begin{tabular}{ r | >{\columncolor{YellowGreen}}c | l }
\multicolumn{1}{r}{RBP offset} & \multicolumn{1}{c}{Content} & \\
$\uparrow$ & \cellcolor{white} & \\
& \cellcolor{white} \dots \textit{beyond current stack} \dots & \\
\hhline{~-~}
0 & \textit{Previous RSP} & $\leftarrow$ RBP \\
\hhline{~-~}
\vdots & \dots~~\textit{local variables}~~\dots & \\
\hhline{~-~}
-0x30 & 3rd arg & \\
\hhline{~|-|~}
-0x38 & 2nd arg & \\
\hhline{~-~}
-0x40 & 1st arg & \\
\hhline{~-~}
\vdots & \dots~~\textit{local variables}~~\dots & \\
\hhline{~-~}
-0x60 & rdi & \\
\hhline{~-~}
& \dots~~\textit{local variables}~~\dots & \\
\hhline{~-~}
$RBP-RSP$ & \textit{unknown} & $\leftarrow$ RSP \\
\hhline{~-~}
& \cellcolor{white} & \\
$\downarrow$ & \cellcolor{white} & \\
\end{tabular}
\end{table}
\cref{code::context::examples::func-prologue} shows \textit{sum}'s prologue.
The corresponding epilogue is displayed in \cref{code::context::examples::func-epilogue}.
The comments explain the code line by line, please read them to understand what exactly happens at each instruction.
\begin{listing}[ht!] \begin{listing}[ht!]
\begin{minted}[escapeinside=??,linenos=false,breaklines=true]{nasm} \begin{minted}[escapeinside=??,linenos=false,breaklines=true]{nasm}
@ -797,17 +767,18 @@ $74f7: ret ; return to the caller, following the add
\caption{Function Epilogue} \caption{Function Epilogue}
\label{code::context::examples::func-epilogue} \label{code::context::examples::func-epilogue}
\end{listing} \end{listing}
\cref{fig:proc-call-example-mem} displays
\begin{figure}
\centering
\includegraphics[width=0.95\textwidth]{gfx/call-procedure-memory-content.png}
\caption{Memory Layout Throughout The Procedure Call Steps}
\label{fig:proc-call-example-mem}
\end{figure}
\FloatBarrier \FloatBarrier
%\cref{fig:proc-call-example-mem} displays
%
%\begin{figure}
%\centering
%\includegraphics[width=0.95\textwidth]{gfx/call-procedure-memory-content.png}
%\caption{Memory Layout Throughout The Procedure Call Steps}
%\label{fig:proc-call-example-mem}
%\end{figure}
%\FloatBarrier
\section{Stack And Heap: Combined Usage} \section{Stack And Heap: Combined Usage}
\label{context::os-dev-concepts::stackheap-combined} \label{context::os-dev-concepts::stackheap-combined}
\Glspl{program} combine the usage of \gls{stack} and \gls{heap} use them for different purposes. \Glspl{program} combine the usage of \gls{stack} and \gls{heap} use them for different purposes.
@ -1457,7 +1428,7 @@ From today's perspective it appears to be clearly inferior to younger \gls{os} l
\section{LLVM: C and Rust} \section{LLVM: C and Rust}
The \glsentrydesc{llvm} has become popular since it was introduced. The \glsentrydesc{llvm} has become popular since it was introduced.
To demonstrate this, \cref{fig:llvm-research-papers-since-2002}\footnote{\url{TODO https://llvm.org/pubs/}} shows a statistic on how many research papers have been published yearly since 2002. To demonstrate this, \cref{fig:llvm-research-papers-since-2002}\footnote{\url{https://llvm.org/pubs/}} shows a statistic on how many research papers have been published yearly since 2002.
\begin{figure}[ht!] \begin{figure}[ht!]
\centering \centering

View file

@ -349,10 +349,11 @@ The results are summarized in \cref{enc}.
\section{Porting \glsentrytext{C} Vulnerabilities} \section{Porting \glsentrytext{C} Vulnerabilities}
\label{rnd::weakness-mitig-prev::porting-c-vulns} \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. Unlike originally anticipated, the vulnerabilities were not manually ported to Rust.
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. 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} \section{Stack Protection}
\label{rnd::weakness-mitig-prev::stack-protection} \label{rnd::weakness-mitig-prev::stack-protection}
@ -432,14 +433,15 @@ ret
\label{code::context::examples::sf-modification-simple-c-asm} \label{code::context::examples::sf-modification-simple-c-asm}
\end{figure} \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. % \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} % \begin{figure}
\includegraphics[width=\textwidth]{gfx/TODO-callstack-manipulation} % TODO
\caption{TODO-callstack-manipulation} % \includegraphics[width=\textwidth]{gfx/TODO-callstack-manipulation}
\label{TODO-callstack-manipulation} % \caption{fig:callstack-manipulation}
\end{figure} % \label{fig:callstack-manipulation}
\FloatBarrier % \end{figure}
% \FloatBarrier
\paragraph{Compiler Hardening - Placing A Canary Value} \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}. 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. 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. 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}} % \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. % 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. % 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 % - 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} \chapter{Existing \glsentrytext{os}-Development Projects Based On Rust}
\label{rnd::existing-os-dev-with-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. 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. 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{ It was decided not to summarize the references, but rather explain the gained insight in particular detail at each relevant occurence.
\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}
}
\section{Libraries} % \subsection{
% \citetitle{Levy2015a}
% \cite{Levy2015a}
% }
\subsection{Libfringe} % \paragraph{
% TODO: https://github.com/edef1c/libfringe % \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} \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. 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. 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. 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. This allows programmers to use Rust with all it's features to develop programs for Redox OS.
% \subsection{Tock 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} 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{Task Model}
% \subsubsection{Memory Management} % \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 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 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} \section{System Clock Driver}

View file

@ -1,6 +1,8 @@
% // vim: set ft=tex:
\documentclass[12pt,a4paper]{report} \documentclass[12pt,a4paper]{report}
\overfullrule=5mm %\overfullrule=5mm
\overfullrule=1cm
\usepackage[utf8]{inputenc} \usepackage[utf8]{inputenc}
@ -78,6 +80,18 @@
\newcommand{\startdate}{2017/4/1} \newcommand{\startdate}{2017/4/1}
\newcommand{\submitdate}{2017/9/29} \newcommand{\submitdate}{2017/9/29}
\newcommand{\buzzwords}{memory-safety, operating system development, rust, static software analysis, software vulnerability} \newcommand{\buzzwords}{memory-safety, operating system development, rust, static software analysis, software vulnerability}
\renewcommand{\abstract}{%
This study evaluated Rust's guarantees on memory safety in the OS through static analysis.
Static analysis was identified as a requirement due to the assumption that humans tend to make mistakes and C was found to be an error prone language.
Rust, as an affine-typed borrow- and lifetime-checked systems language that is equipped with an ownership model, is considered a viable candidate for replacing C for today's OS development.
After identifying common weaknesses of memory vulnerabilities and their manifestations, the choice of programming language was verified as the most effective mitigation attempt.
Rust was chosen to act as a new candidate, and was found to be effective against common errors in buffer handling due to its ownership model and strong type system.
The language shown to be less error prone in memory intensive tasks like buffer handling, which has been identified as a common cause in software vulnerabilities.
After experimentation with various stack protection scenarios and implementing preemptive multitasking on top of interemezzOS, the downside was discovered that Rust cannot statically detect stack overflows of any type.
Implementing this detection was considered beyond scope, although requirements could be identified for future reference.
It was concluded that Rust's static checks of all kinds are a big improvement in OS development, where object orientation and other paradigms are not simple to manage.
Despite the failed hypotheses of guaranteeing full memory-safety in OS development, Rust is suggested as the language for today's and future OS development.
}
% Numbered Subsubsections % Numbered Subsubsections
\setcounter{secnumdepth}{3} \setcounter{secnumdepth}{3}
@ -232,55 +246,22 @@
\makeatother \makeatother
\include{glossary} \include{glossary}
\overfullrule=1cm
\begin{document} \begin{document}
%TODO: \include{cover} \include{cover}
\pagestyle{front} \pagestyle{front}
\include{title} \include{title}
\pagestyle{preamble} \pagestyle{preamble}
\include{abstract} \include{abstract}
%TODO: \include{affidavit} \include{affidavit}
\cleardoublepage \cleardoublepage
\newcounter{roman_pagenumbers} % save page number \newcounter{roman_pagenumbers} % save page number
\setcounter{roman_pagenumbers}{\value{page}} \setcounter{roman_pagenumbers}{\value{page}}
\pagestyle{main} \pagestyle{main}
%TODO \include{acknowledgments} %TODO \include{acknowledgments}
%TODO abstract
\chapter*{Preface}
This thesis is original, unpublished, independent work by me, \authorOne.
I strongly believe in openness and collaboration in the development of new technology, therefore the development will be based solely on Open-Source software.
The source of this document and the code I have worked on will be freely available on my personal Gitlab site\footnote{https://gitlab.com/steveeJ/msc-thesis} once the academic process of this project is complete.
\section*{Ehrenwörtliche Erklärung}
Hiermit erkläre ich, {\authorOne}, geboren am {\authorOneBirthDate} in {\authorOneBirthCity},
\begin{enumerate}
\item{
dass ich meine Masterarbeit mit dem Titel:
{"\topic"}
in der Fakultät Informatik unter Anleitung von Professor {\supervisorOne} und ohne fremde Hilfe angefertigt habe und keine anderen als die angeführten Hilfen benutzt habe;
}
\item{
dass ich die Übernahme wörtlicher Zitate, von Tabellen, Zeichnungen, Bildern und Programmen aus der Literatur oder anderen Quellen (Internet) sowie die Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen innerhalb der Arbeit gekennzeichnet habe;
}
\item{
dass die eingereichten Abgabe-Exemplare in Papierform und im PDF-Format vollständig übereinstimmen.
}
\end{enumerate}
Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
\vspace{4cm}
Konstanz, 29.9.2017\hspace{5cm} \authorOne
\tableofcontents \tableofcontents