format: remove overfullrule

src/code/llc-arglist/arglist.cc

@@ -0,0 +1,12 @@
+#include "llvm/Support/CommandLine.h"
+
+using namespace llvm;
+
+/*
+ * Call with `--help-list-hidden` as argument to get a full list
+ */
+int main(int argc, char** argv) {
+      cl::ParseCommandLineOptions(argc, argv, "");
+
+          return 0;
+}

src/code/llc-arglist/run.sh

@@ -0,0 +1,2 @@
+g++ arglist.cc -o arglist -std=gnu++11 -lLLVM-4.0.1
+./arglist --help-list-hidden

src/code/stack_handling.c/makefile

@@ -1,7 +1,7 @@
 TARGET = stack_handling
 LIBS =
-CC = clang
+CC = gcc
-CFLAGS = -Wall -fomit-frame-pointer
+CFLAGS = -Wall -fomit-frame-pointer -fstack-check #-fsanitize=address
 
 .PHONY: default all clean
 
@@ -9,7 +9,7 @@ default: $(TARGET)
 all: default objdump
 
 OBJECTS = $(patsubst %.c, %.o, $(wildcard *.c))
-HEADERS = $(wildcard *.h)
+HEADERS = $(wildcard *.h)GG
 
 %.o: %.c $(HEADERS)
 	$(CC) $(CFLAGS) -c $< -o $@
@@ -22,7 +22,6 @@ $(TARGET): $(OBJECTS)
 clean:
 	-rm -f *.o
 	-rm -f $(TARGET)
-	-rm -f objdump
 
 objdump: $(TARGET)
 	objdump --no-show-raw-insn --disassembler-options=intel-nmemonic -d $(TARGET) > $@

src/code/stack_handling.c/stack_handling.c

@@ -39,9 +39,17 @@ static void caller(void) {
   printer(&a, &b);
 }
 
-static void shell() {
+static int *grow_stack(int size) {
-  char *argv[] = {};
+  int a[size];
-  execve("/bin/sh", argv, NULL);
+  for (int i = 0; i < size; i++) {
+    a[i] = 0;
+  }
+  return a;
+}
+
+static int64_t *large_stack() {
+  uint64_t a[100000000];
+  return a;
 }
 
 static void simple_printer(void) { fprintf(stderr, "I wonder who called me?"); }
@@ -49,7 +57,7 @@ static void simple_printer(void) { fprintf(stderr, "I wonder who called me?"); }
 static void modifier(void) {
   uint64_t *p;
   // without frame-pointer
-  *(&p + 1) = (uint64_t *)simple_printer;
+  // *(&p + 1) = (uint64_t *)simple_printer;
 
   // with frame-pointer
   *(&p + 2) = (uint64_t *)simple_printer;
@@ -69,7 +77,8 @@ int main(void) {
   //          0xfffffffffffffff4, 0xfffffffffffffff5, 0xfffffffffffffff6,
   //          0xfffffffffffffff7);
   //  modifier_indexed(NULL);
-  modifier();
+  // modifier();
+  large_stack();
   fprintf(stderr, "main exiting");
   return 0;
 }

src/code/stack_handling.rs/Cargo.toml

@@ -8,3 +8,6 @@ build = "build.rs"
 
 [profile.dev]
 panic = "abort"
+
+[profile.release]
+panic = "abort"

src/code/stack_handling.rs/src/main.rs

@@ -1,3 +1,6 @@
+#![feature(naked_functions)]
+#![deny(unconditional_recursion)]
+
 // #[derive(Debug)]
 // struct Stat {
 //     sum: isize,
@@ -76,39 +79,6 @@ fn passthrough(a: isize) -> isize {
 }
 
 #[inline(never)]
-fn caller() {
+fn r();
-    let a = passthrough(1);
-    let b = a * 2;
-    printer(&a, &b);
-}
-
-#[inline(never)]
-fn printer(a: &isize, b: &isize) {
-    println!("2*{}={}", a, b)
-}
-
-#[inline(never)]
-fn modifier() {
-    let mut sp: usize = 0xdeadbeef;
-    let addr = &mut sp as *mut usize;
-    // println!("{:p} {}", sp, addr as usize + 0x38);
-    //    unsafe {
-    //        std::ptr::write(sp.offset(4).as_mut().unwrap(), simple_printer);
-    //    }
-
-    unsafe {
-        std::ptr::write((addr as usize + 0x40) as *mut usize,
-                        simple_printer as usize);
-    }
-}
-
-#[inline(never)]
-#[allow(dead_code)]
-fn simple_printer() {
-    println!("I wonder who called me")
-}
-
-fn main() {
-    modifier();
     println!("main exiting")
 }

src/docs/abstract.tex

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

src/docs/affidavit.tex

@@ -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

src/docs/cover.tex

@@ -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} 

src/docs/glossary.tex

@@ -11,9 +11,38 @@
 
 \newglossaryentry{Rust} {
     name = {Rust},
-    long = {the Rust programming language},
+    long = {The Rust programming language},
     description = {%
-        Statically typed programming language that uses a new concept of variable ownership and reference tracking. Largely explain in \cref{context::rust}.
+        Statically typed programming language that uses a new concept of variable ownership and reference tracking. Largely explain in \cref{rnd::rust}.
+    },
+    first = {\glsentrylong{Rust}}
+}
+
+\newglossaryentry{rustc}{
+    name = rustc,
+    long = {The Rust compiler},
+    description = {%
+        This program is a compiler for the Rust language (man rustc).
+    },
+    first = {\glsentrylong{rustc}},
+}
+
+\newglossaryentry{cargo} {
+    name = {cargo},
+    long = {The Rust package manager},
+    description = {%
+        This program is a package manager for the Rust language (man cargo).
+        It is also a wrapper for the Rust compiler.
+        It is also a management tool for Rust source code projects, and simplifies the initialization of project directories, the build of the source code and the run of the compiled binary.
+    },
+    first = {\glsentrylong{Rust}}
+}
+
+\newglossaryentry{xargo} {
+    name = {xcargo},
+    long = {The Cross-Compilation wrapper for cargo},
+    description = {%
+        Wrapper for cargo to simplify cross-compilation.
     },
     first = {\glsentrylong{Rust}}
 }
@@ -46,6 +75,27 @@
     first = {\glsentrylong{GCC}}
 }
 
