thesis: explain more of the difficulties in C

src/docs/glossary.tex

@@ -211,3 +211,11 @@
         Specific variant of an \gls{sac} defined by the \gls{appcorg}.
     }
 }
+
+\newglossaryentry{CWE}{
+    name=Common Weakness Enumeration,
+    description={
+        A formal list of software weakness types.
+    }
+}
+

src/docs/parts/context/context.tex

@@ -7,31 +7,20 @@ The \gls{OS} is the only \gls{app} that has unrestricted access to these resourc
 % Purpose of the Study
 %The Purpose of the Study is a statement contained within one or two paragraphs that identifies the research design, such as qualitative, quantitative, mixed methods, ethnographic, or another design. The research variables, if a quantitative study, are identified, for instance, independent, dependent, comparisons, relationships, or other variables. The population that will be used is identified, whether it will be randomly or purposively chosen, and the location of the study is summarized. Most of these factors will be discussed in detail in Chapter 3.
 The purpose of this study is to evaluate Rust's feasibility to guarantee memory safety when it's used for \gls{OS} development.
-
-* TODO: Qualitative or Quantitative?
+The results will be of qualitative nature by implementing and analyzing popular memory management techniques in Rust, discerning the level of memory safety improvements - or guarantees - in comparison to implementations in C.
 
 % Significance of the Study
 % The significance is a statement of why it is important to determine the answer to the gap in the knowledge, and is related to improving the human condition. The contribution to the body of knowledge is described, and summarizes who will be able to use the knowledge to make better decisions, improve policy, advance science, or other uses of the new information. The “new” data is the information used to fill the gap in the knowledge.
-The de-facto standard language for \gls{OS} development appears to be the C (TODO: reference).
 A very popular \gls{OS} that has been developed with C (and some assembly) is \gls{Linux}.
-Recent years have shown how prone it is to vulnerabilities which are the result of programming errors leading to insecure memory handling.
-This is covered by exemplary details within this study. (TODO reference)
+Recent years have shown how prone it is to vulnerabilities that result from the unsafe language design and programming errors.
+With the growing number of vulnerabilities, various solutions have been proposed to increase the safety of C, either with static code analysis or via checks imposed at runtime. (TODO: reference).
 
-* TODO: is it even theoretically possible to write safe C code?
+The former is complex to perform on a language that has not been designed to be safety-analysed. TODO? reference?
+Despite its complexity, attempts exist to define a subset of the C language that can be safety checked, namely Safe-C.
 
-\section{Common Memory-Related Errors}
+The performance overhead of the latter is immense which makes it an unviable option in the domain of \gls{OS} development, where there exists code paths which must be very fast to ensure the operation of high speed I/O devices\cite{Balasubramanian2017}.
 
-\subsection{Uninitialized Pointers}
-
-\begin{lstlisting}[language=C,
-                   directivestyle={\color{black}}
-                   emph={int,char,double,float,unsigned},
-                   emphstyle={\color{blue}}
-                  ]
-char *src = "hello" ; // character string constant 
-char *dst;            // unallocated
-strcpy(dst, src);     // segfault and die
-\end{lstlisting}
+Details about the challenge of writing code that does memory management safely, and related vulnerabilities are given in \autoref{chap:mmt}.
 
 \section{Static Code Analysis}
 * TODO: Difference between static- and runtime checks
@@ -68,8 +57,9 @@ strcpy(dst, src);     // segfault and die
 % Summarize the content of Chapter 1 and preview of content of Chapter 2.
 
 \chapter{Memory Management Techniques}
+\label{chap:mmt}
 
-* http://wiki.osdev.org/Memory_Management_Unit
+% * TODO: parse http://wiki.osdev.org/Memory_Management_Unit
 
 \section{Multi-Level Paging}
 \subsection{Top-Levle Pagetable Self-Reference}
@@ -77,6 +67,48 @@ strcpy(dst, src);     // segfault and die
 * 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
 
+\section{Common Memory-Related Errors}
+
+This work focuses on the following weaknesses defined in the \gls{CWE}
+
+\begin{itemize}
+    \item{Improper Restriction of Operations within the Bounds of a Memory Buffer}
+    https://cwe.mitre.org/data/definitions/119.html
+    
+    % TODO: find more
+\end{itemize}
+
+\subsection{Uninitialized Pointers}
+
+\begin{lstlisting}[language=C,
+                   directivestyle={\color{black}}
+                   emph={int,char,double,float,unsigned},
+                   emphstyle={\color{blue}}
+                  ]
+char *src = "hello" ; // character string constant 
+char *dst;            // unallocated
+strcpy(dst, src);     // segfault and die
+\end{lstlisting}
+
+\subsection{Null-Pointers}
+
+\begin{lstlisting}[language=C,
+                   directivestyle={\color{black}}
+                   emph={int,char,double,float,unsigned},
+                   emphstyle={\color{blue}}
+                  ]
+char *ptr; 
+int ret;
+if (ret = init_ptr(ptr)) {
+    return ret;
+}
+
+if (ptr == NULL) {
+    // gracefully handles the NP
+} else {
+    // may assume that the ptr address is not NULL
+}
+\end{lstlisting}
 
 \chapter{Introduction To Rust}
 

src/docs/thesis.tex

@@ -87,6 +87,8 @@
 \titlespacing*{\chapter}{0cm}{-1cm}{0.75cm}
 \titleformat{\chapter}[hang]{\normalfont\Large\bfseries}{\thechapter}{0.5cm}{}
 
+\usepackage{hyperref}
+
 \makeatletter
 
 %\renewcommand\paragraph{\startsection{paragraph}{4}{\z}%