Updated trial run of the wikibook project

Makefile

@@ -1,5 +1,5 @@
 # Find all tex files one directory down
-TEX=$(shell find . -maxdepth 2 -mindepth 2 -path "./.git*" -prune -o -type f -iname "*.tex" -print)
+TEX=$(shell find . -path "./.git*" -prune -o -type f -iname "*.tex" -print)
 MAIN_TEX=main.tex
 PDF_TEX=$(patsubst %.tex,%.pdf,$(MAIN_TEX))
 BASE=$(patsubst %.tex,%,$(MAIN_TEX))
@@ -12,7 +12,7 @@ all: $(PDF_TEX)
 
 
 $(PDF_TEX): $(TEX) $(MAIN_TEX) $(BIBS) Makefile
-	-latexmk latexmk -interaction=nonstopmode -quiet -f -pdf $(MAIN_TEX) 2>&1 >/dev/null
+	-latexmk -quiet -interaction=nonstopmode -f -pdf $(MAIN_TEX) 2>&1 >/dev/null
 	-@latexmk -c
 	-@rm *aux *bbl *glg *glo *gls *ist *latexmk *fls
 

appendix/appendix.tex

@@ -242,12 +242,51 @@ \section{GDB}\label{gdb}
 
 \section{Life in the terminal}
 
-\todo
+\todo{Life in the Terminal}
 
