*: extend and refine structure

src/docs/glossary.tex

@@ -87,6 +87,13 @@
     plural=Linuces
 }
 
+\newglossaryentry{imezzos}{
+    name = intermezzOS,
+    description = {
+        TODO
+    },
+}
+
 \newglossaryentry{rootfs}{
     name = RootFS,
     description = {

src/docs/parts/context/context.tex

@@ -75,7 +75,7 @@ Details about the challenge of writing code that does memory management safely,
 * TODO: is it worth to explain ECC?
 * TODO: explain that the hardware might be unsafe but this is not in scope of the thesis
 
-\section{Summary}
+\section{Recap}
 % Summarize the content of Chapter 1 and preview of content of Chapter 2.
 \label{chap:mmt}
 The \autoref{chap:mmt} gives a detailed introduction to memory management in contemporary architectures and \glspl{OS}.
@@ -104,7 +104,7 @@ This chapter starts with the provides a thorough introduction to modern memory m
 
 \subsection{Multi-Level Paging}
 
-\subsection{Top-Level Page table Self-Reference}
+\subsection{Top-Level Page Table Self-Reference}
 
 \subsection{Caching Lookups}
 
@@ -113,12 +113,18 @@ This chapter starts with the provides a thorough introduction to modern memory m
 * 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{Stack And Heap Concept}
+
 \section{Memory Allocation}
 
-\chapter{Common Memory-Related Errors}
+\chapter{Memory-Related Software-Programming Weaknesses}
+\label{chap:context.mem-weaknesses}
+Software vulnerabilities can be categorized by their underlying weaknesses.
+This chapter explains the weaknesses of interest for this project and gives concrete examples for their manifestation.
 
+\section{Weakness Categories}
 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
@@ -126,6 +132,8 @@ This work focuses on the following weaknesses defined in the \gls{CWE}
     % TODO: find more
 \end{itemize}
 
+\section{Manifestation Examples}
+
 \subsection{Uninitialized Pointers}
 
 \begin{lstlisting}[language=C,
@@ -158,26 +166,44 @@ if (ptr == NULL) {
 }
 \end{lstlisting}
 
+\subsection{TODO: more}
+
+\chapter{Memory-Safety Analysis Techniques}
+As per the previous \autoref{chap:context.mem-weaknesses} there is general awareness of the problems, and there has been ongoing effort to develop and improve techniques that assist the programmer to detect and avoid such mistakes first- or secondhand. 
+
+\section{Static vs. Dynamic Analysis}
+* TODO: explain first-/secondhand -> static/dynamic -> compile-time/runtime -> offline/online
+* TODO: Explain static and dynamic checks
+
+
+\section{Requirements}
+* TODO: which knowledge is required to analyze access to memory?
+
+\section{Limitations}
+* TODO: deadlock example
+
 \chapter{Introduction To Rust}
 
 \section{Compiler Architecture}
-- TODO: Tokens? AST? LLVM?
+- TODO: Tokens? AST? LLVM? (http://embed.rs/articles/2016/arm-inline-assembly-rust/)
 - TODO: BSYS SS17 GITHUB IO Rust Memory Layout - 4
 
-
 \section{Static Analysis Features}
 - TODO: How does static typing help with preventing programming errors
 - TODO: How does the Rust's static analysis work, theoretically and practically
-- TODO: how could memory be dynamically allocated and still safety checked?
+- TODO: How can memory be dynamically allocated and still safety checked?
+
+\subsection{Ownership And Borrows}
+- TODO: Who owns global 'static variables?
+
+- https://nercury.github.io/rust/guide/2015/01/19/ownership.html
 
 \subsection{Lifetimes}
 - TODO: Where are global 'static variables allocated?
 
-\subsection{Ownership}
-- TODO: Who owns global 'static variables?
-
 \subsection{Type Safety}
 - TODO: how does casting work? 
+- TODO: demonstrate raw pointers
 - TODO: what's the equivalent of void*?
 
 \subsection{The Newtype Pattern}
@@ -188,3 +214,11 @@ if (ptr == NULL) {
 https://aturon.github.io/features/types/newtype.html
 
 
+\subsection{Im/mutability}
+- TODO: describe Rc, Arc, and {Ref,}Cell
+
+\section Language Extension
+\subsection{Syntax Extension}
+\subsubsection{Macros}
+\subsubsection{Annotations}
+\subsection{Compiler Plugins}

src/docs/parts/research/research.tex

@@ -1,50 +0,0 @@
-% // vim: set ft=tex:
-\chapter{Topic Refinement}
-
-\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}

src/docs/parts/research_and_development/research_and_development.tex

@@ -0,0 +1,64 @@
+% // vim: set ft=tex:
+\chapter{Topic Refinement}
+- TODO: is this chapter required?
+
+\chapter{Derived Research Questions}
+
+\subsection{Definition Of Additional Analysis Rules To Extend Safety Checks}
+* TODO: How can Business Logical
+Examples: 
+* TLB needs to be reset on Task Change
+* Registers need to be 
+
+\subsubsection{Software Fault Isolation}
+* TODO: content from \cite{Balasubramanian2017}
+
+\subsection{More Detailed Research Questions}
+* Which language items help with managing memory?
+* How generic can the memory allocators be written?
+
+Guarantees to be statically checked:
+* Control access to duplicates in page tables
+* Tasks can't access unallocated (physical) memory
+* Tasks can't access other tasks memory
+
+\subsection{Interrupts}
+* https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf p. 2848
+
+\section{Software Tests}
+* TODO: describe that tests are mostly semantics as opposed to static checks being mostly syntactical and technical
+* TODO: They necessary in addition to static checks to cover the well-known use-cases and edge-cases. TODO: example?
+
+\chapter{Attempt Extend \gls{Linux} with \gls{Rust}}
+* TODO: describe Difficulties with the GPL Macros used Within Kernel Modules
+
+\chapter{Existing \gls{OS}-Development Projects Based On Rust}
+
+
+\section{Libraries}
+
+\subsection{Libfringe}
+* https://github.com/edef1c/libfringe
+
+\section{Systems}
+\subsection{intermezzOS}
+\subsection{Blog OS}
+\subsection{Redox}
+\subsection{Tock}
+
+\chapter{Introduce Preemptive \gls{OS}-Level Multitasking to \gls{imezzos}}
+
+\chapter{Result Generalization}
+
+\section{Low-Level Safe Abstractions in Rust}
+* 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
+
+\section{Tracking \textit{'static}ally allocated Resources}
+
+\section{The Necessary Evils of \textit{unsafe}}
+
+\chapter{Result Evaluation}
+* TODO: repeat that rust *can* be used to increase safety in the OS, but it doesn't guarantee it per-se
+
+\chapter{Summary}

src/docs/thesis.bib

@@ -3,24 +3,39 @@ 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{Levy2015a,
+@book{AMD64Vol1,
-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 = {AMD},
-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},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/AMD64 Architecture Programmer's Manual Volume 1$\backslash$: Application Programming.pdf:pdf},
-doi = {10.1145/2818302.2818306},
+keywords = {AMD64,SIMD,extended media instructions,legacy m},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/tock-plos2015.pdf:pdf},
+number = {26568},
-isbn = {9781450339421},
+title = {{AMD64 Architecture Programmer's Manual Volume 1: Application Programming}},
-journal = {PLOS: Workshop on Programming Languages and Operating Systems},
+volume = {4},
-keywords = {embedded operating systems,linear types,ownership,rust},
+year = {2012}
-pages = {21--26},
-title = {{Ownership is Theft: Experiences Building an Embedded OS in Rust}},
-url = {http://dl.acm.org/citation.cfm?id=2818302.2818306},
-year = {2015}
 }
-@article{Affairs2015,
+@article{Dhurjati2003,
-author = {Affairs, Post Doctoral},
+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.},
-file = {:home/steveej/src/steveej/msc-thesis/docs/You can't spell trust without Rust.pdf:pdf},
+author = {Dhurjati, D and Kowshik, S and Adve, V and Lattner, C},
-title = {{YOU CAN ' T SPELL TRUST WITHOUT RUST alexis beingessner Master ' s in Computer Science Carleton University}},
+doi = {10.1145/780742.780743},
-year = {2015}
+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}
+}
+@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{Merity2016,
 abstract = {Recent neural network sequence models with softmax classifiers have achieved their best language modeling performance only with very large hidden states and large vocabularies. Even then they struggle to predict rare or unseen words even if the context makes the prediction unambiguous. We introduce the pointer sentinel mixture architecture for neural sequence models which has the ability to either reproduce a word from the recent context or produce a word from a standard softmax classifier. Our pointer sentinel-LSTM model achieves state of the art language modeling performance on the Penn Treebank (70.9 perplexity) while using far fewer parameters than a standard softmax LSTM. In order to evaluate how well language models can exploit longer contexts and deal with more realistic vocabularies and larger corpora we also introduce the freely available WikiText corpus.},
@@ -33,51 +48,18 @@ title = {{Pointer Sentinel Mixture Models}},
 url = {http://arxiv.org/abs/1609.07843},
 year = {2016}
 }
-@misc{Endler,
+@article{Chisnall2015,
-author = {Endler, Matthias},
+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.},
-title = {{A curated list of static analysis tools, linters and code quality checkers for various programming languages}},
+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},
-url = {https://github.com/mre/awesome-static-analysis}
+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},
-@inproceedings{Kuznetsov2014,
+isbn = {9781450328357},
-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},
+issn = {01635964},
-author = {Kuznetsov, Volodymyr and Szekeres, L{\'{a}}szl{\'{o}} and Payer, Mathias},
+journal = {Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems},
-booktitle = {Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation},
+pages = {117--130},
-isbn = {9781931971164},
+title = {{Beyond the PDP-11 : Architectural support for a memory-safe C abstract machine}},
-pages = {147--163},
+url = {http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201503-asplos2015-cheri-cmachine.pdf},
-title = {{Code-pointer integrity}},
+year = {2015}
-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{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{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.},
-archivePrefix = {arXiv},
-arxivId = {9780201398298},
-author = {Lattner, Chris and Adve, Vikram},
-doi = {10.1007/11532378_2},
-eprint = {9780201398298},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/The LLVM Compiler Framework and Infrastructure Tutorial.pdf:pdf},
-isbn = {978-3-540-28009-5},
-issn = {03029743},
-journal = {Languages and Compilers for High Performance Computing},
-number = {Part 1},
-pages = {15--16},
-pmid = {4520227},
-title = {{The LLVM Compiler Framework and Infrastructure Tutorial}},
-url = {http://dx.doi.org/10.1007/11532378{\_}2},
-year = {2005}
 }
 @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.},
@@ -102,25 +84,54 @@ pages = {48--62},
 title = {{SoK: Eternal war in memory}},
 year = {2013}
 }
-@article{Chisnall2015,
+@article{Corporation2011,
-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.},
+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 = {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},
+author = {Corporation, Intel},
-doi = {10.1145/2694344.2694367},
+doi = {10.1109/MAHC.2010.22},
-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},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf:pdf},
-isbn = {9781450328357},
+isbn = {253665-057US},
-issn = {01635964},
+issn = {15222594},
-journal = {Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems},
+journal = {System},
-pages = {117--130},
+keywords = {253665,IA-32 architecture,Intel 64},
-title = {{Beyond the PDP-11 : Architectural support for a memory-safe C abstract machine}},
+number = {253665},
-url = {http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201503-asplos2015-cheri-cmachine.pdf},
+title = {{Intel {\textregistered} 64 and IA-32 Architectures Software Developer ' s Manual Volume 3}},
-year = {2015}
+volume = {3},
+year = {2011}
 }
-@article{Balasubramanian2017,
+@article{Caballero2012,
-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.},
+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 = {Balasubramanian, Abhiram and Baranowski, Marek S and Burtsev, Anton and Irvine, Uc and Rakamari, Zvonimir and Ryzhyk, Leonid and Research, Vmware},
+author = {Caballero, Juan and Grieco, Gustavo and Marron, Mark and Nappa, Antonio},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/DRAFT$\backslash$: System Programming in Rust$\backslash$: Beyond Safety.pdf:pdf},
+doi = {10.1145/2338965.2336769},
-title = {{DRAFT: System Programming in Rust: Beyond Safety}},
+isbn = {9781450314541},
-year = {2017}
+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{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},
+doi = {10.1145/2818302.2818306},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/tock-plos2015.pdf:pdf},
+isbn = {9781450339421},
+journal = {PLOS: Workshop on Programming Languages and Operating Systems},
+keywords = {embedded operating systems,linear types,ownership,rust},
+pages = {21--26},
+title = {{Ownership is Theft: Experiences Building an Embedded OS in Rust}},
+url = {http://dl.acm.org/citation.cfm?id=2818302.2818306},
+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.},
@@ -141,20 +152,31 @@ pages = {1--24},
 title = {{Embedded System Security with Rust}},
 year = {2016}
 }
-@article{Dhurjati2003,
+@article{Corporation2011a,
-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.},
+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 = {Dhurjati, D and Kowshik, S and Adve, V and Lattner, C},
+author = {Corporation, Intel},
-doi = {10.1145/780742.780743},
+doi = {10.1109/MAHC.2010.22},
-file = {:home/steveej/src/github/steveej/msc-thesis/docs/Memory Safety Without Runtime Checks or Garbage.pdf:pdf},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/64-ia-32-architectures-software-developer-vol-1-manual.pdf:pdf},
-isbn = {0362-1340},
+isbn = {253665-057US},
-issn = {03621340},
+issn = {15222594},
-journal = {Acm Sigplan Notices},
+journal = {System},
-keywords = {automatic pool allocation,compilers,embedded systems,languages,programming languages,region management,security,static analysis},
+keywords = {253665,64,ia 32 architecture},
-number = {7},
+number = {253665},
-pages = {69--80},
+title = {{Intel {\textregistered} 64 and IA-32 Architectures Software Developer ' s Manual Volume 1}},
-title = {{Memory safety without runtime checks or garbage collection}},
+volume = {1},
-volume = {38},
+year = {2011}
-year = {2003}
+}
+@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{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}
 }
 @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.},
@@ -170,3 +192,33 @@ title = {{From Collision To Exploitation: Unleashing Use-After-Free Vulnerabilit
 url = {http://dl.acm.org/citation.cfm?doid=2810103.2813637},
 year = {2015}
 }
+@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{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{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.},
+archivePrefix = {arXiv},
+arxivId = {9780201398298},
+author = {Lattner, Chris and Adve, Vikram},
+doi = {10.1007/11532378_2},
+eprint = {9780201398298},
+file = {:home/steveej/src/github/steveej/msc-thesis/docs/The LLVM Compiler Framework and Infrastructure Tutorial.pdf:pdf},
+isbn = {978-3-540-28009-5},
+issn = {03029743},
+journal = {Languages and Compilers for High Performance Computing},
+number = {Part 1},
+pages = {15--16},
+pmid = {4520227},
+title = {{The LLVM Compiler Framework and Infrastructure Tutorial}},
+url = {http://dx.doi.org/10.1007/11532378{\_}2},
+year = {2005}
+}

src/docs/thesis.tex

@@ -136,9 +136,9 @@
 
     \include{parts/context/context}
 
-    \part{Research}
+    \part{Research And Development}
-    \label{part:research}
+    \label{part:rnd}
-    \include{parts/research/research}
+    \include{parts/research_and_development/research_and_development}
 
     \part{Conclusion}