+\newglossaryentry{llvm}{
+    name = LLVM,
+    long = {Low Level Virtual Machine},
+    description = {%
+        A Virtual Instruction Set and Compilation Framework.
+        The key idea in LLVM is to use a rich virtual instruction set (instead of raw machine code) as the object code representation manipulated by link-time and post-link optimizers and code generators.\cite{Kowshik2002}.
+    },
+    first = {\glsentrylong{clang}}
+}
+
+
+\newglossaryentry{clang}{
+    name = Clang,
+    long = {C Language frontendend for LLVM},
+    description = {%
+        The goal of the Clang project is to create a new C based language front-end: C, C++, Objective C/C++, OpenCL C and others for the LLVM compiler. You can get and build the source today.
+        \url{http://clang.llvm.org/}
+    },
+    first = {\glsentrylong{clang}}
+}
+
 \newglossaryentry{addrspace}{
     name = address space,
     long = bound address range in memory,
@@ -58,7 +108,6 @@
 \newglossaryentry{stack}{
     name = stack,
     description = {%
-        TODO
     },
 }
 
@@ -72,7 +121,6 @@
 \newglossaryentry{heap}{
     name = heap,
     description = {%
-        TODO
     },
 }
 
@@ -98,42 +146,36 @@
 \newglossaryentry{fs}{
     name = filesystem,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{virt}{
     name = virtualization,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{OSS}{
     name = Open-Source Software,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{osvirt}{
     name = Operating System-Level Virtualization,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{hypervisor}{
     name = Hypervisor,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{VM}{
     name = Virtual Machine,
     description = {%
-        TODO
     },
 }
 
@@ -146,9 +188,16 @@
     plural=Linuces
 }
 
+\newglossaryentry{microkernel}{
+    name = microkernel,
+    description = {%
+        Kernel design that operates most drivers in userland, and only provides bare minimum functionality in kernel mode for glueing the drivers together.
+    },
+}
+
 \newglossaryentry{android}{
     name = Android,
-    description = {a mobile \gls{os} based on \gls{LX}},
+    description = {an open-source mobile \gls{os} based on \gls{LX}},
     first = {\glsentryname{android}, \glsentrydesc{android}},
 }
 
@@ -156,35 +205,30 @@
 \newglossaryentry{imezzos}{
     name = intermezzOS,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{redoxos}{
     name = Redox OS,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{blogos}{
     name = Blog OS,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{tockos}{
     name = Tock OS,
     description = {%
-        TODO
     },
 }
 
 \newglossaryentry{rootfs}{
     name = RootFS,
     description = {%
-        % TODO
     },
 }
 
@@ -213,7 +257,6 @@
 \newglossaryentry{BSD}{
     name = BSD,
     description = {%
-        TODO
     }
 }
 
@@ -230,7 +273,6 @@
 \newglossaryentry{pm}{
     name = package manager,
     description = {%
-        TODO
     }
 }
 
@@ -261,7 +303,6 @@
 \newglossaryentry{LXC}{
     name = LXC,
     description = {%
-        TODO
     }
 }
 
@@ -275,14 +316,12 @@
 \newglossaryentry{systemd-nspawn}{
     name = systemd-nspawn,
     description = {%
-        TODO
     }
 }
 
 \newglossaryentry{rkt}{
     name = rkt,
     description = {%
-        TODO
     }
 }
 
@@ -302,8 +341,10 @@
 
 \newglossaryentry{NVD}{
     name = {NVD},
-    description = {https://nvd.nist.gov/},
+    description = {
-    long = {National Vulnerability Database},
+        The NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security related software flaws, misconfigurations, product names, and impact metrics.\cite{NVD}
+    },
+    long = {\citetitle{NVD}},
     first = {\glsentrylong{NVD}}
 }
 
@@ -324,13 +365,34 @@
     name = CWE-119,
     long = {CWE-119: \glsentrydesc{CWE-119}},
     description = {Improper Restriction of Operations within the Bounds of a Memory Buffer},
-    first = {\glsentrylong{CWE-119}\cite{MITRE-CWE-119}}
+    first = {\glsentrytext{CWE-119}\cite{MITRE-CWE-119}}
+}
+
+\newglossaryentry{CWE-635}{
+    name = CWE-635,
+    long = {\glsentrydesc{CWE-635}},
+    description = {\citetitle{MITRE-CWE-635}},
+    first = {\glsentrytext{CWE-635}\cite{MITRE-CWE-635}}
+}
+
+\newglossaryentry{CWE-122}{
+    name = CWE-122,
+    long = {\glsentrydesc{CWE-122}},
+    description = {\citetitle{MITRE-CWE-122}},
+    first = {\glsentrytext{CWE-122}\cite{MITRE-CWE-122}}
+}
+
+\newglossaryentry{CWE-134}{
+    name = CWE-134,
+    long = {\glsentrydesc{CWE-134}},
+    description = {\citetitle{MITRE-CWE-134}},
+    first = {\glsentrytext{CWE-134}\cite{MITRE-CWE-134}}
 }
 
 \newglossaryentry{C}{
     name = C,
     , description = {%
-        TODO C programming language,
+        C programming language,
     }
 }
 
@@ -342,9 +404,9 @@
 }
 
 \newglossaryentry{asm}{
-    name = Assembly programming language,
+    name = ASM,
+    long = Assembly programming language,
     description = {%
-        TODO ASM
     }
 }
 
@@ -352,7 +414,7 @@
     name = AMD64,
     long = AMD64,
     description = {%
-        TODO AMD64
+        Contemporary Hardware Architecture\cite{AMD64Vol1,AMD64Vol2}
     },
     first = {\glsentrylong{amd64}},
 }
@@ -361,7 +423,7 @@
     name = CPU,
     long = Central Processing Unit,
     description = {%
-        TODO cpu
+        Central Haddware Unit that executes machine code
     },
     first = {\glsentrylong{cpu}},
 }
@@ -371,31 +433,37 @@
     name = TLB,
     long = Translation Lookaside Buffer,
     description = {%
-        TODO tlb
     },
     first = {\glsentrylong{tlb}},
 }
 
-\newglossaryentry{MMU}{
+\newglossaryentry{mmu}{
     name = MMU,
     long = Memory Management Unit,
     description = {%
-        TODO MMU
+        Physical part of the \gls{cpu} equipped for managing the system's memory.
     },
     first = {\glsentrylong{MMU}},
 }
 
+\newglossaryentry{vaddr}{
+    name = virtual address,
+    plural = virtual addresses,
+    description = {%
+        Memory Addresses that does not reference physical memory directly, but is part of a memory virtualization scheme.
+    },
+}
+
 \newglossaryentry{sysadmin}{
     name = System Administrator
     , description = {%
-        TODO sysadmin
     }
 }
 
 \newglossaryentry{realtime}{
     name = realtime
     , description = {%
-        TODO realtime
+        In computer science realtime refers to guaranateed execution within specified time boundaries.
     }
 }
 
@@ -410,7 +478,7 @@
     name = task 
     , description = {%
     Generic term for any unit of work to be executed on the.
-        In the context of this thesis, it may be used for any of \glsentrytext{program}, \glsentrytext{process}, \glsentrytext{thread}. 
+        In the context of this study, it may be used for any of \glsentrytext{program}, \glsentrytext{process}, \glsentrytext{thread}. 
     }
 }
 

src/docs/parts/context/context.tex

@@ -1,7 +1,7 @@
 % // vim: set ft=tex:
 \chapter{Introduction}
 \label{context::introduction}
-This thesis studies the feasibility of using compile-time code analysis, as found in \gls{Rust}'s \gls{compiler}, for ensuring memory-safety within an \gls{os} kernel.
+This document contains a study on the feasibility of using compile-time code analysis, as found in \gls{Rust}'s \gls{compiler}, for ensuring memory-safety within an \gls{os} kernel.
 This study could be applied to all \glspl{app}, but the focus is on the implementation of \glspl{os} which is the \gls{app} that is responsible for managing the system's resources and provide abstractions for all other \glspl{app}.
 For this the \gls{os} is the only \gls{app} that required unrestricted access to these resources, with the responsibility of managing them safely according to the rules that are either hard-coded or set up by the \gls{sysadmin}.
 
@@ -14,19 +14,19 @@ The increasing number of vulnerabilities based on memory-safety issues in \glspl
 % A hypothesis is a testable prediction for an observed phenomenon, namely, the gap in the knowledge. Each research question will have both a null and an alternative hypothesis in a quantitative study. Qualitative studies do not have hypotheses. The two hypotheses should follow the research question upon which they are based. Hypotheses are testable predictions to the gap in the knowledge. In a qualitative study the hypotheses are replaced with the primary research questions.
 
 According to my best-effort literature research in Q1/2017, the hypothesis that \textit{Rust's static code analysis can guarantee memory safety in the \gls{os}} has not been studied explicitly.
-This is to my surprise, because as explained in \cref{context::introduction::memory-safety}, memory-safety in \gls{os} development is critical, and \gls{Rust} offers attractive features that might bring improvements, which is covered in \cref{context::rust}.
+This is to my surprise, because as explained in \cref{context::introduction::memory-safety}, memory-safety in \gls{os} development is critical, and \gls{Rust} offers attractive features that might bring improvements, which is covered in \cref{rnd::rust}.
-The hypothesis cannot be trivially approved or denied, which drives the research efforts for my final thesis project.
+The hypothesis cannot be trivially approved or denied, which drives the research efforts for my final study project.
 
 Besides this specific hypothesis, many implementations of \glspl{os} with \gls{Rust} have appeared in public.
 Their purposes range from proof-of-concept and educational work like \gls{imezzos} and \gls{blogos}, to implementations that aim to be production grade software like \gls{redoxos} and \gls{tockos} \cite{Levy2015a}.
-These implementations are subject to evaluation in \cref{rnd::existing-os-dev-with-rust}
+These implementations are subject to evaluation in \cref{rnd::existing-os-dev-with-rust}.
 
 The final results will be of qualitative nature, captured by analyzing the existing and a self-developed \gls{Rust}-implementations of popular memory management techniques.
 In addition to the sole analysis of \gls{Rust}-implementations, comparisons will be made, discerning the level of memory safety guarantees gained over similarly intending implementations in \gls{C}.
 
 \section{What is Memory-Safety?}
 \label{context::introduction::memory-safety}
-Memory-safety is a term that is only vaguely defined in general, thus a definition is given for the context of this thesis.  
+Memory-safety is a term that is only vaguely defined in general, thus a definition is given for the context of this study.  
 For a thorough understanding of the issues discussed further in this document, it might be helpful to review the basics of how memory is used in current computer systems.
 
 For decades computer systems, more specifically their \glspl{cpu}, were designed to execute instructions that were previously loaded into volatile main memory, typically from a secondary, persistent memory.
@@ -54,7 +54,7 @@ This is why information on safety related mistakes in software shouldn't be publ
 Ideally, before the vulnerability is publicly known, all systems that run the erroneous software in question should have the chance to update the software is question, so that any potential attackers can't leverage the known vulnerability.
 This introduces a dilemma, because software updates usually contain publicly known information, at least in the open-source sector.
 
-Any existing or hypothetical solution to this dilemma is not in scope of this thesis, but two conclusions can be made.
+Any existing or hypothetical solution to this dilemma is not in scope of this study, but two conclusions can be made.
 First, public statistics in the area of software vulnerabilities are questionable with regard to their completeness.
 Second, and more importantly, memory-safety related software mistakes should be detected as early as possible, ideally before the software is released and installed anywhere.
 
@@ -89,7 +89,7 @@ A professor and co-author of \citetitle{Arpaci-Dusseau2015} gives the following
 
 Plenty of educational, economical or methodological solutions are imaginable for this problem.
 Higher focus on safety and testing in education, enforced internal company guidelines, or industry wide third party software certification requirements can be attempted.
-For this thesis such constraints are out of scope, and the focus is on examining technical methods that detect and indicate mistakes as early as possible.
+For this study such constraints are out of scope, and the focus is on examining technical methods that detect and indicate mistakes as early as possible.
 
 \subsection{Technical Aspect}
 \label{context::introduction::technical-aspect}
@@ -229,7 +229,7 @@ The whole memory can be divided into arbitrary groups of addressable units.
 The \gls{os} supervises this structure, and programs must request memory from the \gls{os} to gain access to memory.
 A method that combines virtualization and structuring is called paging and is explained in \cref{context::os-dev-concepts::hw-supported-mm}.
 
-The goal of memory virtualization is to use virtual addresses in \glspl{program}, which can be dynamically mapped to physical memory addresses at system runtime.
+The goal of memory virtualization is to use \glspl{vaddr} in \glspl{program}, which can be dynamically mapped to physical memory addresses at system runtime.
 
 \subsection{CPU Virtualization}
 The \gls{cpu} is generally not explicitly requested by \glspl{program}, because any of the program's instructions implicitly requires the \gls{cpu} for being executed on the system at all.
@@ -240,20 +240,6 @@ How this can be achieved is explained in \cnameref{context::os-dev-concepts::pre
 
 \subsection{Program Execution}
 \label{context::os-dev-concepts::virtualization::task}
-% TODO: remove or complete this graph
-%\begin{tikzpicture}[->,node distance=5ex,on grid,
-%    every state/.style={fill=red,draw=none,circular drop shadow,text=white}]
-%
-%    \node[state] (A) {Task};
-%    \node[state] (B) {Job};
-%    \node[state] (C) {Process};
-%    \node[state] (D) {Program};
-%    \node[state] (E) {Procedure};
-%    \node[state] (F) {Thread};
-%
-%    \path (A) edge (B);
-%\end{tikzpicture}
-
 As explained in this document it should be understood that a program consists of instructions that can be executed by the \gls{cpu}.
 When the \gls{os} loads a program into memory and begins executing its instructions it is called a process.\cite[p.~25]{Arpaci-Dusseau2015}
 A process can begin to exist before its execution, when the \gls{os} has internally created an entry for the process that at least contains a reference to the program and the arguments to be passed.
@@ -354,44 +340,44 @@ More details on this mechanism is given in \cref{context::os-dev-concepts::preem
 
 \section{Hardware-supported Memory-Paging}
 \label{context::os-dev-concepts::hw-supported-mm}
-To improve the efficiency and safety of memory management, developers of hardware and software have been collaborating to offload virtual memory address lookup and caching from the \gls{os} software to the hardware, the \gls{cpu}'s \gls{MMU} to be specific.
+To improve the efficiency and safety of memory management, developers of hardware and software have been collaborating to offload virtual memory address lookup and caching from the \gls{os} software to the hardware, the \gls{cpu}'s \gls{mmu} to be specific.
 A hardware-implementation of the lookup algorithm is fast, and allows rudimentary memory permission runtime-checks to protect pages by leveraging \gls{cpu}'s security rings\cite[p.~117,~p.~145]{AMD64Vol2}.
 
 Activating the 64-Bit long mode on \gls{amd64} makes the system rely primarily on paging memory management, thus the technique of memory segmentation can be neglected in this context.
 This section provides information about hardware-supported memory paging and protection techniques.
 
 \subsection{Virtual Address Translation and Paging}
-Paging with virtual addresses is one method of virtualizing memory and in this way transparently share the system's memory among running tasks and the \gls{os} itself, presumably in a safe way. 
+Paging with \glspl{vaddr} is one method of virtualizing memory and in this way transparently share the system's memory among running tasks and the \gls{os} itself, presumably in a safe way. 
-Even when using a language that supports direct memory addressing, \gls{app} developers don't have to consider paging and address translation in the logic of their programs, because all addresses in their program are virtual and are translated at runtime by the \gls{MMU}.
+Even when using a language that supports direct memory addressing, \gls{app} developers don't have to consider paging and address translation in the logic of their programs, because all addresses in their program are virtual and are translated at runtime by the \gls{mmu}.
-The translation itself is performed by the \gls{MMU} according to a map that is called page table, which is a structure maintained by the \gls{os} in the main memory.
+The translation itself is performed by the \gls{mmu} according to a map that is called page table, which is a structure maintained by the \gls{os} in the main memory.
-This memory structure can be stored anywhere in memory, and the address is handed to the \gls{MMU} via a specific \gls{cpu} register, \textit{CR3} on \gls{amd64}.
+This memory structure can be stored anywhere in memory, and the address is handed to the \gls{mmu} via a specific \gls{cpu} register, \textit{CR3} on \gls{amd64}.
-The \gls{os} can maintain multiple page table structures, and can create different virtual address spaces by changing the \gls{MMU}'s page-table pointer register.
+The \gls{os} can maintain multiple page table structures, and can create different \gls{vaddr} spaces by changing the \gls{mmu}'s page-table pointer register.
 
 \subsubsection{Translation Caching}
 The hardware caches the translation results for subsequent lookups in the \gls{tlb} \cite[p.~142-143]{AMD64Vol2}.
-This greatly improves the speed for repeated access to the same virtual addresses, but is certainly dangerous for memory-safety.
+This greatly improves the speed for repeated access to the same \glspl{vaddr}, but is certainly dangerous for memory-safety.
 Controlling the validity of these cache entries is the responsibility of the \gls{os} .
 This is critical for memory-safety, as the cached virtual to physical address lookup results are different for each address space and shouldn't leak into other address spaces.
 
-If any lookup yields a cached result which originates from a different virtual address space, the physical address is likely to belong to a memory region to which the current task shouldn't have access to.
+If any lookup yields a cached result which originates from a different \gls{vaddr} space, the physical address is likely to belong to a memory region to which the current task shouldn't have access to.
 What makes it more difficult to manage is that there are exceptions to this, e.g. when memory is intentionally shared between two processes or threads, which must be set up by the \gls{os} according to the processes requests.
 
 \subsubsection{Pages: Chunks of Smallest Addressable Unit}
-To avoid the need for storing a translation mapping for every single virtual address, mappings are grouped into equisized regions, called \textit{page}s.
+To avoid the need for storing a translation mapping for every single \gls{vaddr} , mappings are grouped into equisized regions, called \textit{page}s.
-This works by encoding a page-offset in the virtual address, together with page's index in the page table.
+This works by encoding a page-offset in the \gls{vaddr} , together with page's index in the page table.
 The offset size depends on the chosen page-size, and can be calculated with the following formula, given page-size $p$, a power of two given in Byte:
 \begin{equation}
-    vaddr\_offset(p) = log_2(p), p \in \mathbb{N}^2 %TODO: restrain that p must be a power of 2
+    f(p) = log_2(p)
 \end{equation}
-For example, the \gls{amd64} default page-size of 4 KiB has a 12-bit offset, which theoretically leaves the other $64-12 = 52$ bits of the virtual address for page-table indexing.
+For example, the \gls{amd64} default page-size of 4 KiB has a 12-bit offset, which theoretically leaves the other $64-12 = 52$ bits of the \gls{vaddr} for page-table indexing.
-On \gls{amd64} there's an architectural limit of 48 bits for the virtual address, thus the address constellation is different than explained here. 
+On \gls{amd64} there's an architectural limit of 48 bits for the \gls{vaddr} , thus the address constellation is different than explained here. 
 Details on this concrete implementation follows in \cnameref{context::os-dev-concepts::hw-supported-mm::multilevel-paging-amd64}.
 
 \subsection{Page-Faults}
 \label{context::os-dev-concepts::hw-supported-mm::page-fault}
-To improve the efficiency and safety of memory management, developers of hardware and software have been collaborating to offload virtual memory address lookup and caching from the \gls{os} software to the hardware, the \gls{cpu}'s \gls{MMU} to be specific.
+To improve the efficiency and safety of memory management, developers of hardware and software have been collaborating to offload virtual memory address lookup and caching from the \gls{os} software to the hardware, the \gls{cpu}'s \gls{mmu} to be specific.
 The page-fault is a hardware-triggered, memory-safety critical event that must be handled by the \gls{os}.
-It is triggered by the \gls{cpu}'s \gls{MMU} during the virtual address lookup algorithm, when an instruction uses a virtual address for which the target page is not available.
+It is triggered by the \gls{cpu}'s \gls{mmu} during the \gls{vaddr} lookup algorithm, when an instruction uses a \gls{vaddr} for which the target page is not available.
 This happens for example if the indexed page is not present in main memory or has not been allocated at all.
 It also happens when an instruction violates a page protection, of which four exist and can be configured by the \gls{os} on \gls{amd64} \cite[p.~145-148]{AMD64Vol2}:
 \begin{itemize}
@@ -401,17 +387,17 @@ It also happens when an instruction violates a page protection, of which four ex
 \end{itemize}
 
 The \gls{os} must implement the page-fault handler to deal with it accordingly.
-For example, the case of a non-existing mapping requires to find and allocate free physical memory and map it to the page by modifying the virtual addresse's page-table entry.
+For example, the case of a non-existing mapping requires to find and allocate free physical memory and map it to the page by modifying the \gls{vaddr} e's page-table entry.
 Or in case of protection violation it would simply indicate denied access.
 
 \subsection{Swapping}
 The finite primary memory can only hold a finite number of virtual pages, and the \gls{os} is responsible for having the required pages present.
 Besides the pages that contain the page-table itself, the pages that aren't required by the current instruction might be moved to secondary memory.
-Swapping pages in and out of primary memory is risky as it requires to transfer large amounts of raw memory content, but these safety analyzes exceed the scope of this thesis.
+Swapping pages in and out of primary memory is risky as it requires to transfer large amounts of raw memory content, but these safety analyzes exceed the scope of this study.
 
 \subsection{Multi-Level Paging Concept}
 \label{context::os-dev-concepts::hw-supported-mm::multilevel-paging-concept}
-If only one page-table per virtual address space was used that consists of $2^{52}$ page-table entries, which must at minimum store the physical address, it would require $\frac{52 * 2^{52} [Bit]}{8*1024^4 [Bit/Byte]} = 26624$ TiB of memory for each virtual address space.
+If only one page-table per \gls{vaddr} space was used that consists of $2^{52}$ page-table entries, which must at minimum store the physical address, it would require $\frac{52 * 2^{52} [Bit]}{8*1024^4 [Bit/Byte]} = 26624$ TiB of memory for each \gls{vaddr} space.
 Even if only a handful of additional pages were allocated and mapped, the \gls{os} would still have to allocate this huge page-table.
 This vast consumption of main memory is impractical and impossible for average systems, which rarely surpass 100 GiB of main memory.
 
@@ -419,58 +405,21 @@ 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.
 
 % 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)
-        node(text-a){idx$_n$} ++(\x,0)
-        node(text-b){idx$_{n-1}$} ++(\x,0)
-        node(text-c){...} ++(\x,0)
-        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}
-        ;
-    % braces
-    \foreach \y in {1,...,5} {
-        \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
-     % cells
-    (0*\x,-1*\x)                  
-        rectangle ++( \x, 0.5*-1) 
-        rectangle ++(-\x,-1)     
-        rectangle ++( \x, 0.5*-1) 
-    (1*\x,-3*\x)
-        rectangle ++( \x, 0.5*-1)
-        rectangle ++(-\x,-1)
-        rectangle ++( \x, 0.5*-1) 
-    (2*\x,-5*\x)
-        rectangle ++( \x, 0.5*-1)
-        rectangle ++(-\x,-1)
-        rectangle ++( \x, 0.5*-1) 
-        ;
-
-    % cell text
 %     (0.5*\x,0.5)
 %         node(text-a){idx$_n$} ++(\x,0)
 %         node(text-b){idx$_{n-1}$} ++(\x,0)
@@ -483,33 +432,42 @@ Using a hierarchical translation structure allows to save significant amounts of
 %     (5*\x,1) 
 %         node[anchor=south]{0}
 %         ;
-
+%     % braces
-%        \def\y{1}
+%     \foreach \y in {1,...,5} {
-%        \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)$);
+%     \draw
-
+%      % cells
-\end{tikzpicture}
+%     (0*\x,-1*\x)                  
-\caption{Hierarchical Virtual Paging}
+%         rectangle ++( \x, 0.5*-1) 
-\label{fig:paging-hierarchy-abstract}
+%         rectangle ++(-\x,-1)     
-\end{figure}
+%         rectangle ++( \x, 0.5*-1) 
-\FloatBarrier
+%     (1*\x,-3*\x)
+%         rectangle ++( \x, 0.5*-1)
+%         rectangle ++(-\x,-1)
+%         rectangle ++( \x, 0.5*-1) 
+%     (2*\x,-5*\x)
+%         rectangle ++( \x, 0.5*-1)
+%         rectangle ++(-\x,-1)
+%         rectangle ++( \x, 0.5*-1) 
+%         ;
+% 
+% \end{tikzpicture}
+% \caption{Hierarchical Virtual Paging}
+% \label{fig:paging-hierarchy-abstract}
+% \end{figure}
+% \FloatBarrier
 
 \subsection{Multi-Level Paging on AMD64}
 \label{context::os-dev-concepts::hw-supported-mm::multilevel-paging-amd64}
 On \gls{amd64} "a four-level page-translation data structure is provided to allow long-mode operating systems to translate a 64-Bit virtual-address space into a 52-Bit physical-address space."\cite[p.~18]{AMD64Vol2}.
 This allows the system to only hold the \textit{PML4} table, the which is currently referenced by the \textit{Page Map Base Register (CR3)}, available in main memory.
 
-\Cref{fig:virtual-addr-transl} shows the 64-Bit virtual address composition on \gls{amd64}, which uses four-levels of page tables.
+\Cref{fig:virtual-addr-transl} shows the 64-Bit \gls{vaddr} composition on \gls{amd64}, which uses four-levels of page tables.
 Counter intuitively the page-tables are not called level-\textit{n}-page-table, but the levels received distinct names in \citetitle{AMD64Vol2}.
 The most-significant Bits labelled as \textit{Sign Extend} are not used for addressing purposes, but must adhere the canonical address form and simply repeat the value of the most-significant implemented Bit \cite[p.~130]{AMD64Vol2}.
 The least significant Bits represent the offset within the physical page.
@@ -523,8 +481,8 @@ The four groups in between are used to index the page-table at their respective
 \end{figure}
 \subsubsection{Translation Scheme 4 KiB and 2 MiB Pages}
 The \gls{amd64} architecture allows configuring the page-size, two of which will be introduced in this section.
-\cref{tab:page-transl-vaddr-composition} displays the virtual address composition for the 4KiB and 2MiB page-size modes on \gls{amd64}.
+\cref{tab:page-transl-vaddr-composition} displays the \gls{vaddr} composition for the 4KiB and 2MiB page-size modes on \gls{amd64}.
-The direction from top to bottom in the table corresponds to most significant to least significant - left to right - in the virtual address.
+The direction from top to bottom in the table corresponds to most significant to least significant - left to right - in the \gls{vaddr} .
 The \textit{sign extension} Bits cannot be used for actual information but act as a reservation for future architectural changes.
 
 \begin{table}
@@ -549,8 +507,8 @@ The \textit{sign extension} Bits cannot be used for actual information but act a
 \label{fig:4kb-page-transl}
 \end{figure}
 
-\cref{fig:4kb-page-transl} shows the detailed virtual address composition for 4 KiB pages, using four levels of page-tables.
+\cref{fig:4kb-page-transl} shows the detailed \gls{vaddr} composition for 4 KiB pages, using four levels of page-tables.
-It uses four sets of 9-Bit indices in the virtual address, one per hierarchy level, followed by the 9 Bit page-internal offset.
+It uses four sets of 9-Bit indices in the \gls{vaddr} , one per hierarchy level, followed by the 9 Bit page-internal offset.
 
 An alternative approach is displayed in \cref{fig:2mb-page-transl}, using 2 MiB sized pages.
 It uses three sets of 9-Bit indices for the page-tables, and a 21-Bit page-internal offset.
@@ -611,10 +569,9 @@ In this picture, the \gls{stack} grows upwards.
 
 \subsubsection{Safety Concerns}
 To achieve memory-safe \gls{stack} management in the \gls{os}, each procedure must only be able to access its own particular \gls{stack} and possible references via its arguments.
-This is not the case in a regular \gls{C} program, where the called procedure is able to modify the previous \gls{sf}, which is demonstrated in \cnameref{rnd::weakness-mitig-eval::stack-protection}.
+This is not the case in a regular \gls{C} program, where the called procedure is able to modify the previous \gls{sf}, which is demonstrated in \cnameref{rnd::weakness-mitig-prev::stack-protection}.
-
 Additionally, the \glspl{stack} must be prevented from growing into other memory zones like the \gls{heap}.
-Since \Gls{stack} management is memory-safety critical for \gls{os} developers when implementing memory management for multitasking within the \gls{os}, it is one of the main subjects in \cnameref{rnd}, \cref{rnd::existing-os-dev-with-rust,rnd::imezzos-preemptive-multitasking}.
+Since \Gls{stack} management is memory-safety critical for \gls{os} developers when implementing memory management for multitasking within the \gls{os}; This is one of the main subjects in \cref{rnd::existing-os-dev-with-rust,rnd::imezzos-preemptive-multitasking}.
 
 \subsection{Heap: Organized Chaos}
 \label{context::os-dev-concepts::stackheap::heap}
@@ -638,7 +595,7 @@ Between properly cleaning up and loosing memory allocations is a whole range of
 \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 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}
 \code{push} a takes value operand which is to be pushed onto the stack.
@@ -665,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.
 
 \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}.
 \cite[p.~48]{AMD64Vol1}:
 
@@ -698,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.
 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, XMM0–7
+% 
+% \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, XMM0–7
-
-\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{minted}[escapeinside=??,linenos=false,breaklines=true]{nasm}
@@ -812,17 +767,18 @@ $74f7: ret                             ; return to the caller, following the add
 \caption{Function Epilogue}
 \label{code::context::examples::func-epilogue}
 \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
 
+%\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}
 \label{context::os-dev-concepts::stackheap-combined}
 \Glspl{program} combine the usage of \gls{stack} and \gls{heap} use them for different purposes.
@@ -873,9 +829,9 @@ Depending on the \gls{proglang}'s \gls{compiler} and the target system, the resp
 
 \subsection{Arrangement}
 \label{context::os-dev-concepts::stackheap-combined::arrangement}
-Both zones must be organized separately and arrange within the virtual address space which is assigned to process or thread.
+Both zones must be organized separately and arrange within the \gls{vaddr} space which is assigned to process or thread.
 \Cref{fig:heap-malloc-stack-example-program} shows a \gls{C} \gls{program} and a simplified model of the hypothetical address space that would result on execution.
-In this example, the \gls{stack} and \gls{heap} are placed on opposite sides of the virtual address space, and will grow towards each other.
+In this example, the \gls{stack} and \gls{heap} are placed on opposite sides of the \gls{vaddr} space, and will grow towards each other.
 
 \begin{figure}[ht!]
     \centering
@@ -895,7 +851,7 @@ Lastly the \gls{stack} holds the pointer variable \textit{p}, which will referen
 
 \subsection{Safety Concerns}
 \label{context::os-dev-concepts::stackheap-combined::safety-concerns}
-Even though virtual address spaces are huge on \gls{amd64}, there is a slight chance that the \gls{stack} and \gls{heap} will interfere. 
+Even though \gls{vaddr} spaces are huge on \gls{amd64}, there is a slight chance that the \gls{stack} and \gls{heap} will interfere. 
 This could be due to direct collision, or more subtly by not detecting invalid mutual references.
 
 
@@ -957,7 +913,7 @@ For a full context-switch, the other registers that are part of the context need
 The previous \cref{context::introduction,context::os-dev-concepts} describe the concepts of memory management on \gls{amd64} and how mistakes might come into existence. 
 This chapter describes the related software weaknesses which are too commonly found.
 The underlying weakness classes are explained alongside real-world and exemplary manifestations in \gls{C}.
-The latter are ported and compared to functionally equivalent versions written with \gls{Rust} in \cref{rnd::weakness-mitig-eval::porting-c-vulns}, 
+The latter are ported and compared to functionally equivalent versions written with \gls{Rust} in \cref{rnd::weakness-mitig-prev::porting-c-vulns}, 
 
 %\section{\glsentrylong{CWE}}
 %\label{context::weaknesses-mem-safety::cwe}
@@ -974,8 +930,8 @@ The following information is provided for enumerations of the type weakness clas
 1. Relationships
 \end{markdown}
 
-The relevant weaknesses for this thesis are children of the umbrella weakness \citetitle{MITRE-CWE-633}.
+The relevant weaknesses for this study are children of the umbrella weakness \citetitle{MITRE-CWE-633}.
-Their information about demonstrative examples and potential mitigations are relevant for this thesis.
+Their information about demonstrative examples and potential mitigations are relevant for this study.
 This and the following \cref{context::weakness-mitigation} present this information for \gls{CWE-633} and selected children.
 
 % TODO test the autocite command with footnotes
@@ -991,28 +947,28 @@ Direct memory addressing support doesn't imply a lack of memory management suppo
 
 There are languages that provide memory management support and still allow direct memory addressing, which is interesting for \gls{os} development.
 \gls{Rust} is one of these languages, although it requires the developer to explicitly acknowledge all direct memory access operations with the \textit{unsafe} keyword.
-More information on \gls{Rust} follows in \cref{context::rust}.
+More information on \gls{Rust} follows in \cref{rnd::rust}.
 
 \section{Statistics}
 \label{context::weaknesses-mem-safety::cwe::statistics}
 One of the main reasons for me to work on this topic is the increasing number of vulnerabilities based on memory-safety issues.
 
 This section is intended to express the weakness's severity in real-world software based on available statistics.
-The only data available is based on publicly available sources, thus the completeness of it is questionable, because many organizations might choose to not disclose their vulnerabilities, either to protect their reputation or for security reasons as explained in \cref{context::introduction::memory-safety-violation-in-sw}.
+The only data available are based on publicly available sources, thus the completeness of it is questionable, because many organizations might choose to not disclose their vulnerabilities, either to protect their reputation or for security reasons as explained in \cref{context::introduction::memory-safety-violation-in-sw}.
-The data and visualizations are supplied by the \gls{NVD}, which collects the data based on the umbrella weakness CWE-635\footnote{http://cwe.mitre.org/data/definitions/635.html} that was specifically created for the \gls{NVD}.
+The data and visualizations are supplied by the \gls{NVD}, which collects the data based on the umbrella weakness \gls{CWE-635} that was specifically created for the \gls{NVD}.
 The numbers of these selected weaknesses are detailed in the following figures, the rest is grouped as \textit{other}.
 
 \Cref{fig:vulnerability-ratio-history,fig:vulnerability-counts-history} display a decade of data on vulnerabilities grouped by their \gls{CWE} category.
-The category called \textit{buffer\footnote{A bounded chunk of memory used by programs to store and exchange data} errors} represents \autocite{MITRE-CWE-119}. 
+The category called \textit{buffer\footnote{A bounded chunk of memory used by programs to store and exchange data} errors} \gls{CWE-119}. 
 In \cref{fig:vulnerability-ratio-history} it has the color light blue, 2nd from the bottom in the legend, and in \cref{fig:vulnerability-counts-history} it has the color blue, 2nd from the top in the legend.
 
 \begin{figure}
 \centering
 \includegraphics[width=\textwidth]{gfx/Relative-Vulnerability-Type-Totals-By-Year}
-\caption{Vulnerability Relative Counts History}
+\caption{Vulnerability Relative Counts History\cite{NVD}}
 \label{fig:vulnerability-ratio-history}
 \includegraphics[width=\textwidth]{gfx/Vulnerability-Type-Change-by-Year}
-\caption{Vulnerability Absolute Counts History}
+\caption{Vulnerability Absolute Counts History\cite{NVD}}
 \label{fig:vulnerability-counts-history}
 \end{figure}
 
@@ -1040,7 +996,7 @@ In \cref{fig:vulnerability-ratio-history} it has the color light blue, 2nd from
 \end{table}
 
 In \cref{tab:vulnerability-buffer-error-by-history}, the column \textit{relative count} represents \cref{fig:vulnerability-ratio-history}, and the column \textit{absolute count} represents \cref{fig:vulnerability-counts-history}.
-With 16.34 percent of all vulnerabilities known by 2016, and an average of 12.92 percent over ten years, \autocite{MITRE-CWE-119} makes up a significant part of real-world weaknesses.
+With 16.34 percent of all vulnerabilities known by 2016, and an average of 12.92 percent over ten years, \gls{CWE-119} makes up a significant part of real-world weaknesses.
 
 \subsection{Vulnerable APIs in Linux and C/C++}
 \label{context::weaknesses-mem-safety::vuln-apis-linux-c}
@@ -1065,13 +1021,13 @@ This section contains real-world manifestations and \textit{re}constructed exper
 It requires common understanding of the \gls{C} language and knowledge from the previous chapters.
 
 \subsection{Official CWE Examples}
+\label{context::weaknesses-mem-safety::manifestations::cwe-ex}
 The following examples are officially listed under various children of \citetitle{MITRE-CWE-633}\cite{MITRE-CWE-633}.
 The code and descriptions are copied literally and are used as references throughout the document.
 The numbering in the example names aren't contiguous because only a subset was selected, and the naming is supposed to match the \gls{CWE} website.
-References to the respective \gls{Rust} version are generally found in \cpnameref{rnd::weakness-mitig-eval::porting-c-vulns}, and referenced under each specific example for easier navigation.
+References to the respective \gls{Rust} version are generally found in \cpnameref{rnd::weakness-mitig-prev::porting-c-vulns}, and referenced under each specific example for easier navigation.
 
-\subsubsection{CWE-119}
+\subsubsection{\glsentrylong{CWE-119}}
-\glsentrylong{CWE-119}
 
 \paragraph{Example 1}
 The following code asks the user to enter their last name and then attempts to store the value entered in the last\_name array.
@@ -1089,7 +1045,7 @@ The following code asks the user to enter their last name and then attempts to s
 \end{listing}
 \FloatBarrier
 
-The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very\_very\_long\_last\_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total. 
+The problem with the code above is that it does not restrict or limit the size of the name entered by the user.If the user enters "Very\_very\_long\_last\_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total. 
 
 % \paragraph{Example 1}
 % This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.
@@ -1215,7 +1171,7 @@ However, this method only verifies that the given array index is less than the m
 \FloatBarrier
 
 
-\subsubsection{CWE-122: Heap-based Buffer Overflow}
+\subsubsection{\glsentrylong{CWE-122}}
 
 \paragraph{Example 1}
 
@@ -1235,7 +1191,7 @@ While buffer overflow examples can be rather complex, it is possible to have ver
 \FloatBarrier
 The buffer is allocated heap memory with a fixed size, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow. 
 
-\subsubsection{CWE-134: Use of Externally-Controlled Format String}
+\subsubsection{\glsentrylong{CWE-134}}
 
 \paragraph{Example 1}
 The following program prints a string provided as an argument.
@@ -1260,8 +1216,37 @@ The following program prints a string provided as an argument.
 \FloatBarrier
 The example is exploitable, because of the call to printf() in the printWrapper() function. Note: The stack buffer was added to make exploitation more simple.
 
-\subsection{Heartbleet}
+% \subsection{Heartbleed}
-% TODO: paper about hearbleet with Rust
+% TODO: paper about hearbleed with Rust
+
+\subsection{BlueBorne on Linux}
+Implementation of complex protocols are extremely dangerous in C as there is no notion of iterating or collections. 
+\gls{LX}, which is written in C, suffers extensively from buffer related errors and is likely to do so in the foreseeable future.
+Many hardware drivers are implementers of such protocols by exchanging data with the hardware and verifying the content.
+Often protocols aren't ideal either which makes their implementation even harder.
+
+A very recent and high impact vulnerability group is code named BlueBorne\cite{Seri2017}.
+It has multiple manifestations on various \gls{os}, including Android and \gls{LX}, e.g. CVE-2017-1000251\cite[p.12]{Seri2017} which is explained here.
+
+The vulnerable code is quite long and staged over three functions, though the following should be enough to indicate the issue:
+
+\begin{minted}[breaklines]{c}
+...
+    char buf [64];
+    len = l2cap_parse_conf_rsp (chan, rsp -> data , len, buf , & result);
+...
+\end{minted}
+\code{buf}, which is subject to overflow in this vulnerability, is a stack array with a fixed size, and its pointer is passed into a function.
+Inside the function is a loop which writes \code{len} messages from \code{rsp->data} to \code{buf}, while the last two are both of the "type" \code{void *}.
+The length to \code{buf} is not known in the function, thus there is no possibility of intentionally respecting its boundaries.
+
+\citeauthor{Seri2017} has additional criticism about \gls{LX}'s choice of having this code in the kernel:\footnote{italicized text was added by me}
+"L2CAP\textit{, which can be seen as Bluetooth’s equivalent of TCP,} is included as part of the core Linux kernel code.
+This is a rather dangerous choice.
+Combining a fully exposed communication protocol, arcane features like EFS and a kernel space implementation is a recipe for trouble.
+This vulnerability is a classic stack overflow occurring in the context of a kernel thread.
+This provides an attacker with a full and reliable kernel-level exploit for any Bluetooth enabled device running Linux, requiring no additional steps.
+Moreover, each compromised host can be used to launch secondary attacks, making this vulnerability wormable."
 
 \subsection{The Stack Clash}
 \label{context::weaknesses-mem-safety::manifestations::stack-clash}
@@ -1280,12 +1265,12 @@ This simply answers the question how this vulnerability can be present on in mul
 \subsubsection{Unguarded Stack Growth}
 The guard page concept has been introduced to prevent the stack from growing further than it should.\footnote{Related Linux CVE-2010-2240}
 
-If the stack grows contiguously and thus accesses virtual addresses that are not mapped to a page, the \gls{os}'s page-fault handler has the chance to inspect the situation.
+If the stack grows contiguously and thus accesses \glspl{vaddr} that are not mapped to a page, the \gls{os}'s page-fault handler has the chance to inspect the situation.
-The \gls{os} simply allocates a new page for the unmapped virtual address and allows the process to grow its stack.
+The \gls{os} simply allocates a new page for the unmapped \gls{vaddr} and allows the process to grow its stack.
-When the virtual address accesses the defined guard page, the \gls{os} denies the operation and the process will be notified by a segmentation fault.
+When the \gls{vaddr} accesses the defined guard page, the \gls{os} denies the operation and the process will be notified by a segmentation fault.
 This works as long one of these conditions is true: 
 \begin{itemize}
-    \item The guard page spans a virtual address range that is larger than the largest stack increment  
+    \item The guard page spans a \gls{vaddr} range that is larger than the largest stack increment  
     \item The area behind the stack page is unmapped and will also a page-fault
 \end{itemize}
 As the existence of vulnerability proves, these two conditions aren't always met.
@@ -1299,6 +1284,8 @@ The best case scenario is mere memory corruption and the crash of the applicatio
 In the worst case there's possible execution of arbitrary code, which can be by used by an attacker to gain control of the application and possibly the whole system.
 
 \subsubsection{Proposed Solutions}
+\label{context::weaknesses-mem-safety::manifestations::stack-clash::proposals}
+
 The researchers at \textit{qualys} suggest two solutions\cite[III]{TheStackClash}.
 
 The first proposed solution is to increase the guard page to 1MB or larger within the \gls{os}.
@@ -1308,60 +1295,65 @@ The second solution doesn't involve the \gls{os} but is about the userspace prog
 The suggestion is to compile all \glspl{app} on the system with the \gls{GCC}\cite{GCC540} with the \code{-fstack-check} option.
 This allegedly "prevents the stack-pointer from moving into another memory region without accessing the stack guard-page (it writes one word to every 4KB page allocated on the stack)."
 Besides the mention of this option, there is no explanation of what the exact technical outcome is.
-This is further investigated in \cref{rnd::weakness-mitig-eval::stack-protection}, as stack protection is also something procedures within the \gls{os} could make use of.
+This is further investigated in \cref{rnd::weakness-mitig-prev::stack-protection}, as stack protection is also something procedures within the \gls{os} could make use of.
 
 \chapter{Weakness Mitigation And Prevention Strategies}
 \label{context::weakness-mitigation}
 This chapter explains what can be done to mitigate and prevent software weaknesses, focusing on actions that can be taken by the developer.
 The first step is to leverage the \gls{CWE}'s database with its suggestions.
-With that information and the knowledge from previous chapters, it is then concluded that the choice of \gls{proglang} is significant for memory-safety in \gls{os} and \glspl{app}.
 
 \section{CWE-119 Mitigation Suggestions}
 \label{context::weakness-mitigation::cwe-119-suggestions}
 The \gls{CWE-119} lists mitigation attempts for these software life cycle phases: Requirements, Architecture and Design, Implementation, and Operation.
 
+\paragraph{Requirements Phase - Choose Language That Avoids Weaknesses}
 For the requirements phase, \gls{CWE-119} suggests to "use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid".
 Such languages "perform their own memory management are not subject to buffer overflows".
 
 This is followed by various other suggestions, of which the most relevant ones have been extracted into the following list.
 This list serves as additional test criteria against \gls{Rust}, evaluated in \cref{rnd}.
 
+\paragraph{Architecture and Design - Use Libraries or Frameworks}
+Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
+
+These libraries provide safer versions of overflow-prone string-handling functions: Safe C String Library (SafeStr) 
+
+\paragraph{Build and Compilation - Hardened Compilation}
+Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.
+
+Examples: FORTIFY\_SOURCE GCC flag
+
+\paragraph{Implementation}
+This refers to the phase during which the programmer writes code.
+        
+\subparagraph{Careful Buffer Handling}
 \begin{itemize}
-\item{Architecture and Design - Use Libraries or Frameworks
+\item Double check that your buffer is as large as you specify.
-    Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
+\item When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
+\item Check buffer boundaries if accessing the buffer in a loop and make sure you are not in danger of writing past the allocated space.
+\item If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
+\end{itemize}
 
-    These libraries provide safer versions of overflow-prone string-handling functions: Safe C String Library (SafeStr) 
+\subparagraph{Use Functions That Support Bounds}
-}
+\begin{itemize}
-\item{Build and Compilation - Hardened Compilation
-
-    Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.
-
-    Examples: FORTIFY\_SOURCE GCC flag, StackGuard
-}
-\item{Implementation  -
-        
-    Careful Buffer Handling:
-    \begin{itemize}
-    \item Double check that your buffer is as large as you specify.
-    \item When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
-    \item Check buffer boundaries if accessing the buffer in a loop and make sure you are not in danger of writing past the allocated space.
-    \item If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
-    \end{itemize}
-
-    Use Functions That Support Bounds: 
-    \begin{itemize}
     \item Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy.
     \item Create these if they are not available.
-    \end{itemize}
-}
-\item{Operation - Address Randomization
-
-    Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
-
-    Examples: Address Space Layout Randomization (ASLR),  Position-Independent Executables (PIE)
-}
 \end{itemize}
 
+\paragraph{Operation - Address Randomization}
+Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
+
+Examples: Address Space Layout Randomization (ASLR),  Position-Independent Executables (PIE)
+
+\section{Choice of Language}
+All of the suggestions provided by the \gls{CWE} are in one way or another related the to \gls{proglang}.
+Depending on the stage of the software development cycle, the suggestion is to either chose a stronger -- in the sense of less prone to weaknesses -- or avoid dangerous elements of a weaker \gls{proglang}.
+Combining this with the knowledge from previous chapters, it can be concluded that the choice of \gls{proglang} is significant for memory-safety in \gls{os} as well as \glspl{app}.
+This study does not have to workaround the weaknesses of any languages but is on to evaluating a potentially stronger. 
+Thus, the above information is another motivator for this study's topic.
+
+The next \cnameref{context::os-dev-lang-choice} further drives this evaluation.
+
 \chapter{OS Development: Choice of Programming Language}
 \label{context::os-dev-lang-choice}
 There are dozens of \glspl{proglang} to write \glspl{app}, but only a few are viable for writing \glspl{os}.
@@ -1379,48 +1371,100 @@ The \gls{proglang} can be designed with obligated rules, that make the written s
 
 \section{Requirements}
 \label{context::os-dev-lang-choice::requirements}
-Criteria for the choice of \gls{proglang} are much different for an \gls{os} than for other types of \glspl{app}
+Criteria for the choice of \gls{proglang} are much different for an \gls{os} than for other types of \glspl{app}.
-The following are requirements can be identified  
 
+\subsection{Technical}
 \begin{itemize}
-    \item{TODO: see CWE suggestions}
+    \item{Compiler that generates machine code}
+    \item{Inline \gls{cpu} instruction calls}
+    \item{Direct memory addressing}
+    \item{No requirement on an internal runtime or virtual machine}
+    \item{No dependency on platform functionality}
 \end{itemize}
 
-\section{Why not \glsentrytext{C}?}
+The above features are technical requirements to be able to produce code for the bare machine.
-With the growing number of vulnerabilities, various solutions have been proposed to increase the safety of C, either with static code analysis or via \gls{compiler}-generated checks imposed at runtime. (TODO: reference).  
 
-Static analysis are not very effective on a language that has not been designed to be safety-analyzed. TODO? reference?
+\subsection{Safety-Critical}
-For this reason there have been attempts to define subsets of the \gls{C} language that can be safety checked, TODO: refernces of Cyclone, CCured, etc..
+In addition, this study defines more theoretical requirements that help prevent memory-safety critical mistakes.
 
-Safety checks that are performed at runtime introduce a high degree of overhead, which makes it a nonviable option in the domain of \gls{os} development, where many code paths must be very fast to ensure the operation of high speed I/O devices\cite{Balasubramanian2017} or tasks with \gls{realtime} requirements. (TODO: explain realtime requirements)
+\begin{itemize}
-This has been forcing \gls{os} developers to prioritize performance over safety. (TODO: reference)
+    \item{Static analysis as part of the language design}
+    \item{Memory-safety as a 1st-class feature}
+    \item{Object oriented or similar type system that allows modeling of complex relations between types}
+\end{itemize}
+These features often come at the cost of a more complex language design, which results in a steep learning curve for beginners and might not seem worth it.
 
-\begin{markdown}
+As explained in \cnameref{context::introduction::memory-safety::time-aspect}, mistakes need to be identified as soon as possible, and static analysis is the technical method for this.
-# Flow of Reasoning
+The static analyzer can be designed to target different aspects and the language can be designed to offer these kind of aspects to the static analyzer.
-* How to mitigate distributed weaknesses
+For this study the primary aspect is memory-safety, which is assisted by the type system.
-    - Don't distribute vulnerable software
+For a simple example, a static analyzer should detect casts between incompatible pointer types, as it will eventually lead to undesired effects.
-    - Produce less vulnerabilities
-    OR
-    - Detect vulnerabilities
-* How to prevent vulnerabilities distribution?
-    - Human to make less mistakes; NOT VIABLE, see human aspect.
-    - Detect them before the \gls{app} is installed; see time aspect
-* How to detect vulnerabilities
-    - Write runtime tests for the program
-    - Analyze the source code
-* Runtime Tests
-    - Runs on every execution, thus wastes \gls{cpu} resources
-    - Program needs to handle it
-    -> Slow and too late in the software life cycle!
-* Source Code Analysis
-    - Difficult for low-level code, would require hardware knowledge
-    - Compilers are source code analysers by nature
-    - Additional tools can help, but this takes more effort
-    -> chose a compiler with high analysis standards
-* Choice of Compiler: Language Dependent
-    - C: Safe C, Cyclone, etc.: define sub language that is analyzable. MEH
-    - Rust: designed to be analyzable. WIN!
-* Rust
-    - Can the analyzes be extended to suite OS dev? 
-\end{markdown}
 
+\section{Why not \glsentrytext{C}}
+\gls{C} fulfills all these requirements, and since it's development it has replaced Assembly as the de-facto standard \gls{proglang} for writing \glspl{os}.
+As discussed in \cref{context::weaknesses-mem-safety} it has dangerous weaknesses.
+With the growing number of vulnerabilities, various solutions have been proposed to increase the safety of C, either with static code analysis or via \gls{compiler}-generated code that imposes runtime checks.
+
+Checks that are performed at runtime introduce a high degree of overhead, which makes it a nonviable option in the domain of \gls{os} development, where many code paths must be very fast to ensure the operation of high speed I/O devices\cite[p.~1]{Balasubramanian2017} or tasks with \gls{realtime} requirements.
+This has been forcing many developers to prioritize performance over safety, and others to look for alternatives.
+
+C allows direct access to memory via pointers and arithmetic thereof.
+Static source code analysis is difficult on \gls{C}, as it that has not been designed for this purpose and has too many ambiguities.\cite{Kowshik2002}
+C has no notion of objects beyond structs, which makes more complex memory structures, e.g. double-ended-queues trees, a hurdle to write and maintain safely.
+As recorded by the \gls{CWE} and shown in \cref{context::weaknesses-mem-safety::manifestations::cwe-ex}, even access to simple arrays is often mishandled.
+These criteria rule out \gls{C} for the purpose of this study.
+
+There have been attempts to define subsets of the \gls{C} language that can be safety checked, e.g. Cyclone\cite{Jim2002}, Control-C\cite{Kowshik2002}, but none has managed to take C's position.
+\paragraph{Control-C} 
+Control-C is created on top of \gls{llvm} as a statically provable memory-safe strict subset of C, purposed for real-time control systems.\cite{Kowshik2002}.
+Hardware requirements for handling safe runtime errors, which are known as \gls{cpu} exceptions on \gls{amd64}.
+In Control-C they could be caused by stack and heap overflow, stack overflow (e.g., due to infinite recursion) and heap overflow due to dynamic allocation.
+The latter sounds similar to the concept of guard pages and page-faults described in \cref{context::weaknesses-mem-safety::manifestations::stack-clash,rnd::weakness-mitig-prev::stack-protection::stack-clash}.
+Control-C and Rust have certain similarities, e.g. both and aim to guarantee memory-safety, use static type checks and make use of LLVM as the backend.
+Control-C uses affine transformation rules to statically guarantee bounds on array operations, which Rust does not do.
+It can only be speculated why Control-C hasn't gained popularity since its invention.
+It may be possible that it was mislabeled as a real-time only system language and was neglected in more generic language research.
+
+From today's perspective it appears to be clearly inferior to younger \gls{os} language candidates like Rust, e.g. as it is a subset of C and thus doesn't support object oriented paradigms.
+
+\section{LLVM: C and Rust}
+The \glsentrydesc{llvm} has become popular since it was introduced.
+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!]
+    \centering
+    \includegraphics[width=0.6\textwidth]{gfx/llvm-number-paper-pa.png}
+    \caption{Research Papers About LLVM since 2002}
+    \label{fig:llvm-research-papers-since-2002}
+\end{figure}
+\FloatBarrier
+
+It has since become a viable backend for the \gls{clang} \gls{compiler} and is also used by \gls{Rust}.
+
+The fronted \glspl{compiler} produce code for the \gls{llvm} Intermediate-Represantion, which is a hardware-independent.
+\gls{llvm} can produce machine code for supported architectures, a list of which is found on the official website \footnote{\url{https://llvm.org/docs/CompilerWriterInfo.html\#hardware}}.
+It contains all contemporary architectures, including \gls{amd64}.
+
+\section{Why Investigate Rust}
+Rust has gained popularity in among hobby \gls{os} developers.
+Reasons for this vary from simply challenging the possibility due to being convinced about its claimed features to guarantee memory-safety.
+Theese officially advertised features are\footnote{\url{https://www.rust-lang.org/}}
+\begin{itemize}
+    \item zero-cost abstractions
+    \item move semantics
+    \item guaranteed memory safety
+    \item threads without data races
+    \item trait-based generics
+    \item pattern matching
+    \item type inference
+    \item minimal runtime
+    \item efficient C bindings.
+\end{itemize}
+
+Research articles and existing projects that have appeared in recent months and years have contributed motivation and information to this study.
+Some of them are listed in \cref{rnd::existing-os-dev-with-rust::papers} next to the existing projects.
+Others are referenced throughout the various chapters of \cref{rnd}. 
+They have all been motivators and plenty of justification for this study to pay closer attention to Rust.
+
+\section{Next Steps}
+At this point, the assumption is made that \gls{Rust} can increase memory-safety in the \gls{os} in comparison to using \gls{C}.
+In the next \cnameref{rnd} it is studied which of the above features contribute to memory-safety in the \gls{os}, and the corresponding language items are identified.

src/docs/parts/eval_and_conclusion/eval_and_conclusion.tex

@@ -1,174 +1,246 @@
 % // vim: set ft=tex:
 \chapter{Evaluation}
+This chapter summarizes the findings of the previous parts. 
+The summary is then evaluated against the hypothesis, to create the foundation of a concise conclusion.
 
-\section{Premised Trust In Hardware}
+\section{Summary}
-Memory management mechanisms are partially implemented in the target system's hardware which can't be verified by at time of development.
+After defining an exact definition for memory-safety within the OS was found in \cref{context::introduction::memory-safety::def}, various aspects of software vulnerability origin were discussed.
+The human was identified to be an error prone weak spot in the process of OS development.
+It was found that technical solutions that can detect these errors are to be used as early in the development process as possible.
+This point in time was declared the time of software compilation.
 
-\section{Safety Of Low-Level Code in Rust}
+OS development concepts were introduced to for the AMD64 architecture, to lay out the knowledge that to allow an understanding and implementation of OS concepts on AMD64, which was set out for the development process.
-% TODO: Is the static analysis of hardware specific assembly code possible and useful at all?
-% TODO: LLVM knows about the target and can potentially give hints about hardware specific instructions
 
-\section{Protecting \textit{'static}ally allocated Resources}
+Common Weaknesses in software were identified, and demonstrated how these lead to concrete vulnerabilities.
+The stack clash was explained as an architectural and design issue, which requires changes in stack overflow detection in userspace software.
+The origin of many of the weaknesses was identified to be based on weak languages, and Rust was verified to be a good alternative to C.
+Research was conducted on these common weaknesses through other scientific studies.
+This found weaknesses based on
+\begin{itemize}
+    \item use-after-free
+    \item indexing out of bounds
+    \item iterator invalidation
+    \item data races
+\end{itemize}
+to be prevented by Rust's ownership system\cite{Beingessner2015}.
+Stack protection experiments were conducted and found Rust to be less vulnerable to return address manipulation.
+These were found to be effectively prevented by static analysis under normal circumstances, since it required multiple explicit features to intentionally force the manipulation to succeed.
+Stack overflow could not be statically detected by trying various tweaks to the compiler.
+Information that would be required for this static detection was evaluated, and was found to be not completely available in the present compiler architecture.
 
-\section{The Necessary Evils of \textit{unsafe}}
+A practical introduction to Rust was given, overviewing the encountered language features and the ones that were explicitly investigated.
+Rust was found to have extension features only limited by the complexity of its usage, demonstrated by an implementation of pure-software information flow control.
 
-\section{Extending Rust For Safe OS Development}
+Existing OS development efforts were investigated to serve as a codebase for the development and to evaluate their usage of Rust for achieving memory-safety.
+Redox OS was found to not be vulnerable to the Stack Clash due to design decisions in the OS.
+Blog OS was found to demonstrate extensive usage of Rust's type system to model underlying hardware and prevent mistakes in the paging implementation.
 
-\chapter{Summary}
+Implementation of preemptive multitasking was chosen to be based on intermezzOS for its simplicity.
+After initial problems with the build and debugging tools were solved, the development could proceed quickly.
+Based on the state of intermezzOS that allowed the system to boot, a working preemptive multitasking was implemented successfully.
+The implementation only supports static memory allocation and no dynamic memory management.
+Writing a hardware-driver for the Programmable-Interrupt-Timer was well supported by the module and type system, which allowed an accurate modeling of the underlying hardware.
+Global OS state variables can be protected by requiring Rust's unsafe keyword and disallowing the same within additional defined tasks.
+Extensive usage of the unsafe keyword was required to perform raw hardware access, but could be limited to well-defined functions.
+Inline machine-instructions were found to be well designed and in-line with the rest of the language.
+One occurrence of a cast from an untyped pointer was necessary, within the context-switching interrupt handler, to manipulate data on the stack.
+A stack overflow on user defined tasks could not be prevented by static analysis, only detected by the OS at runtime.
 
-\chapter{Final Conclusion}
+\subsection{Thesis Evaluation}
-Safety - or security for this matter - is not something that can be achieved absolutely.
+Rust's static analysis lacks the ability of static stack overflow detection, which is a significant counter-indication to the hypothesis.
-It grows successively and gives the \gls{os} developers and the end-users a \emph{feeling} of safety, until another vulnerability is found and disclosed.
+Using Rust's static memory analysis does not fully guarantee In-Kernel memory-safe.
 
-% TODO: repeat that rust *can* be used to increase safety in the OS,
+\chapter{Conclusions}
-% TODO: how?
+While hypothesis was not proven, Rust is still considered to be a significant improvement over C for OS development purposes.
-% but it doesn't guarantee it per-se
 
-\chapter{Scratchpad}
+\paragraph{Rust detects many errors early}
+It prevents many errors at compile-time where, they are harmless.
+The language is fully extendable via language extensions that allow the insertion of new language features that can be hooked into the static analysis.
+The process of making Rust suitable for OS development is driven by many hobby and a few production intended projects.
 
+\section{Hardware is still hard, but Rust is worth learning}
+Even though Rust is understood as a memory-safe language, following the hardware specification is still a memory-safety critical requirement.
+OS developers must use the unsafe keyword when performing raw hardware access, which is designed to make them think twice when using it.
+If the chance is presented, Rust should be chosen any time over C for implementing software that is close to hardware.
+This might be difficult in the first place, but should pay off long-term, as less vulnerabilities will be detected throughout the extended life-cycle of the software.
 
-\begin{figure}[h!]
+\section{Next Step}
-\centering
+Further investigation is required to propose a solution for the lack of static stack size estimation in \gls{Rust}.
-\begin{subfigure}[T]{0.50\textwidth}
+The immediate next step is to bring this issue up for a discussion in the Rust community.
-    \tikzmarkcountprep{callee}
-    \begin{compactminted}[
-            escapeinside=??,linenos,autogobble,highlightlines={}
-    ]{nasm}
-    mov    rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?
-    add    rsp,0x50?\tikzmarkcount?             
-    pop    rbp?\tikzmarkcount?
-    ret?\tikzmarkcount?
-    \end{compactminted} 
-    \tikzmarkdrawcircles
-\caption{Subfig A}
-\end{subfigure}
-\begin{subfigure}[T]{0.45\textwidth}
-    \foreach \x/\xtext in {
-        1/{
-            this is going to be a really long sentence with line wraps 
-        },
-        2/{
-            second
-        }
-    } {\tikzmarkcircle{\x}\xtext\\}
-\caption{Subfig B}
-\end{subfigure}
-\caption{Whadup}
-\label{Whadup}
-\end{figure}
 
-\begin{listing}
+% \chapter{Scratchpad}
-    \tikzmarkcountprep{example1}
-    \begin{minted}[
-            label=example1,labelposition=all,escapeinside=??,linenos,autogobble,highlightlines={}
-    ]{nasm}
-    mov    rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?  ?\tikzmark{brace1upper}?
-    add    rsp,0x50?\tikzmarkcount?             
-    pop    rbp?\tikzmarkcount?
-    ret?\tikzmarkcount?                              ?\tikzmark{brace1lower}?
-    \end{minted} 
-    \begin{minted}[
-            escapeinside=??,linenos,autogobble,highlightlines={}
-    ]{nasm}
-    mov    rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?
-    add    rsp,0x50                ?\tikzmarkcount?
-    pop    rbp                     ?\tikzmarkcount?
-    ret                            ?\tikzmarkcount?
-    \end{minted} 
-    \begin{tikzpicture}[remember picture,overlay]
-        \draw[thick,decorate,decoration={brace,raise=1ex}] 
-            (pic cs:brace1upper)+(0,1.5ex) -- node[shape=coordinate][right=1.5ex] (a) {} (pic cs:brace1lower);
-        \fill (a)+(2ex,0) circle[opacity=1,radius=1.1ex] node[white,font=\small]{a};
-    \end{tikzpicture}
-    \tikzmarkdrawcircles
-    \caption{Minted Listing A}
 % 
-    \foreach \x/\xtext in {
+% \begin{figure}[ht!]
-        1/{
+% \centering
-            this is going to be a really long sentence with line wraps 
+% \begin{subfigure}[T]{0.50\textwidth}
-        \\}
+%     \tikzmarkcountprep{callee}
-        ,2/{
+%     \begin{compactminted}[
-            second
+%             escapeinside=??,linenos,autogobble,highlightlines={}
-        \\} 
+%     ]{nasm}
-        ,5/{},6/{
+%     mov    rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?
-            hi
+%     add    rsp,0x50?\tikzmarkcount?             
-        \\}
+%     pop    rbp?\tikzmarkcount?
-        ,a/{
+%     ret?\tikzmarkcount?
-            hi
+%     \end{compactminted} 
-        \\}
+%     \tikzmarkdrawcircles
-    } {\tikzmarkcircle{\x}\xtext}
+% \caption{Subfig A}
+% \end{subfigure}
+% \begin{subfigure}[T]{0.45\textwidth}
+%     \foreach \x/\xtext in {
+%         1/{
+%             this is going to be a really long sentence with line wraps 
+%         },
+%         2/{
+%             second
+%         }
+%     } {\tikzmarkcircle{\x}\xtext\\}
+% \caption{Subfig B}
+% \end{subfigure}
+% \caption{Whadup}
+% \label{Whadup}
+% \end{figure}
 % 
-\end{listing}
+% \begin{listing}
-\FloatBarrier
+%     \tikzmarkcountprep{example1}
-
+%     \begin{minted}[
-\begin{listing}
+%             label=example1,labelposition=all,escapeinside=??,linenos,autogobble,highlightlines={}
-    \tikzset{/minted/basename=example}
+%     ]{nasm}
-    \begin{minted}[label=caller,labelposition=topline,escapeinside=??,highlightlines={},autogobble,linenos,breaklines=true]{nasm}
+%     mov    rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?  ?\tikzmark{brace1upper}?
-    mov    rcx,QWORD PTR [rbp-0x40] ; copy 1st arg to rcx
+%     add    rsp,0x50?\tikzmarkcount?             
-    mov    rsi,QWORD PTR [rbp-0x38] ; copy 2nd arg to rsi
+%     pop    rbp?\tikzmarkcount?
-    mov    rdx,QWORD PTR [rbp-0x30] ; copy 3rd arg to rdx
+%     ret?\tikzmarkcount?                              ?\tikzmark{brace1lower}?
-    mov    QWORD PTR [rbp-0x60],rdi ; save rdi to make it available
+%     \end{minted} 
-    mov    rdi,rcx                  ; copy 1st arg to rdi
+%     \begin{minted}[
-    mov    QWORD PTR [rbp-0x68],rax ; save rax to make it available
+%             escapeinside=??,linenos,autogobble,highlightlines={}
-    call   7490?\tikzmark{exampleprecallfrom}? <_ZN14stack_handling3sum17h8f12d2383e075691E> ; push '756e' onto the stack and jump to the first instruction of sum
+%     ]{nasm}
-    mov    QWORD PTR [rbp-0x28],rax ; save return value
+%     mov    rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?
-    \end{minted}
+%     add    rsp,0x50                ?\tikzmarkcount?
-    \caption{Function Call with Three Arguments}
+%     pop    rbp                     ?\tikzmarkcount?
-    \begin{tikzpicture}[remember picture,overlay]
+%     ret                            ?\tikzmarkcount?
-        \draw[red,thick] (pic cs:exampleprecallfrom) ellipse (0.7cm and 12pt) node { \textbf{1} };
+%     \end{minted} 
-        \fill[blue] (pic cs:example1) circle (0.1cm);
+%     \begin{tikzpicture}[remember picture,overlay]
-        \fill[yellow] (pic cs:example2) circle (0.1cm);
+%         \draw[thick,decorate,decoration={brace,raise=1ex}] 
-    \end{tikzpicture}
+%             (pic cs:brace1upper)+(0,1.5ex) -- node[shape=coordinate][right=1.5ex] (a) {} (pic cs:brace1lower);
-\end{listing}
+%         \fill (a)+(2ex,0) circle[opacity=1,radius=1.1ex] node[white,font=\small]{a};
-
+%     \end{tikzpicture}
-\begin{tikzpicture}[node distance=2cm,
+%     \tikzmarkdrawcircles
-        startstop/.style={rectangle, rounded corners, minimum width=3cm, minimum height=1cm,text centered, draw=black, fill=red!30},
+%     \caption{Minted Listing A}
-        io/.style = {trapezium, trapezium left angle=70, trapezium right angle=110, minimum width=3cm, minimum height=1cm, text centered, draw=black, fill=blue!30},
+% %
-        process/.style = {rectangle, minimum width=1cm, minimum height=1cm, text centered, text width=3cm, draw=black, fill=orange!30},
+%     \foreach \x/\xtext in {
-        decision/.style = {diamond, minimum width=3cm, minimum height=1cm, text centered, draw=black, fill=green!30},
+%         1/{
-        arrow/.style = {thick,->,>=stealth} 
+%             this is going to be a really long sentence with line wraps 
-    ]
+%         \\}
-
+%         ,2/{
-%\node (start) [startstop] {Start};
+%             second
-%\node (in1) [io, below of=start] {Input};
+%         \\} 
-%\node (pro1) [process, below of=in1] {Process 1};
+%         ,5/{},6/{
-%\node (dec1) [decision, below of=pro1, yshift=-0.5cm] {Decision 1};
+%             hi
-%\node (pro2a) [process, below of=dec1, yshift=-0.5cm] {Process 2a text text text text text text text text text text};
+%         \\}
-%\node (pro2b) [process, right of=dec1, xshift=2cm] {Process 2b};
+%         ,a/{
-%\node (out1) [io, below of=pro2a] {Output};
+%             hi
-%\node (stop) [startstop, below of=out1] {Stop};
+%         \\}
+%     } {\tikzmarkcircle{\x}\xtext}
+% %
+% \end{listing}
+% \FloatBarrier
 % 
-%\draw [arrow] (start) -- (in1);
+% \begin{listing}
-%\draw [arrow] (in1) -- (pro1);
+%     \tikzset{/minted/basename=example}
-%\draw [arrow] (pro1) -- (dec1);
+%     \begin{minted}[label=caller,labelposition=topline,escapeinside=??,highlightlines={},autogobble,linenos,breaklines=true]{nasm}
-%\draw [arrow] (dec1) -- node[anchor=east] {yes} (pro2a);
+%     mov    rcx,QWORD PTR [rbp-0x40] ; copy 1st arg to rcx
-%\draw [arrow] (dec1) -- node[anchor=south] {no} (pro2b);
+%     mov    rsi,QWORD PTR [rbp-0x38] ; copy 2nd arg to rsi
-%\draw [arrow] (pro2b) |- (pro1);
+%     mov    rdx,QWORD PTR [rbp-0x30] ; copy 3rd arg to rdx
-%\draw [arrow] (pro2a) -- (out1);
+%     mov    QWORD PTR [rbp-0x60],rdi ; save rdi to make it available
-%\draw [arrow] (out1) -- (stop);
+%     mov    rdi,rcx                  ; copy 1st arg to rdi
-
+%     mov    QWORD PTR [rbp-0x68],rax ; save rax to make it available
-\node[process,xshift=0ex,yshift=-0ex] (ua_back) {User Applications};
+%     call   7490?\tikzmark{exampleprecallfrom}? <_ZN14stack_handling3sum17h8f12d2383e075691E> ; push '756e' onto the stack and jump to the first instruction of sum
-\node[process,xshift=0ex,yshift=-1ex] at (ua_back) {User Applications};
+%     mov    QWORD PTR [rbp-0x28],rax ; save return value
-\node[process,xshift=0ex,yshift=-2ex] (ua) at (ua_back) {User Applications};
+%     \end{minted}
-
+%     \caption{Function Call with Three Arguments}
-\node[process,xshift=0ex,yshift=-0ex,below of=ua] (sl_back) {System Libraries};
+%     \begin{tikzpicture}[remember picture,overlay]
-\node[process,xshift=0ex,yshift=-1ex] at (sl_back) {System Libraries};
+%         \draw[red,thick] (pic cs:exampleprecallfrom) ellipse (0.7cm and 12pt) node { \textbf{1} };
-\node[process,xshift=0ex,yshift=-2ex] (sl) at (sl_back) {System Libraries};
+%         \fill[blue] (pic cs:example1) circle (0.1cm);
-
+%         \fill[yellow] (pic cs:example2) circle (0.1cm);
-\node[process,xshift=0ex,yshift=-0ex,below of=sl] (os_back) {OS};
+%     \end{tikzpicture}
-\node[process,xshift=0ex,yshift=-1ex] at (os_back) {OS API};
+% \end{listing}
-\node[process,xshift=0ex,yshift=-2ex] (os) at (os_back) {OS};
+% 
-
+% \begin{tikzpicture}[node distance=2cm,
-\node[process,xshift=0ex,yshift=-0ex,left of=mem, below of=os] (cpu) {CPU};
+%         startstop/.style={rectangle, rounded corners, minimum width=3cm, minimum height=1cm,text centered, draw=black, fill=red!30},
-\node[process,xshift=0ex,yshift=-0ex,right of=cpu] (mem) {Memory};
+%         io/.style = {trapezium, trapezium left angle=70, trapezium right angle=110, minimum width=3cm, minimum height=1cm, text centered, draw=black, fill=blue!30},
-\node[process,xshift=0ex,yshift=-0ex,right of=mem] (otherhw) {Other HW};
+%         process/.style = {rectangle, minimum width=1cm, minimum height=1cm, text centered, text width=3cm, draw=black, fill=orange!30},
-
+%         decision/.style = {diamond, minimum width=3cm, minimum height=1cm, text centered, draw=black, fill=green!30},
-\draw [arrow] (ua) -- (sl);
+%         arrow/.style = {thick,->,>=stealth} 
-\draw [arrow] (sl) -- (os);
+%     ]
-\draw [arrow] (os) -- (cpu);
+% 
-\draw [arrow] (os) -- (mem);
+% %\node (start) [startstop] {Start};
-\draw [arrow] (os) -- (otherhw);
+% %\node (in1) [io, below of=start] {Input};
-
+% %\node (pro1) [process, below of=in1] {Process 1};
-TODO: improve
+% %\node (dec1) [decision, below of=pro1, yshift=-0.5cm] {Decision 1};
-
+% %\node (pro2a) [process, below of=dec1, yshift=-0.5cm] {Process 2a text text text text text text text text text text};
-\end{tikzpicture}
+% %\node (pro2b) [process, right of=dec1, xshift=2cm] {Process 2b};
+% %\node (out1) [io, below of=pro2a] {Output};
+% %\node (stop) [startstop, below of=out1] {Stop};
+% %
+% %\draw [arrow] (start) -- (in1);
+% %\draw [arrow] (in1) -- (pro1);
+% %\draw [arrow] (pro1) -- (dec1);
+% %\draw [arrow] (dec1) -- node[anchor=east] {yes} (pro2a);
+% %\draw [arrow] (dec1) -- node[anchor=south] {no} (pro2b);
+% %\draw [arrow] (pro2b) |- (pro1);
+% %\draw [arrow] (pro2a) -- (out1);
+% %\draw [arrow] (out1) -- (stop);
+% 
+% \node[process,xshift=0ex,yshift=-0ex] (ua_back) {User Applications};
+% \node[process,xshift=0ex,yshift=-1ex] at (ua_back) {User Applications};
+% \node[process,xshift=0ex,yshift=-2ex] (ua) at (ua_back) {User Applications};
+% 
+% \node[process,xshift=0ex,yshift=-0ex,below of=ua] (sl_back) {System Libraries};
+% \node[process,xshift=0ex,yshift=-1ex] at (sl_back) {System Libraries};
+% \node[process,xshift=0ex,yshift=-2ex] (sl) at (sl_back) {System Libraries};
+% 
+% \node[process,xshift=0ex,yshift=-0ex,below of=sl] (os_back) {OS};
+% \node[process,xshift=0ex,yshift=-1ex] at (os_back) {OS API};
+% \node[process,xshift=0ex,yshift=-2ex] (os) at (os_back) {OS};
+% 
+% \node[process,xshift=0ex,yshift=-0ex,left of=mem, below of=os] (cpu) {CPU};
+% \node[process,xshift=0ex,yshift=-0ex,right of=cpu] (mem) {Memory};
+% \node[process,xshift=0ex,yshift=-0ex,right of=mem] (otherhw) {Other HW};
+% 
+% \draw [arrow] (ua) -- (sl);
+% \draw [arrow] (sl) -- (os);
+% \draw [arrow] (os) -- (cpu);
+% \draw [arrow] (os) -- (mem);
+% \draw [arrow] (os) -- (otherhw);
+% 
+% TODO: improve
+% 
+% \end{tikzpicture}
+% 
+% \begin{markdown}
+% # Flow of Reasoning
+% * How to mitigate distributed weaknesses
+%     - Don't distribute vulnerable software
+%     - Produce less vulnerabilities
+%     OR
+%     - Detect vulnerabilities
+% * How to prevent vulnerabilities distribution?
+%     - Human to make less mistakes; NOT VIABLE, see human aspect.
+%     - Detect them before the \gls{app} is installed; see time aspect
+% * How to detect vulnerabilities
+%     - Write runtime tests for the program
+%     - Analyze the source code
+% * Runtime Tests
+%     - Runs on every execution, thus wastes \gls{cpu} resources
+%     - Program needs to handle it
+%     -> Slow and too late in the software life cycle!
+% * Source Code Analysis
+%     - Difficult for low-level code, would require hardware knowledge
+%     - Compilers are source code analysers by nature
+%     - Additional tools can help, but this takes more effort
+%     -> chose a compiler with high analysis standards
+% * Choice of Compiler: Language Dependent
+%     - C: Safe C, Cyclone, etc.: define sub language that is analyzable. MEH
+%     - Rust: designed to be analyzable. WIN!
+% * Rust
+%     - Can the analyzes be extended to suite OS dev? 
+% \end{markdown}

src/docs/thesis.bib

@@ -3,14 +3,198 @@ Any changes to this file will be lost if it is regenerated by Mendeley.
 
 BibTeX export options can be customized via Options -> BibTeX in Mendeley Desktop
 
-@article{GCC540,
+@article{Beingessner2015,
-abstract = {This manual documents how to use the GNU compilers, as well as their features and incom- patibilities, and how to report bugs. It corresponds to the compilers (GCC) version 5.4.0. The internals of the GNU compilers, including how to port them to new targets and some information about how to write front ends for new languages, are documented in a separate manual. See Section Introduction in GNU Compiler Collection (GCC) Internals.},
+author = {Beingessner, Alexis},
-author = {Stallman, Richard M},
+file = {:home/steveej/src/steveej/msc-thesis/docs/You can't spell trust without Rust.pdf:pdf},
-file = {:home/steveej/src/steveej/msc-thesis/docs/gcc-5.4.0.pdf:pdf},
+title = {{YOU CAN'T SPELL TRUST WITHOUT RUST}},
-isbn = {188211437X},
+year = {2015}
-journal = {Development},
+}
-title = {{Using the GNU Compiler Collection}},
+@misc{OsPhilOpp,
-url = {https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc.pdf}
+author = {Oppermann, Philipp},
+title = {{Writing an OS in Rust}},
+url = {https://os.phil-opp.com/}
+}
+@article{Balasubramanian2017,
+abstract = {Rust is a new system programming language that offers a practical and safe alternative to C. Rust is unique in that it enforces safety without runtime overhead, most importantly, without the overhead of garbage collection. While zero-cost safety is remarkable on its own, we argue that the super-powers of Rust go beyond safety. In particular, Rust's linear type system enables capabilities that cannot be implemented efficiently in traditional languages, both safe and unsafe, and that dramatically improve security and reliability of system software. We show three examples of such capabilities: zero-copy software fault isolation, efficient static information flow analysis, and automatic checkpointing. While these capabilities have been in the spotlight of systems research for a long time, their practical use is hindered by high cost and complexity. We argue that with the adoption of Rust these mechanisms will become commoditized.},
+author = {Balasubramanian, Abhiram and Baranowski, Marek S and Burtsev, Anton and Irvine, Uc and Rakamari, Zvonimir and Ryzhyk, Leonid and Research, Vmware},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/DRAFT$\backslash$: System Programming in Rust$\backslash$: Beyond Safety.pdf:pdf},
+title = {{DRAFT: System Programming in Rust: Beyond Safety}},
+year = {2017}
+}
+@inproceedings{Ma2013,
+abstract = {—Aiming at the problem of higher memory consumption and lower execution efficiency during the dynamic detecting to C/C++ programs memory vulnerabilities, this paper presents a dynamic detection method called ISC. The ISC improves the Safe-C using pointer analysis technology. Firstly, the ISC defines a simple and efficient fat pointer representation instead of the safe pointer in the Safe-C. Furthermore, the ISC uses the unification-based analysis algorithm with one level flow static pointer. This identification reduces the number of pointers that need to be converted to fat pointers. Then in the process of program running, the ISC detects memory vulnerabilities through constantly inspecting the attributes of fat pointers. Experimental results indicate that the ISC could detect memory vulnerabilities such as buffer overflows and dangling pointers. Comparing with the Safe-C, the ISC dramatically reduces the memory consumption and lightly improves the execution efficiency.},
+author = {Ma, Rui and Chen, Lingkui and Hu, Changzhen and Xue, Jingfeng and Zhao, Xiaolin},
+booktitle = {Proceedings - 2013 IEEE 11th International Conference on Dependable, Autonomic and Secure Computing, DASC 2013},
+doi = {10.1109/DASC.2013.37},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/A Dynamic Detection Method to C-C++ Programs Memory Vulnerabilities Based on Pointer Analysis.pdf:pdf},
+isbn = {9781479933815},
+keywords = {dynamic detecting,fat pointer,improved Safe-C,memory vulnerability,pointer analysis},
+pages = {52--57},
+title = {{A dynamic detection method to C/C++ programs memory vulnerabilities based on pointer analysis}},
+year = {2013}
+}
+@article{Dhurjati2003,
+abstract = {Traditional approaches to enforcing memory safety of programs rely heavily on runtime checks of memory accesses and on garbage collection, both of which are unattractive for embedded applications. The long-term goal of our work is to enable 100{\%} static enforcement of memory safety for embedded programs through advanced compiler techniques and minimal semantic restrictions on programs. The key result of this paper is a compiler technique that ensures memory safety of dynamically allocated memory without programmer annotations, runtime checks, or garbage collection, and works for a large subclass of type-safe C programs. The technique is based on a fully automatic pool allocation (i.e., region-inference) algorithm for C programs we developed previously, and it ensures safety of dynamically allocated memory while retaining explicit deallocation of individual objects within regions (to avoid garbage collection). For a diverse set of embedded C programs (and using a previous technique to avoid null pointer checks), we show that we are able to statically ensure the safety of pointer and dynamic memory usage in all these programs. We also describe some improvements over our previous work in static checking of array accesses. Overall, we achieve 100{\%} static enforcement of memory safety without new language syntax for a significant subclass of embedded C programs, and the subclass is much broader if array bounds checks are ignored.},
+author = {Dhurjati, D and Kowshik, S and Adve, V and Lattner, C},
+doi = {10.1145/780742.780743},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/Memory Safety Without Runtime Checks or Garbage.pdf:pdf},
+isbn = {0362-1340},
+issn = {03621340},
+journal = {Acm Sigplan Notices},
+keywords = {automatic pool allocation,compilers,embedded systems,languages,programming languages,region management,security,static analysis},
+number = {7},
+pages = {69--80},
+title = {{Memory safety without runtime checks or garbage collection}},
+volume = {38},
+year = {2003}
+}
+@article{Junker,
+author = {Junker, Stefan},
+file = {:home/steveej/src/steveej/msc-thesis/src/docs/thesis.pdf:pdf},
+title = {{Guarantees On In-Kernel Memory-Safety Using Rust's Static Code Analysis}}
+}
+@misc{Endler,
+author = {Endler, Matthias},
+title = {{A curated list of static analysis tools, linters and code quality checkers for various programming languages}},
+url = {https://github.com/mre/awesome-static-analysis}
+}
+@article{Corporation2011,
+abstract = {The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 1, describes the basic architecture and programming environment of Intel 64 and IA-32 processors. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 2A {\&} 2B, describe the instruction set of the processor and the opcode struc- ture. These volumes apply to application programmers and to programmers who write operating systems or executives. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 3A {\&} 3B, describe the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating- system and BIOS designers. In addition, the Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 3B, addresses the programming environment for classes of software that host operating systems.},
+author = {Corporation, Intel},
+doi = {10.1109/MAHC.2010.22},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf:pdf},
+isbn = {253665-057US},
+issn = {15222594},
+journal = {System},
+keywords = {253665,IA-32 architecture,Intel 64},
+number = {253665},
+title = {{Intel {\textregistered} 64 and IA-32 Architectures Software Developer ' s Manual Volume 3}},
+volume = {3},
+year = {2011}
+}
+@article{Matz2009,
+author = {Matz, M and Hubicka, J and Jaeger, a and Mitchell, M},
+file = {:home/steveej/src/steveej/msc-thesis/docs/System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.7.pdf:pdf},
+isbn = {013877630X},
+pages = {1--128},
+pmid = {2477614},
+title = {{System V Application Binary Interface AMD64 Architecture Processor Supplement}},
+url = {papers2://publication/uuid/CD8D5668-B1F5-4FE3-BAD8-25F1E589A9E5},
+year = {2009}
+}
+@misc{MITRE-CWE-134,
+author = {MITRE},
+title = {{CWE-134: Use of Externally-Controlled Format String}},
+url = {http://cwe.mitre.org/data/definitions/134.html},
+urldate = {2017-09-20}
+}
+@article{Seri2017,
+abstract = {The dangers of Bluetooth implementations: Unveiling zero day vulnerabilities and security flaws in modern Bluetooth stacks.},
+author = {Seri, Ben and Vishnepolsky, Gregory},
+file = {:home/steveej/src/steveej/msc-thesis/docs/BlueBorne Technical White Paper.pdf:pdf},
+title = {{BlueBorne}},
+url = {http://go.armis.com/blueborne-technical-paper},
+year = {2017}
+}
+@article{Reed2015,
+abstract = {Rust is a new systems language that uses some advanced type system features, specifically affine types and regions, to statically guarantee memory safety and eliminate the need for a garbage collector. While each individual addition to the type system is well understood in isolation and are known to be sound, the combined system is not known to be sound. Furthermore, Rust uses a novel checking scheme for its regions, known as the Borrow Checker, that is not known to be correct. Since Rust's goal is to be a safer alternative to C/C++, we should ensure that this safety scheme actually works. We present a formal semantics that captures the key features relevant to memory safety, unique pointers and borrowed references, specifies how they guarantee memory safety, and describes the operation of the Borrow Checker. We use this model to prove the soudness of some core operations and justify the conjecture that the model, as a whole, is sound. Additionally, our model provides a syntactic version of the Borrow Checker, which may be more understandable than the non-syntactic version in Rust.},
+author = {Reed, Eric},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/Patina$\backslash$:  A Formalization of the Rust Programming Language.pdf:pdf},
+number = {February},
+pages = {1--37},
+title = {{Patina: A Formalization of the Rust Programming Language}},
+year = {2015}
+}
+@misc{IEEEspectrum-proglangs,
+author = {IEEE},
+title = {{Interactive: The Top Programming Languages 2017}},
+url = {https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2017},
+urldate = {2017-09-08},
+year = {2017}
+}
+@article{Mailloux1969,
+author = {Mailloux, B. J. and Peck, J. E L and Koster, C. H A},
+doi = {10.1007/BF02163002},
+file = {:home/steveej/src/steveej/msc-thesis/docs/Algol68-RevisedReport.pdf:pdf},
+isbn = {978-3-662-38646-0},
+issn = {0029599X},
+journal = {Numerische Mathematik},
+number = {2},
+pages = {79--218},
+title = {{Report on the Algorithmic Language ALGOL 68}},
+volume = {14},
+year = {1969}
+}
+@misc{TockOS,
+title = {{Tock OS}},
+url = {https://www.tockos.org/},
+urldate = {2017-09-22}
+}
+@article{Xu2015,
+abstract = {Since vulnerabilities in Linux kernel are on the increase, attackers have turned their interests into related exploitation techniques. However, compared with numerous researches on exploiting use-after-free vulnerabilities in the user applications, few efforts studied how to exploit use-after-free vulnerabilities in Linux kernel due to the difficulties that mainly come from the uncertainty of the kernel memory layout. Without specific information leakage, attackers could only conduct a blind memory overwriting strategy trying to corrupt the critical part of the kernel, for which the success rate is negligible. In this work, we present a novel memory collision strategy to exploit the use-after-free vulnerabilities in Linux kernel reliably. The insight of our exploit strategy is that a probabilistic memory collision can be constructed according to the widely deployed kernel memory reuse mechanisms, which significantly increases the success rate of the attack. Based on this insight, we present two practical memory collision attacks: An object-based attack that leverages the memory recycling mechanism of the kernel allocator to achieve freed vulnerable object covering, and a physmap-based attack that takes advantage of the overlap between the physmap and the SLAB caches to achieve a more flexible memory manipulation. Our proposed attacks are universal for various Linux kernels of different architectures and could successfully exploit systems with use-after-free vulnerabilities in kernel. Particularly, we achieve privilege escalation on various popular Android devices (kernel version{\textgreater}=4.3) including those with 64-bit processors by exploiting the CVE-2015-3636 use-after-free vulnerability in Linux kernel. To our knowledge, this is the first generic kernel exploit for the latest version of Android. Finally, to defend this kind of memory collision, we propose two corresponding mitigation schemes.},
+author = {Xu, Wen and Li, Juanru and Shu, Junliang and Yang, Wenbo and Xie, Tianyi and Zhang, Yuanyuan and Gu, Dawu},
+doi = {10.1145/2810103.2813637},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/From Collision To Exploitation$\backslash$: Unleashing Use-After-Free Vulnerabilities in Linux Kernel.pdf:pdf},
+isbn = {978-1-4503-3832-5},
+issn = {15437221},
+journal = {Ccs},
+keywords = {linux kernel exploit,memory collision,user-after-free vulnerability},
+pages = {414--425},
+title = {{From Collision To Exploitation: Unleashing Use-After-Free Vulnerabilities in Linux Kernel}},
+url = {http://dl.acm.org/citation.cfm?doid=2810103.2813637},
+year = {2015}
+}
+@misc{MITRE-CWE-635,
+author = {MITRE},
+title = {{CWE-635: Weaknesses Used by NVD}},
+url = {http://cwe.mitre.org/data/definitions/635.html},
+urldate = {2017-08-05}
+}
+@misc{NVD,
+title = {{National Vulnerability Database}},
+url = {https://nvd.nist.gov/},
+urldate = {2017-08-05}
+}
+@article{Jim2002,
+abstract = {Cyclone is a safe dialect of C. It has been designed from the ground up to prevent the buer overflows, format string attacks, and memory management errors that are common in C programs, while retaining C's syntax and semantics. This paper examines safety violations enabled by C's design, and shows how Cyclone avoids them, without giving up C's hallmark control over low-level details such as data representation and memory management.},
+author = {Jim, Trevor and Morrisett, Greg and Grossman, Dan and Hicks, Michael and Cheney, James and Wang, Yanling},
+isbn = {1-880446-00-6},
+journal = {USENIX Annual Technical Conference},
+pages = {275--288},
+title = {{Cyclone: A safe dialect of C}},
+url = {http://www.usenix.org/events/usenix02/full{\_}papers/jim/jim{\_}html/},
+year = {2002}
+}
+@misc{MITRE-CWE-633,
+author = {MITRE},
+title = {{CWE-633: Weaknesses that Affect Memory}},
+url = {http://cwe.mitre.org/data/definitions/633.html},
+urldate = {2017-08-31},
+year = {2017}
+}
+@misc{MITRE-CWE-119,
+author = {MITRE},
+booktitle = {2.11},
+title = {{CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer}},
+url = {http://cwe.mitre.org/data/definitions/119.html},
+urldate = {2017-08-31},
+year = {2017}
+}
+@misc{MITRE-CWE-122,
+author = {MITRE},
+title = {{CWE-122: Heap-based Buffer Overflow}},
+url = {http://cwe.mitre.org/data/definitions/122.html},
+urldate = {2017-09-26}
+}
+@inproceedings{Kuznetsov2014,
+abstract = {Systems code is often written in low-level languages like C/C++, which offer many benefits but also dele- gate memory management to programmers. This invites memory safety bugs that attackers can exploit to divert control flow and compromise the system. Deployed de- fense mechanisms (e.g., ASLR, DEP) are incomplete, and stronger defense mechanisms (e.g., CFI) often have high overhead and limited guarantees [19, 15, 9]. We introduce code-pointer integrity (CPI), a new de- sign point that guarantees the integrity of all code point- ers in a program (e.g., function pointers, saved return ad- dresses) and thereby prevents all control-flow hijack at- tacks, including return-oriented programming. We also introduce code-pointer separation (CPS), a relaxation of CPI with better performance properties. CPI and CPS offer substantially better security-to-overhead ratios than the state of the art, they are practical (we protect a complete FreeBSD system and over 100 packages like apache and postgresql), effective (prevent all attacks in the RIPE benchmark), and efficient: on SPEC CPU2006, CPS averages 1.2{\%} overhead for C and 1.9{\%} for C/C++, while CPI's overhead is 2.9{\%} for C and 8.4{\%} for C/C++. A prototype implementation of CPI and CPS can be obtained from http://levee.epfl.ch. 1},
+author = {Kuznetsov, Volodymyr and Szekeres, L{\'{a}}szl{\'{o}} and Payer, Mathias},
+booktitle = {Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation},
+isbn = {9781931971164},
+pages = {147--163},
+title = {{Code-pointer integrity}},
+url = {https://www.usenix.org/conference/osdi14/technical-sessions/presentation/kuznetsov{\%}5Cnhttps://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf?utm{\_}source=dlvr.it{\&}utm{\_}medium=tumblr},
+year = {2014}
 }
 @article{Lattner2005,
 abstract = {The LLVM Compiler Infrastructure (http://llvm.cs. uiuc.edu) is a$\backslash$nrobust system that is well suited for a wide variety of research$\backslash$nand development work. This brief paper introduces the LLVM system$\backslash$nand provides pointers to more extensive documentation, complementing$\backslash$nthe tutorial presented at LCPC.},
@@ -30,6 +214,124 @@ title = {{The LLVM Compiler Framework and Infrastructure Tutorial}},
 url = {http://dx.doi.org/10.1007/11532378{\_}2},
 year = {2005}
 }
+@article{Nilsson2017,
+author = {Nilsson, Fredrik},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/A Rust-based Runtime for the Internet of Things.pdf:pdf},
+title = {{A Rust-based Runtime for the Internet of Things}},
+year = {2017}
+}
+@misc{MITRE-CWE,
+author = {MITRE},
+title = {{CWE - Common Weakness Enumeration}},
+url = {http://cwe.mitre.org},
+urldate = {2017-08-31},
+year = {2017}
+}
+@article{Szekeres2013,
+abstract = {Memory corruption bugs in software written in low-level languages like C or C++ are one of the oldest problems in computer security. The lack of safety in these languages allows attackers to alter the program's behavior or take full control over it by hijacking its control flow. This problem has existed for more than 30 years and a vast number of potential solutions have been proposed, yet memory corruption attacks continue to pose a serious threat. Real world exploits show that all currently deployed protections can be defeated. This paper sheds light on the primary reasons for this by describing attacks that succeed on today's systems. We systematize the current knowledge about various protection techniques by setting up a general model for memory corrup- tion attacks. Using this model we show what policies can stop which attacks. The model identifies weaknesses of currently deployed techniques, as well as other proposed protections enforcing stricter policies. We analyze the reasons why protection mechanisms imple- menting stricter polices are not deployed. To achieve wide adoption, protection mechanisms must support a multitude of features and must satisfy a host of requirements. Especially important is performance, as experience shows that only solutions whose overhead is in reasonable bounds get deployed. A comparison of different enforceable policies helps de- signers of new protection mechanisms in finding the balance between effectiveness (security) and efficiency.We identify some open research problems, and provide suggestions on improving the adoption of newer techniques.},
+author = {Szekeres, L??szl?? and Payer, Mathias and Wei, Tao and Song, Dawn},
+doi = {10.1109/SP.2013.13},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/SoK$\backslash$: Eternal War in Memory.pdf:pdf},
+isbn = {9780769549774},
+issn = {10816011},
+journal = {Proceedings - IEEE Symposium on Security and Privacy},
+pages = {48--62},
+title = {{SoK: Eternal war in memory}},
+year = {2013}
+}
+@article{Arpaci-Dusseau2015,
+abstract = {A book covering the fundamentals of operating systems, including virtualization of the CPU and memory, threads and concurrency, and file and storage systems. Written by professors active in the field for 20 years, this text has been developed in the classrooms of the University of Wisconsin-Madison, and has been used in the instruction of thousands of students.},
+author = {{Arpaci-Dusseau Remzi}, Arpaci-Dusseau Andrea},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/operating{\_}systems{\_}{\_}three{\_}easy{\_}pieces{\_}{\_}electronic{\_}version{\_}0{\_}91{\_}.pdf:pdf},
+journal = {Arpaci-Dusseau},
+number = {0.91},
+pages = {665},
+title = {{Operating Systems: Three Easy Pieces}},
+volume = {Electronic},
+year = {2015}
+}
+@article{Kowshik2002,
+abstract = {This paper considers the problem of providing safe programming support and enabling secure online software upgrades for control software in real-time control systems. In such systems, offline techniques for ensuring code safety are greatly preferable to online techniques. We propose a language called Control-C that is essentially a subset of C, but with key restrictions designed to ensure that memory safety of code can be verified entirely by static checking, under certain system assumptions. The language permits pointer-based data structures, restricted dynamic memory allocation, and restricted array operations, without requiring any runtime checks on memory operations and without garbage collection. The language restrictions have been chosen based on an understanding of both compiler technology and the needs of real-time control systems. The paper describes the language design and a compiler implementation for Control-C. We use control codes from three different experimental control systems to evaluate the suitability of the language for these codes, the effort required to port them to Control-C, and the effectiveness of the compiler in detecting a wide range of potential security violations for one of the systems.},
+author = {Kowshik, Sumant and Dhurjati, Dinakar and Adve, Vikram},
+doi = {10.1145/581677.581678},
+file = {:home/steveej/src/steveej/msc-thesis/docs/Ensuring Code Safety Without Runtime Checks for Real-Time Control Systems.pdf:pdf},
+isbn = {1581135750},
+journal = {Proceedings of the international conference on Compilers, architecture, and synthesis for embedded systems - CASES '02},
+keywords = {compiler,control,programming language,real-time,static analy-},
+pages = {288},
+title = {{Ensuring code safety without runtime checks for real-time control systems}},
+url = {http://portal.acm.org/citation.cfm?doid=581630.581678},
+year = {2002}
+}
+@misc{TheStackClash,
+author = {Advisory, Qualys Security},
+file = {:home/steveej/src/steveej/msc-thesis/docs/stack-clash.txt:txt},
+title = {{The Stack Clash}},
+url = {https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt}
+}
+@book{AMD64Vol1,
+author = {AMD},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/AMD64 Architecture Programmer's Manual Volume 1$\backslash$: Application Programming.pdf:pdf},
+keywords = {AMD64,SIMD,extended media instructions,legacy m},
+number = {26568},
+title = {{AMD64 Architecture Programmer's Manual Volume 1: Application Programming}},
+volume = {4},
+year = {2012}
+}
+@article{Chisnall2015,
+abstract = {We propose a new memory-safe interpretation of the C ab-stract machine that provides stronger protection to benefit security and debugging. Despite ambiguities in the specifi-cation intended to provide implementation flexibility, con-temporary implementations of C have converged on a mem-ory model similar to the PDP-11, the original target for C. This model lacks support for memory safety despite well-documented impacts on security and reliability. Attempts to change this model are often hampered by as-sumptions embedded in a large body of existing C code, dat-ing back to the memory model exposed by the original C compiler for the PDP-11. Our experience with attempting to implement a memory-safe variant of C on the CHERI ex-perimental microprocessor led us to identify a number of problematic idioms. We describe these as well as their in-teraction with existing memory safety schemes and the as-sumptions that they make beyond the requirements of the C specification. Finally, we refine the CHERI ISA and abstract model for C, by combining elements of the CHERI capabil-ity model and fat pointers, and present a softcore CPU that implements a C abstract machine that can run legacy C code with strong memory protection guarantees.},
+author = {Chisnall, David and Rothwell, Colin and Watson, Robert N M and Woodruff, Jonathan and Vadera, Munraj and Moore, Simon W and Roe, Michael and Davis, Brooks and Neumann, Peter G},
+doi = {10.1145/2694344.2694367},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/Beyond the PDP-11$\backslash$: Architectural support for a memory-safe C abstract machine.pdf:pdf},
+isbn = {9781450328357},
+issn = {01635964},
+journal = {Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems},
+pages = {117--130},
+title = {{Beyond the PDP-11 : Architectural support for a memory-safe C abstract machine}},
+url = {http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201503-asplos2015-cheri-cmachine.pdf},
+year = {2015}
+}
+@article{GCC540,
+abstract = {This manual documents how to use the GNU compilers, as well as their features and incom- patibilities, and how to report bugs. It corresponds to the compilers (GCC) version 5.4.0. The internals of the GNU compilers, including how to port them to new targets and some information about how to write front ends for new languages, are documented in a separate manual. See Section Introduction in GNU Compiler Collection (GCC) Internals.},
+author = {Stallman, Richard M},
+file = {:home/steveej/src/steveej/msc-thesis/docs/gcc-5.4.0.pdf:pdf},
+isbn = {188211437X},
+journal = {Development},
+title = {{Using the GNU Compiler Collection}},
+url = {https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc.pdf}
+}
+@article{Getreu2016,
+annote = {- runtime checkis are expensive 
+
+- critical with energy restriction on the target device},
+author = {Getreu, Jens},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/Embedded System Security with Rust - Case Study of Heartbleed.pdf:pdf},
+pages = {1--24},
+title = {{Embedded System Security with Rust}},
+year = {2016}
+}
+@book{AMD64Vol2,
+author = {AMD},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/AMD64 Architecture Programmer's Manual Volume 2$\backslash$: System Programming.pdf:pdf},
+keywords = {24593,AMD64 Architecture Programmer's Manual Volume 2: S},
+number = {24592},
+title = {{AMD64 Architecture Programmer's Manual Volume 2: System Programming}},
+volume = {1},
+year = {2012}
+}
+@article{Caballero2012,
+abstract = {Use-after-free vulnerabilities are rapidly growing in popularity, especially for exploiting web browsers. Use-after-free (and double-free) vulnerabilities are caused by a program operating on a dangling pointer. In this work we propose early detection, a novel runtime approach for finding and diagnosing use-after-free and double-free vulnerabilities. While previous work focuses on the creation of the vulnerability (i.e., the use of a dangling pointer), early detection shifts the focus to the creation of the dangling pointer(s) at the root of the vulnerability. Early detection increases the effectiveness of testing by identifying unsafe dangling pointers in executions where they are created but not used. It also accelerates vulnerability analysis and minimizes the risk of incomplete fixes, by automatically collecting information about all dangling pointers involved in the vulnerability. We implement our early detection technique in a tool called Undangle. We evaluate Undangle for vulnerability analysis on 8 real-world vulnerabilities. The analysis uncovers that two separate vulnerabilities in Firefox had a common root cause and that their patches did not completely fix the underlying bug. We also evaluate Undangle for testing on the Firefox web browser identifying a potential vulnerability.},
+author = {Caballero, Juan and Grieco, Gustavo and Marron, Mark and Nappa, Antonio},
+doi = {10.1145/2338965.2336769},
+isbn = {9781450314541},
+issn = {1450314546},
+journal = {ISSTA},
+keywords = {automated testing,binary analysis,debugging,dynamic analysis},
+pages = {133},
+title = {{Undangle: early detection of dangling pointers in use-after-free and double-free vulnerabilities}},
+url = {http://dl.acm.org/citation.cfm?doid=2338965.2336769},
+year = {2012}
+}
 @article{Levy2015a,
 abstract = {Rust, a new systems programming language, provides compile-time memory safety checks to help eliminate runtime bugs that manifest from improper memory management. This feature is advantageous for operating system development, and especially for embedded OS development, where recovery and debugging are particularly challenging. However, embedded platforms are highly event-based, and Rust's memory safety mechanisms largely presume threads. In our experience developing an operating system for embedded systems in Rust, we have found that Rust's ownership model prevents otherwise safe resource sharing common in the embedded domain, conflicts with the reality of hardware resources, and hinders using closures for programming asynchronously. We describe these experiences and how they relate to memory safety as well as illustrate our workarounds that preserve the safety guarantees to the largest extent possible. In addition, we draw from our experience to propose a new language extension to Rust that would enable it to provide better memory safety tools for event-driven platforms.},
 author = {Levy, Amit and Andersen, Michael P. and Campbell, Bradford and Culler, David and Dutta, Prabal and Ghena, Branden and Levis, Philip and Pannuto, Pat},
@@ -57,241 +359,3 @@ title = {{Intel {\textregistered} 64 and IA-32 Architectures Software Developer
 volume = {1},
 year = {2011}
 }
-@misc{IEEEspectrum-proglangs,
-author = {IEEE},
-title = {{Interactive: The Top Programming Languages 2017}},
-url = {https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2017},
-urldate = {2017-09-08},
-year = {2017}
-}
-@article{Xu2015,
-abstract = {Since vulnerabilities in Linux kernel are on the increase, attackers have turned their interests into related exploitation techniques. However, compared with numerous researches on exploiting use-after-free vulnerabilities in the user applications, few efforts studied how to exploit use-after-free vulnerabilities in Linux kernel due to the difficulties that mainly come from the uncertainty of the kernel memory layout. Without specific information leakage, attackers could only conduct a blind memory overwriting strategy trying to corrupt the critical part of the kernel, for which the success rate is negligible. In this work, we present a novel memory collision strategy to exploit the use-after-free vulnerabilities in Linux kernel reliably. The insight of our exploit strategy is that a probabilistic memory collision can be constructed according to the widely deployed kernel memory reuse mechanisms, which significantly increases the success rate of the attack. Based on this insight, we present two practical memory collision attacks: An object-based attack that leverages the memory recycling mechanism of the kernel allocator to achieve freed vulnerable object covering, and a physmap-based attack that takes advantage of the overlap between the physmap and the SLAB caches to achieve a more flexible memory manipulation. Our proposed attacks are universal for various Linux kernels of different architectures and could successfully exploit systems with use-after-free vulnerabilities in kernel. Particularly, we achieve privilege escalation on various popular Android devices (kernel version{\textgreater}=4.3) including those with 64-bit processors by exploiting the CVE-2015-3636 use-after-free vulnerability in Linux kernel. To our knowledge, this is the first generic kernel exploit for the latest version of Android. Finally, to defend this kind of memory collision, we propose two corresponding mitigation schemes.},
-author = {Xu, Wen and Li, Juanru and Shu, Junliang and Yang, Wenbo and Xie, Tianyi and Zhang, Yuanyuan and Gu, Dawu},
-doi = {10.1145/2810103.2813637},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/From Collision To Exploitation$\backslash$: Unleashing Use-After-Free Vulnerabilities in Linux Kernel.pdf:pdf},
-isbn = {978-1-4503-3832-5},
-issn = {15437221},
-journal = {Ccs},
-keywords = {linux kernel exploit,memory collision,user-after-free vulnerability},
-pages = {414--425},
-title = {{From Collision To Exploitation: Unleashing Use-After-Free Vulnerabilities in Linux Kernel}},
-url = {http://dl.acm.org/citation.cfm?doid=2810103.2813637},
-year = {2015}
-}
-@inproceedings{Ma2013,
-abstract = {—Aiming at the problem of higher memory consumption and lower execution efficiency during the dynamic detecting to C/C++ programs memory vulnerabilities, this paper presents a dynamic detection method called ISC. The ISC improves the Safe-C using pointer analysis technology. Firstly, the ISC defines a simple and efficient fat pointer representation instead of the safe pointer in the Safe-C. Furthermore, the ISC uses the unification-based analysis algorithm with one level flow static pointer. This identification reduces the number of pointers that need to be converted to fat pointers. Then in the process of program running, the ISC detects memory vulnerabilities through constantly inspecting the attributes of fat pointers. Experimental results indicate that the ISC could detect memory vulnerabilities such as buffer overflows and dangling pointers. Comparing with the Safe-C, the ISC dramatically reduces the memory consumption and lightly improves the execution efficiency.},
-author = {Ma, Rui and Chen, Lingkui and Hu, Changzhen and Xue, Jingfeng and Zhao, Xiaolin},
-booktitle = {Proceedings - 2013 IEEE 11th International Conference on Dependable, Autonomic and Secure Computing, DASC 2013},
-doi = {10.1109/DASC.2013.37},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/A Dynamic Detection Method to C-C++ Programs Memory Vulnerabilities Based on Pointer Analysis.pdf:pdf},
-isbn = {9781479933815},
-keywords = {dynamic detecting,fat pointer,improved Safe-C,memory vulnerability,pointer analysis},
-pages = {52--57},
-title = {{A dynamic detection method to C/C++ programs memory vulnerabilities based on pointer analysis}},
-year = {2013}
-}
-@article{Mailloux1969,
-author = {Mailloux, B. J. and Peck, J. E L and Koster, C. H A},
-doi = {10.1007/BF02163002},
-file = {:home/steveej/src/steveej/msc-thesis/docs/Algol68-RevisedReport.pdf:pdf},
-isbn = {978-3-662-38646-0},
-issn = {0029599X},
-journal = {Numerische Mathematik},
-number = {2},
-pages = {79--218},
-title = {{Report on the Algorithmic Language ALGOL 68}},
-volume = {14},
-year = {1969}
-}
-@article{Corporation2011,
-abstract = {The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 1, describes the basic architecture and programming environment of Intel 64 and IA-32 processors. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 2A {\&} 2B, describe the instruction set of the processor and the opcode struc- ture. These volumes apply to application programmers and to programmers who write operating systems or executives. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 3A {\&} 3B, describe the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating- system and BIOS designers. In addition, the Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 3B, addresses the programming environment for classes of software that host operating systems.},
-author = {Corporation, Intel},
-doi = {10.1109/MAHC.2010.22},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf:pdf},
-isbn = {253665-057US},
-issn = {15222594},
-journal = {System},
-keywords = {253665,IA-32 architecture,Intel 64},
-number = {253665},
-title = {{Intel {\textregistered} 64 and IA-32 Architectures Software Developer ' s Manual Volume 3}},
-volume = {3},
-year = {2011}
-}
-@article{Balasubramanian2017,
-abstract = {Rust is a new system programming language that offers a practical and safe alternative to C. Rust is unique in that it enforces safety without runtime overhead, most importantly, without the overhead of garbage collection. While zero-cost safety is remarkable on its own, we argue that the super-powers of Rust go beyond safety. In particular, Rust's linear type system enables capabilities that cannot be implemented efficiently in traditional languages, both safe and unsafe, and that dramatically improve security and reliability of system software. We show three examples of such capabilities: zero-copy software fault isolation, efficient static information flow analysis, and automatic checkpointing. While these capabilities have been in the spotlight of systems research for a long time, their practical use is hindered by high cost and complexity. We argue that with the adoption of Rust these mechanisms will become commoditized.},
-author = {Balasubramanian, Abhiram and Baranowski, Marek S and Burtsev, Anton and Irvine, Uc and Rakamari, Zvonimir and Ryzhyk, Leonid and Research, Vmware},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/DRAFT$\backslash$: System Programming in Rust$\backslash$: Beyond Safety.pdf:pdf},
-title = {{DRAFT: System Programming in Rust: Beyond Safety}},
-year = {2017}
-}
-@article{Matz2009,
-author = {Matz, M and Hubicka, J and Jaeger, a and Mitchell, M},
-file = {:home/steveej/src/steveej/msc-thesis/docs/System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.7.pdf:pdf},
-isbn = {013877630X},
-pages = {1--128},
-pmid = {2477614},
-title = {{System V Application Binary Interface AMD64 Architecture Processor Supplement}},
-url = {papers2://publication/uuid/CD8D5668-B1F5-4FE3-BAD8-25F1E589A9E5},
-year = {2009}
-}
-@article{Chisnall2015,
-abstract = {We propose a new memory-safe interpretation of the C ab-stract machine that provides stronger protection to benefit security and debugging. Despite ambiguities in the specifi-cation intended to provide implementation flexibility, con-temporary implementations of C have converged on a mem-ory model similar to the PDP-11, the original target for C. This model lacks support for memory safety despite well-documented impacts on security and reliability. Attempts to change this model are often hampered by as-sumptions embedded in a large body of existing C code, dat-ing back to the memory model exposed by the original C compiler for the PDP-11. Our experience with attempting to implement a memory-safe variant of C on the CHERI ex-perimental microprocessor led us to identify a number of problematic idioms. We describe these as well as their in-teraction with existing memory safety schemes and the as-sumptions that they make beyond the requirements of the C specification. Finally, we refine the CHERI ISA and abstract model for C, by combining elements of the CHERI capabil-ity model and fat pointers, and present a softcore CPU that implements a C abstract machine that can run legacy C code with strong memory protection guarantees.},
-author = {Chisnall, David and Rothwell, Colin and Watson, Robert N M and Woodruff, Jonathan and Vadera, Munraj and Moore, Simon W and Roe, Michael and Davis, Brooks and Neumann, Peter G},
-doi = {10.1145/2694344.2694367},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/Beyond the PDP-11$\backslash$: Architectural support for a memory-safe C abstract machine.pdf:pdf},
-isbn = {9781450328357},
-issn = {01635964},
-journal = {Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems},
-pages = {117--130},
-title = {{Beyond the PDP-11 : Architectural support for a memory-safe C abstract machine}},
-url = {http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201503-asplos2015-cheri-cmachine.pdf},
-year = {2015}
-}
-@article{Dhurjati2003,
-abstract = {Traditional approaches to enforcing memory safety of programs rely heavily on runtime checks of memory accesses and on garbage collection, both of which are unattractive for embedded applications. The long-term goal of our work is to enable 100{\%} static enforcement of memory safety for embedded programs through advanced compiler techniques and minimal semantic restrictions on programs. The key result of this paper is a compiler technique that ensures memory safety of dynamically allocated memory without programmer annotations, runtime checks, or garbage collection, and works for a large subclass of type-safe C programs. The technique is based on a fully automatic pool allocation (i.e., region-inference) algorithm for C programs we developed previously, and it ensures safety of dynamically allocated memory while retaining explicit deallocation of individual objects within regions (to avoid garbage collection). For a diverse set of embedded C programs (and using a previous technique to avoid null pointer checks), we show that we are able to statically ensure the safety of pointer and dynamic memory usage in all these programs. We also describe some improvements over our previous work in static checking of array accesses. Overall, we achieve 100{\%} static enforcement of memory safety without new language syntax for a significant subclass of embedded C programs, and the subclass is much broader if array bounds checks are ignored.},
-author = {Dhurjati, D and Kowshik, S and Adve, V and Lattner, C},
-doi = {10.1145/780742.780743},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/Memory Safety Without Runtime Checks or Garbage.pdf:pdf},
-isbn = {0362-1340},
-issn = {03621340},
-journal = {Acm Sigplan Notices},
-keywords = {automatic pool allocation,compilers,embedded systems,languages,programming languages,region management,security,static analysis},
-number = {7},
-pages = {69--80},
-title = {{Memory safety without runtime checks or garbage collection}},
-volume = {38},
-year = {2003}
-}
-@misc{MITRE-CWE,
-author = {MITRE},
-title = {{CWE - Common Weakness Enumeration}},
-url = {http://cwe.mitre.org},
-urldate = {2017-08-31},
-year = {2017}
-}
-@article{Affairs2015,
-author = {Affairs, Post Doctoral},
-file = {:home/steveej/src/steveej/msc-thesis/docs/You can't spell trust without Rust.pdf:pdf},
-title = {{YOU CAN ' T SPELL TRUST WITHOUT RUST alexis beingessner Master ' s in Computer Science Carleton University}},
-year = {2015}
-}
-@inproceedings{Kuznetsov2014,
-abstract = {Systems code is often written in low-level languages like C/C++, which offer many benefits but also dele- gate memory management to programmers. This invites memory safety bugs that attackers can exploit to divert control flow and compromise the system. Deployed de- fense mechanisms (e.g., ASLR, DEP) are incomplete, and stronger defense mechanisms (e.g., CFI) often have high overhead and limited guarantees [19, 15, 9]. We introduce code-pointer integrity (CPI), a new de- sign point that guarantees the integrity of all code point- ers in a program (e.g., function pointers, saved return ad- dresses) and thereby prevents all control-flow hijack at- tacks, including return-oriented programming. We also introduce code-pointer separation (CPS), a relaxation of CPI with better performance properties. CPI and CPS offer substantially better security-to-overhead ratios than the state of the art, they are practical (we protect a complete FreeBSD system and over 100 packages like apache and postgresql), effective (prevent all attacks in the RIPE benchmark), and efficient: on SPEC CPU2006, CPS averages 1.2{\%} overhead for C and 1.9{\%} for C/C++, while CPI's overhead is 2.9{\%} for C and 8.4{\%} for C/C++. A prototype implementation of CPI and CPS can be obtained from http://levee.epfl.ch. 1},
-author = {Kuznetsov, Volodymyr and Szekeres, L{\'{a}}szl{\'{o}} and Payer, Mathias},
-booktitle = {Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation},
-isbn = {9781931971164},
-pages = {147--163},
-title = {{Code-pointer integrity}},
-url = {https://www.usenix.org/conference/osdi14/technical-sessions/presentation/kuznetsov{\%}5Cnhttps://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf?utm{\_}source=dlvr.it{\&}utm{\_}medium=tumblr},
-year = {2014}
-}
-@misc{TheStackClash,
-author = {Advisory, Qualys Security},
-file = {:home/steveej/src/steveej/msc-thesis/docs/stack-clash.txt:txt},
-title = {{The Stack Clash}},
-url = {https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt}
-}
-@article{Caballero2012,
-abstract = {Use-after-free vulnerabilities are rapidly growing in popularity, especially for exploiting web browsers. Use-after-free (and double-free) vulnerabilities are caused by a program operating on a dangling pointer. In this work we propose early detection, a novel runtime approach for finding and diagnosing use-after-free and double-free vulnerabilities. While previous work focuses on the creation of the vulnerability (i.e., the use of a dangling pointer), early detection shifts the focus to the creation of the dangling pointer(s) at the root of the vulnerability. Early detection increases the effectiveness of testing by identifying unsafe dangling pointers in executions where they are created but not used. It also accelerates vulnerability analysis and minimizes the risk of incomplete fixes, by automatically collecting information about all dangling pointers involved in the vulnerability. We implement our early detection technique in a tool called Undangle. We evaluate Undangle for vulnerability analysis on 8 real-world vulnerabilities. The analysis uncovers that two separate vulnerabilities in Firefox had a common root cause and that their patches did not completely fix the underlying bug. We also evaluate Undangle for testing on the Firefox web browser identifying a potential vulnerability.},
-author = {Caballero, Juan and Grieco, Gustavo and Marron, Mark and Nappa, Antonio},
-doi = {10.1145/2338965.2336769},
-isbn = {9781450314541},
-issn = {1450314546},
-journal = {ISSTA},
-keywords = {automated testing,binary analysis,debugging,dynamic analysis},
-pages = {133},
-title = {{Undangle: early detection of dangling pointers in use-after-free and double-free vulnerabilities}},
-url = {http://dl.acm.org/citation.cfm?doid=2338965.2336769},
-year = {2012}
-}
-@book{AMD64Vol2,
-author = {AMD},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/AMD64 Architecture Programmer's Manual Volume 2$\backslash$: System Programming.pdf:pdf},
-keywords = {24593,AMD64 Architecture Programmer's Manual Volume 2: S},
-number = {24592},
-title = {{AMD64 Architecture Programmer's Manual Volume 2: System Programming}},
-volume = {1},
-year = {2012}
-}
-@article{Junker,
-author = {Junker, Stefan},
-file = {:home/steveej/src/steveej/msc-thesis/src/docs/thesis.pdf:pdf},
-title = {{Guarantees On In-Kernel Memory-Safety Using Rust's Static Code Analysis}}
-}
-@article{Nilsson2017,
-author = {Nilsson, Fredrik},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/A Rust-based Runtime for the Internet of Things.pdf:pdf},
-title = {{A Rust-based Runtime for the Internet of Things}},
-year = {2017}
-}
-@article{Szekeres2013,
-abstract = {Memory corruption bugs in software written in low-level languages like C or C++ are one of the oldest problems in computer security. The lack of safety in these languages allows attackers to alter the program's behavior or take full control over it by hijacking its control flow. This problem has existed for more than 30 years and a vast number of potential solutions have been proposed, yet memory corruption attacks continue to pose a serious threat. Real world exploits show that all currently deployed protections can be defeated. This paper sheds light on the primary reasons for this by describing attacks that succeed on today's systems. We systematize the current knowledge about various protection techniques by setting up a general model for memory corrup- tion attacks. Using this model we show what policies can stop which attacks. The model identifies weaknesses of currently deployed techniques, as well as other proposed protections enforcing stricter policies. We analyze the reasons why protection mechanisms imple- menting stricter polices are not deployed. To achieve wide adoption, protection mechanisms must support a multitude of features and must satisfy a host of requirements. Especially important is performance, as experience shows that only solutions whose overhead is in reasonable bounds get deployed. A comparison of different enforceable policies helps de- signers of new protection mechanisms in finding the balance between effectiveness (security) and efficiency.We identify some open research problems, and provide suggestions on improving the adoption of newer techniques.},
-author = {Szekeres, L??szl?? and Payer, Mathias and Wei, Tao and Song, Dawn},
-doi = {10.1109/SP.2013.13},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/SoK$\backslash$: Eternal War in Memory.pdf:pdf},
-isbn = {9780769549774},
-issn = {10816011},
-journal = {Proceedings - IEEE Symposium on Security and Privacy},
-pages = {48--62},
-title = {{SoK: Eternal war in memory}},
-year = {2013}
-}
-@book{AMD64Vol1,
-author = {AMD},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/AMD64 Architecture Programmer's Manual Volume 1$\backslash$: Application Programming.pdf:pdf},
-keywords = {AMD64,SIMD,extended media instructions,legacy m},
-number = {26568},
-title = {{AMD64 Architecture Programmer's Manual Volume 1: Application Programming}},
-volume = {4},
-year = {2012}
-}
-@article{Getreu2016,
-annote = {- runtime checkis are expensive 
-
-- critical with energy restriction on the target device},
-author = {Getreu, Jens},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/Embedded System Security with Rust - Case Study of Heartbleed.pdf:pdf},
-pages = {1--24},
-title = {{Embedded System Security with Rust}},
-year = {2016}
-}
-@article{Reed2015,
-abstract = {Rust is a new systems language that uses some advanced type system features, specifically affine types and regions, to statically guarantee memory safety and eliminate the need for a garbage collector. While each individual addition to the type system is well understood in isolation and are known to be sound, the combined system is not known to be sound. Furthermore, Rust uses a novel checking scheme for its regions, known as the Borrow Checker, that is not known to be correct. Since Rust's goal is to be a safer alternative to C/C++, we should ensure that this safety scheme actually works. We present a formal semantics that captures the key features relevant to memory safety, unique pointers and borrowed references, specifies how they guarantee memory safety, and describes the operation of the Borrow Checker. We use this model to prove the soudness of some core operations and justify the conjecture that the model, as a whole, is sound. Additionally, our model provides a syntactic version of the Borrow Checker, which may be more understandable than the non-syntactic version in Rust.},
-author = {Reed, Eric},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/Patina$\backslash$:  A Formalization of the Rust Programming Language.pdf:pdf},
-number = {February},
-pages = {1--37},
-title = {{Patina: A Formalization of the Rust Programming Language}},
-year = {2015}
-}
-@misc{MITRE-CWE-633,
-author = {MITRE},
-title = {{CWE-633: Weaknesses that Affect Memory}},
-url = {http://cwe.mitre.org/data/definitions/633.html},
-urldate = {2017-08-31},
-year = {2017}
-}
-@misc{Endler,
-author = {Endler, Matthias},
-title = {{A curated list of static analysis tools, linters and code quality checkers for various programming languages}},
-url = {https://github.com/mre/awesome-static-analysis}
-}
-@article{Arpaci-Dusseau2015,
-abstract = {A book covering the fundamentals of operating systems, including virtualization of the CPU and memory, threads and concurrency, and file and storage systems. Written by professors active in the field for 20 years, this text has been developed in the classrooms of the University of Wisconsin-Madison, and has been used in the instruction of thousands of students.},
-author = {{Arpaci-Dusseau Remzi}, Arpaci-Dusseau Andrea},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/operating{\_}systems{\_}{\_}three{\_}easy{\_}pieces{\_}{\_}electronic{\_}version{\_}0{\_}91{\_}.pdf:pdf},
-journal = {Arpaci-Dusseau},
-number = {0.91},
-pages = {665},
-title = {{Operating Systems: Three Easy Pieces}},
-volume = {Electronic},
-year = {2015}
-}
-@misc{MITRE-CWE-119,
-author = {MITRE},
-booktitle = {2.11},
-title = {{CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer}},
-url = {http://cwe.mitre.org/data/definitions/119.html},
-urldate = {2017-08-31},
-year = {2017}
-}

src/docs/thesis.tex

@@ -1,6 +1,7 @@
+% // vim: set ft=tex:
 \documentclass[12pt,a4paper]{report}
 
-\overfullrule=5mm
+%\overfullrule=1cm
 
 \usepackage[utf8]{inputenc}
 
@@ -8,7 +9,7 @@
 \usepackage{blindtext,color,fancyhdr}
 
 \usepackage{geometry}
-\geometry{a4paper, top=25mm, left=30mm, right=35mm,  bottom=35mm, headsep=10mm, footskip=12mm}
+\geometry{a4paper, top=25mm, left=35mm, right=30mm,  bottom=35mm, headsep=10mm, footskip=12mm}
 
 \usepackage{multirow,tabularx,tabu}
 \usepackage{booktabs}
@@ -64,6 +65,8 @@
 
 \newcommand{\topic}{Guarantees On In-Kernel Memory-Safety Using Rust's Static Code Analysis}
 \newcommand{\authorOne}{Stefan Junker}
+\newcommand{\authorOneBirthDate}{23.12.1986}
+\newcommand{\authorOneBirthCity}{Rottweil}
 \newcommand{\authorOneInit}{SJ}
 \newcommand{\authorOnestreet}{Alemannenstr. 7}
 \newcommand{\authorOnezip}{78467}
@@ -76,11 +79,23 @@
 \newcommand{\startdate}{2017/4/1}
 \newcommand{\submitdate}{2017/9/29}
 \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
 \setcounter{secnumdepth}{3}
 
-\date{Summersemester 2017}
+\date{}
 \title{\topic}
 
 \author{authorOne}
@@ -230,30 +245,22 @@
 \makeatother
 \include{glossary}
 
-\overfullrule=1cm
 
 \begin{document}
 
-    %TODO: \include{cover}
+    \include{cover}
 \pagestyle{front}
     \include{title}
 
 \pagestyle{preamble}
     \include{abstract}
-    %TODO: \include{affidavit}
+    \include{affidavit}
     \cleardoublepage
     \newcounter{roman_pagenumbers} % save page number
     \setcounter{roman_pagenumbers}{\value{page}}
 
 \pagestyle{main}
 	%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.
-
 
 	\tableofcontents
 
@@ -269,7 +276,7 @@
     \include{parts/research_and_development/research_and_development}
 
     \part{Evaluation And Conclusion}
-    \label{eval_and_conclusion}
+    \label{enc}
     \include{parts/eval_and_conclusion/eval_and_conclusion}
 
 	\newpage