-\texttt{0x43\ 0x61\ 0x74\ 0xe0\ 0xf9\ 0xbf\ 0x5f\ 0xff\ 0x7f\ 0x00}
+\section{Stack Smashing}\label{stack-smashing}
+
+Each thread uses a stack memory. The stack `grows downwards' - if a function calls another function, then the stack is extended to smaller memory addresses. Stack memory includes non-static automatic (temporary) variables, parameter values and the return address. If a buffer is too small some data (e.g.~input values from the user), then there is a real possibility that other stack variables and even the return address will be overwritten. The precise layout of the stack's contents and order of the automatic variables is architecture and compiler dependent. However with a little investigative work we can learn how to deliberately smash the stack for a particular architecture.
+
+The example below demonstrates how the return address is stored on the stack. For a particular 32 bit architecture \href{http://cs-education.github.io/sys/}{Live Linux Machine}, we determine that the return address is stored at an address two pointers (8 bytes) above the address of the automatic variable. The code deliberately changes the stack value so that when the input function returns, rather than continuing on inside the main method, it jumps to the exploit function instead.
+
+\begin{code}[language=C]
+// Overwrites the return address on the following machine:
+// http://cs-education.github.io/sys/
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+
+void breakout() {
+    puts("Welcome. Have a shell...");
+    system("/bin/sh");
+}
+void input() {
+  void *p;
+  printf("Address of stack variable: %p\n", &p);
+  printf("Something that looks like a return address on stack: %p\n", *((&p)+2));
+  // Let's change it to point to the start of our sneaky function.
+  *((&p)+2) = breakout;
+}
+int main() {
+    printf("main() code starts at %p\n",main);
+    
+    input();
+    while (1) {
+        puts("Hello");
+        sleep(1);
+    }
+
+    return 0;
+}
+\end{code}
+
+There are \href{https://en.wikipedia.org/wiki/Stack_buffer_overflow}{a lot} of ways that computers tend to get around this.
 
 \section{System Programming Jokes}
 
+\texttt{0x43\ 0x61\ 0x74\ 0xe0\ 0xf9\ 0xbf\ 0x5f\ 0xff\ 0x7f\ 0x00}
+
 Warning: Authors are not responsible for any neuro-apoptosis caused by these ``jokes.'' - Groaners are allowed.
 
 \subsection{Light bulb jokes}

deadlock/deadlock.bib

@@ -8,6 +8,7 @@ @book{silberschatz2006operating
   publisher={Wiley India Pvt. Limited}
 }
 
+
 @article{coffman1971system,
   title={System deadlocks},
   author={Coffman, Edward G and Elphick, Melanie and Shoshani, Arie},
@@ -19,6 +20,7 @@ @article{coffman1971system
   publisher={ACM}
 }
 
+
 @article{rice,
  ISSN = {00029947},
  URL = {http://www.jstor.org/stable/1990888},

deadlock/deadlock.tex

@@ -6,7 +6,7 @@ \chapter{Deadlock}
 \\But if you try sometime you find
 \\You get what you need}{The philosphers Jagger \& Richards}
 
-Deadlock is defined as when the system cannot make and forward progress. In a lot of systems, Deadlock is just avoided by ignore the entire concept \cite[P.237]{silberschatz2006operating}. Have you heard about turn it on and off again? That is partly because of this. For products where the stakes are low when you deadlock (User Operating Systems, Phones), it may be more efficient not not keep track of all of the allocations in order to keep deadlock from happening. But in the cases where "failure is not an option" - Apollo 13, you need a system that tracks deadlock or better yet prevents it entirely. Take the Apollo 13 module. It may have not failed because of deadlock, but probably wouldn't be good to restart the system on liftoff.
+\gls{Deadlock} is defined as when the system cannot make and forward progress. In a lot of systems, Deadlock is just avoided by ignore the entire concept \cite[P.237]{silberschatz2006operating}. Have you heard about turn it on and off again? That is partly because of this. For products where the stakes are low when you deadlock (User Operating Systems, Phones), it may be more efficient not not keep track of all of the allocations in order to keep deadlock from happening. But in the cases where "failure is not an option" - Apollo 13, you need a system that tracks deadlock or better yet prevents it entirely. Take the Apollo 13 module. It may have not failed because of deadlock, but probably wouldn't be good to restart the system on liftoff.
 
 Mission critical operating systems need this guarentee formally because playing the odds with people's lives isn't a good idea. Okay so how do we do this? We model the problem. Even though it is a common statistical phrase that all models are wrong, the more accurate the model is to the system that we are working with the better chance that it'll work better.
 
@@ -19,7 +19,7 @@ \section{Resource Allocation Graphs}
   \caption{Resource allocation graph}
 \end{wrapfigure}
 
-One such way is modeling the system with a resource allocationg graph. A resource allocation graph tracks which resource is held by which process and which process is waiting for a resource of a particular type. It is very powerful and simple tool to illustrate how interacting processes can deadlock. If a process is \emph{using} a resource, an arrow is drawn from the resource node to the process node. If a process is \emph{requesting} a resource, an arrow is drawn from the process node to the resource node.If there is a cycle in the Resource Allocation Graph and each resource in the cycle provides only one instance, then the processes will deadlock. For example, if process 1 holds resource A, process 2 holds resource B and process 1 is waiting for B and process 2 is waiting for A, then process 1 and 2 process will be deadlocked.
+One such way is modeling the system with a resource allocation graph (\gls{RAG}). A resource allocation graph tracks which resource is held by which process and which process is waiting for a resource of a particular type. It is very powerful and simple tool to illustrate how interacting processes can deadlock. If a process is \emph{using} a resource, an arrow is drawn from the resource node to the process node. If a process is \emph{requesting} a resource, an arrow is drawn from the process node to the resource node.If there is a cycle in the Resource Allocation Graph and each resource in the cycle provides only one instance, then the processes will deadlock. For example, if process 1 holds resource A, process 2 holds resource B and process 1 is waiting for B and process 2 is waiting for A, then process 1 and 2 process will be deadlocked.
 
 \begin{wrapfigure}[12]{r}{.35\textwidth}
   \begin{center}
@@ -32,18 +32,18 @@ \section{Resource Allocation Graphs}
 
 \section{Coffman conditions}
 
-There are four \emph{necessary} and \emph{sufficient} conditions for deadlock -- meaning if these conditions hold then there is a non-zero probability that the system will deadlock at any given iteration. These are known as the Coffman conditions \cite{coffman1971system}.
+There are four \emph{necessary} and \emph{sufficient} conditions for deadlock -- meaning if these conditions hold then there is a non-zero probability that the system will deadlock at any given iteration. These are known as the \gls{Coffman Conditions} \cite{coffman1971system}.
 
 \begin{itemize}
 \tightlist
 \item
-  Mutual Exclusion: no two processes can obtain a resource at the same time.
+  \gls{Mutual Exclusion}: no two processes can obtain a resource at the same time.
 \item
-  Circular Wait: there exists a cycle in the Resource Allocation Graph, or there exists a set of processes \{P1,P2,\ldots{}\} such that P1 is waiting for resources held by P2, which is waiting for P3,\ldots{}, which is waiting for P1.
+  \gls{Circular Wait}: there exists a cycle in the Resource Allocation Graph, or there exists a set of processes \{P1,P2,\ldots{}\} such that P1 is waiting for resources held by P2, which is waiting for P3,\ldots{}, which is waiting for P1.
 \item
-  Hold and Wait: a process once obtaining a resource does not let go.
+  \gls{Hold and Wait}: a process once obtaining a resource does not let go.
 \item
-  No pre-emption: nothing can force the process to give up a resource.
+  \gls{No pre-emption}: nothing can force the process to give up a resource.
 \end{itemize}
 
 \begin{proof} Deadlock can happen if and only if the four coffman conditions are satisified.
@@ -76,11 +76,11 @@ \section{Coffman conditions}
 
 If you break any of them, you cannot have deadlock! Consider the scenario where two students need to write both pen and paper and there is only one of each. Breaking mutual exclusion means that the students share the pen and paper. Breaking circular wait could be that the students agree to grab the pen then the paper. As a proof by contradiction, say that deadlock occurs under the rule and the conditions. Without loss of generality, that means a student would have to be waiting on a pen while holding the paper and the other waiting on a pen and holding the paper. We have contradicted ourselves because one student grabbed the paper without grabbing the pen, so deadlock must not be able to occur. Breaking hold and wait could be that the students try to get the pen and then the paper and if a student fails to grab the paper then they release the pen. This introduces a new problem called \textit{livelock} which will be discussed latter. Breaking preemption means that if the two students are in deadlock the teacher can come in and break up the deadlock by giving one of the students one the held on items or tell both students to put the items down.
 
-Livelock relates to deadlock but it is not exactly deadlock. Consider the breaking hold and wait solution as above. Though deadlock is avoided, if we pick up the same device (a pen or the paper) again and again in the exact same pattern, neither of us will get any writing done. More generally, livelock happens when the process looks like it is executing but no meaningful work is done. Livelock is generally harder to detect because the processes generally look like they are working to the outside operating system wheras in deadlock the operating system generally knows when two processes are waiting on a system wide resource. Another problem is that there are nessisary conditions for livelock (i.e. deadlock does not occur) but not sufficient conditions -- meaning there is no set of rules where livelock has to occur. You must formally prove in a system by what is known as an invariant. One has to enumerate each of the steps of a system and if each of the steps eventually (after some finite number of steps) leads to forward progress, the system is not livelocked. There are even better systems that prove bounded waits; a system can only be livelocked for at most $n$ cycles which may be important for something like stock exchanges.
+\gls{livelock} relates to deadlock but it is not exactly deadlock. Consider the breaking hold and wait solution as above. Though deadlock is avoided, if we pick up the same device (a pen or the paper) again and again in the exact same pattern, neither of us will get any writing done. More generally, livelock happens when the process looks like it is executing but no meaningful work is done. Livelock is generally harder to detect because the processes generally look like they are working to the outside operating system wheras in deadlock the operating system generally knows when two processes are waiting on a system wide resource. Another problem is that there are nessisary conditions for livelock (i.e. deadlock does not occur) but not sufficient conditions -- meaning there is no set of rules where livelock has to occur. You must formally prove in a system by what is known as an invariant. One has to enumerate each of the steps of a system and if each of the steps eventually (after some finite number of steps) leads to forward progress, the system is not livelocked. There are even better systems that prove bounded waits; a system can only be livelocked for at most $n$ cycles which may be important for something like stock exchanges.
 
 \section{Approaches to solving deadlock}
 
-Ignoring deadlock is the most obvious approach that started the chapter out detailing. Quite humorously, the name for this approach is called the ostrich algorithm. Though there is no apparent source, the idea for the algorithm comes from the concept of an ostrich sticking its head in the sand. When the operating system detects deadlock, it does nothing out of the ordinary and hopes that the deadlock goes away. Now this is a slight misnomer because the operating system doesn't do anything \textit{abnormal} -- it is not like an operating system deadlocks every few minutes because it runs ~100 processes all requesting shared libraries. An operating system still preempts processes when stopping them for context switches. The operating system has the ability to interrupt any system call, potentially breaking a deadlock scenario. The OS also makes some files read-only thus making the resource shareable. What the algorithm refers to is that if there is an adversary that specifically crafts a program -- or equivalently a user who poorly writes a program -- that deadlock could not be caught by the operating system. For everyday life, this tends to be fine. When it is not we can turn to the following method.
+Ignoring deadlock is the most obvious approach that started the chapter out detailing. Quite humorously, the name for this approach is called the \gls{ostrich algorithm}. Though there is no apparent source, the idea for the algorithm comes from the concept of an ostrich sticking its head in the sand. When the operating system detects deadlock, it does nothing out of the ordinary and hopes that the deadlock goes away. Now this is a slight misnomer because the operating system doesn't do anything \textit{abnormal} -- it is not like an operating system deadlocks every few minutes because it runs ~100 processes all requesting shared libraries. An operating system still preempts processes when stopping them for context switches. The operating system has the ability to interrupt any system call, potentially breaking a deadlock scenario. The OS also makes some files read-only thus making the resource shareable. What the algorithm refers to is that if there is an adversary that specifically crafts a program -- or equivalently a user who poorly writes a program -- that deadlock could not be caught by the operating system. For everyday life, this tends to be fine. When it is not we can turn to the following method.
 
 Deadlock detection allows the system to enter a deadlocked state. After entering, the system uses the information that it has to break deadlock. As an example, consider multiple processes accessing files. The operating system is able to keep track of all of the files/resources through file descriptors at some level either abstracted through an API or directly. If the operating system detects a directed cycle in the operating system file descriptor table it may break one process' hold through scheduling for example and let the system proceed. Why this is a popular choice in this realm is that there is no way of knowing which resources a program will select without running the program. This is an extension of Rice's theorem \cite{rice} that says that we cannot know any semantic feature without running the program (semantic meaning like what files it tries to open). So theoretically, it is sound. The problem then gets introduced that we could reach a livelock scenario if we preempt a set of resources again and again. The way around this is mostly probabilistic. The operating system chooses a random resource to break hold and wait. Now even though a user can craft a program where breaking hold and wait on each resource will result in a livelock, this doesn't happen as often on machines that run programs in practice or the livelock that does happen happens for a couple of cycles. These kind of systems are good for products that need to maintain a non-deadlocked state but can tolerate a small chance of livelock for a short period of time. The following proof \textbf{is not required for our 241 related puproses but is included for concreteness}.
 
@@ -200,7 +200,12 @@ \subsection{Leaving the Table (Stallings' Solution)}
 
 In the case that the philosophers aren't evil, this solution requires a lot of time-consuming context switching. There is also no reliable way to know the number of resources before hand. In the dining philosophers case, this is solved because everything is known but trying to specify and operating system where you don't know which file is going to get opened by what process leads you with a faulty solution. And again since semaphores are system constructs, they obey system timing clocks which means that the same processes tend to get added back into the queue again. Now if a philosopher becomes evil, then the problem becomes that there is no preemption. A philosopher can eat for as long as they want and the system will continue to function but that means the fairness of this solution can be low in the worst case. This works best with timeouts (or forced context switches) in order to ensure bounded wait times.
 
-\todo{Prove stallings's doesn't deadlock}
+\begin{proof} Stallings' Solution Doesn't Deadlock.
+
+Let's number the philosophers $\{p_0, p_1, .., p_{n-1}\}$ and the resources $\{r_0, r_1, .., r_{n-1}\}$. A philosopher $p_i$ needs resource $r_{i-1 \mod n}$ and $r_{i + 1 \mod n}$. Without loss of generality, let us take $p_i$ out of the picture. Each resource had exactly two philosophers that could use it. Now resources $r_{i-1 \mod n}$ and $r_{i + 1 \mod n}$ only have on philosopher waiting on it. Even if hold and wait, no preemption, and mutual exclusion or present, the resources can never enter a state where one philosopher requests them and they are held by another philosopher because only one philosopher can request them. Since there is no way to generate a cycle otherwise, circular wait cannot hold. Since circular wait cannot hold, deadlock cannot happen.
+
+\end{proof}
+
 
 \subsection{Partial Ordering (Dijkstra's Solution)}
 

glossary.tex

@@ -10,8 +10,50 @@
     description={TODO}
 }
 
+% Deadlock
+
 \newglossaryentry{livelock}
 {
-	name=livelock,
+	name=Livelock,
 	description={TODO}
+}
+
+\newglossaryentry{Deadlock}{
+	name=Deadlock,
+	description={When a system cannot progress}
+}
+
+\newglossaryentry{RAG}{
+	name=RAG,
+	description={A tool for helping identify deadlock if a cycle is apprent}
+}
+
+\newglossaryentry{Coffman Conditions}{
+	name=Coffman Conditions,
+	description={Four necissary and sufficient conditions for deadlock}
+}
+
+\newglossaryentry{Mutual Exclusion}{
+	name=a,
+	description={a}
+}
+
+\newglossaryentry{Circular Wait}{
+	name=a,
+	description={a}
+}
+
+\newglossaryentry{Hold and Wait}{
+	name=a,
+	description={a}
+}
+
+\newglossaryentry{No pre-emption}{
+	name=a,
+	description={a}
+}
+
+\newglossaryentry{ostrich algorithm}{
+	name=a,
+	description={a}
 }