thesis/context: introduce topic; add pointer example

src/docs/parts/context/context.tex

@@ -1,24 +1,46 @@
 % // vim: set ft=tex:
 \chapter{Introduction}
 This thesis studies the feasibility of using static code analysis, as found in the \gls{rustlang} \gls{compiler}, to ensure memory safety within an \gls{OS} kernel.
+Because an \gls{OS} is nothing but a \gls{app}, 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.
+The \gls{OS} is the only \gls{app} that has unrestricted access to these resources, and in order to protect them it needs to be secure.
 
 % 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.
 
-% Scope
-In the general sense an \gls{OS} is a \gls{app} that runs within one \gls{addrspace} and is able to run on the hardware platform without any abstraction.
-This study could be applied to all \glspl{app}, but the focus is on the implementation of \glspl{OS}.
-The main reason for this is that the due to its nature, the \gls{OS} is the only \gls{app} that has unrestricted access to the system's hardware, which makes it the most important \gls{app} to maintain secure.
+* TODO: Qualitative or Quantitative?
 
 % 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 current de-facto standard language for \gls{OS} development appears to be the C, a very popular \gls{OS} example is \gls{Linux}.
-Recent years have shown how prone it is to security vulnerabilities, which is covered by exemplary details within this study. (TODO reference)
+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)
 
+* TODO: is it even theoretically possible to write safe C code?
+
+\section{Common Memory-Related Errors}
+
+\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}
+
+\section{Static Code Analysis}
+* TODO: Difference between static- and runtime checks
+
+\section{Programming the OS in Rust: Guaranteed Memory Safety?}
 % Primary Research Questions
 % The primary research question is the basis for data collection and arises from the Purpose of the Study. There may be one, or there may be several. When the research is finished, the contribution to the knowledge will be the answer to these questions. Do not confuse the primary research questions with interview questions in a qualitative study, or survey questions in a quantitative study. The research questions in a qualitative study are followed by both a null and an alternate hypothesis.
 
+
 \section{Hypotheses}
 % Hypotheses
 % 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.
@@ -44,3 +66,23 @@ Recent years have shown how prone it is to security vulnerabilities, which is co
 
 \section{Summary}
 % Summarize the content of Chapter 1 and preview of content of Chapter 2.
+
+\chapter{Memory Management Techniques}
+
+* http://wiki.osdev.org/Memory_Management_Unit
+
+\section{Multi-Level Paging}
+\subsection{Top-Levle Pagetable Self-Reference}
+
+* 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
+
+
+\chapter{Introduction To Rust}
+
+\section{Zero-Cost Abstractions}
+\subsection{The Newtype Pattern}
+
+https://aturon.github.io/features/types/newtype.html
+
+

src/docs/parts/research/research.tex

@@ -1,4 +1,51 @@
 % // vim: set ft=tex:
 \chapter{Topic Refinement}
 
-\chapter{Criteria}
+\section{Static Checks}
+* TODO: Difference between static- and runtime checks
+
+\subsection{Define Additional Anlyse Rules}
+* Example: TLB needs to be reset on Task Change
+
+\subsection{Static Variable Declaration}
+
+
+
+\section{Virtual Memory Management In Hard- and Software}
+* Architecture choice: x86\_64
+* CPU supports
+
+* TODO: Is the static analysis of hardware specific assembly code possible and useful at all?
+    * LLVM knows about the target and can potentially give hints about hardware specific instructions
+* TODO: On which level can abstraction in Rust code start?
+
+\subsection{Interrupts}
+* https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf p. 2848
+
+
+\section{Testing}
+* How effective are tests?
+* Are they necessary in addition to static checks?
+
+
+\chapter{Using Rust Within Non-Rust Operating Systems}
+\section{Linux Kernel Modules}
+
+* TODO: describe Difficulties with Macros used Within Kernel
+
+\chapter{OS Designs Based On Rust}
+
+Thread Libraries:
+* https://github.com/edef1c/libfringe
+
+\section{Blog OS}
+\section{intermezzOS}
+\subsection{Memory Management}
+* Which language items help with managing memory?
+* How generic can the memory allocators be written?
+
+Guarantees to be statically checked:
+* Prevent access to unmapped physical memory
+* Prevent duplicates in page tables
+\section{Reddox}
+\section{Tock}