more

sections/design.tex

@@ -6,12 +6,6 @@ In this section we discuss the details behind the design, formal guarantees, imp
 At the highest level, \korg sits on a user-defined channel in a program written in \promela, the modeling language of the \spin model checker. The user selects an attacker model of choice and correctness properties of choice. \korg then invokes the \spin, which exhaustively searches for attacks with respect to the chosen model and properties. 
 A high-level overview of the \korg pipeline is given in the Figure \ref{fig:korg_workflow}.
 
-%from a formal model written in \promela.
-
-%user-defined (or derived) \promela models.
-
-%TODO: diagram. Promela model, channel selection, gadget selection/definition get put into Korg. Korg spits out another promela model, which is put into Spin along with a property. Then, we get some attacks.
-
 \begin{figure}[h]
     \centering
     \includegraphics[width=0.5\textwidth]{assets/diagram3.png}
@@ -24,7 +18,6 @@ A high-level overview of the \korg pipeline is given in the Figure \ref{fig:korg
 
 \newcommand{\comp}{\mid\mid}
 \newcommand{\ioint}{\mathcal{C}}
-\newcommand{\ba}{B\"uchi Automata}
 
 Fundamentally, the theoretical framework that \korg implements proposed by Hippel et al. reasons about \textit{communicating processes}; similarly, \korg is best understood as a synthesizer for attackers that sit \textit{between} communicating processes. 
 
@@ -82,27 +75,65 @@ Since \korg uses \spin as its underlying model checker, we can effectively concl
 
 We implemented \korg on top of the \spin, a popular and robust model checker for reasoning about distributed and concurrent systems. Intuitively, models written in \promela, the modeling language of \spin, are communicating state machines whose messages are passed over defined \textit{channels}. Channels in \promela can either be unbuffered \textit{synchronous} channels, or buffered \textit{asynchronous} channels. \korg generates attacks \textit{with respect} to these defined channels.
 
-\begin{figure}[h]
 \begin{lstlisting}[caption={Example \promela model of peers communicating over a channel}, label={lst:spin-model}]
 // channel of buffer size 0
 chan msg_channel = [0] of { int } 
 
 active proctype Peer1() {
-    msg_channel ! 1
+    msg_channel ! 1;
 }
 
 active proctype Peer2() {
-    int received_msg
-    msg_channel ? received_msg
+    int received_msg;
+    msg_channel ? received_msg;
 }
 \end{lstlisting}
-\end{figure}
 
 Following the gadgetry framework as described in Hippel et al., \korg is designed to parse user-chosen channels and generate gadgets for sending, receiving, and manipulating messages on them. \korg has built-in gadgets that are designed to emulate various real-world attacker models, as further described in Section \ref{sec:usage_attacker_models}. Additionally, users can explicitly define which messages a generated gadget can send and receive. Once one or multiple gadgets are generated, \korg invokes \spin to check if a given property of interest remains satisfied in the presence of the attacker gadgets.
   
 \subsection{Usage}%
 \label{sub:Usage}
 
-To use \korg, the user inputs a \promela model, a correctness property specified in LTL, a channel from the given \promela model, and an attacker model of choice. \korg will then generate an attacker model gadget corresponding to the selected attacker model with respect to the chosen channel. The attacker model gadget is then appended onto the given \promela model and evaluated against the LTL property with \spin. \korg will then either produce an attack trace demonstrating the precise actions the attacker took to violate the LTL property, or demonstrate the absence of an attack via an exhaustive state-space search.
+To use \korg, the user first authors a \promela model and a correctness property in LTL. Take the following producer-consumer model, as shown in Listing \ref{lst:prod-consume}.
 
-Precise details of how to use the \korg implementation are provided in the anonymous repository: (link)
+\begin{lstlisting}[caption={Example \promela model with four producers and one consumer.}, label={lst:prod-consume}]
+chan msgs = [4] of { bit };
+int count = 0;
+
+active [1] proctype Producer() { 
+  do :: atomic { count++; msgs ! 1; } od
+}
+
+active [4] proctype Consumer() {  
+  do :: atomic { msgs ? 1 -> count--; } od
+}
+
+ltl always_positive { always (count >= 0) }
+\end{lstlisting}
+
+Next, the user selects a \textit{channel} to generate an attacker on, and an attacker model of choice (see Section \ref{sec:usage_attacker_models} for more details). For example, we select \texttt{msgs} as our channel of choice, \texttt{replay} as our attacker model of choice, and assume the producer-consumer model is in the file \texttt{pc.pml}. Then, we run \korg via command line.   
+
+\begin{lstlisting}[label={lst:korg-shell}]
+$ ./korg --model=pc.pml --attacker=replay --channel=msgs --eval
+\end{lstlisting}
+\korg will then modify the \texttt{pc.pml} file to include the \texttt{replay} attacker gadget, and model-check it with \spin. Then, \korg will find and output the simple attack trace where a producer message is replayed, causing a consumer to consume an extra time. The (simplified) attack trace is shown below.
+\begin{lstlisting}[label={trace}]
+(Producer) ko.pml:5 Send 1	-> queue 1 (msgs)
+(Atk) ko.pml:22 [Recv] 1 <- queue 1 (msgs)
+(Atk) ko.pml:23 Send 1 -> queue 2 (a_mem)
+(Atk) ko.pml:47 Recv 1 <- queue 2 (a_mem)
+(Atk) ko.pml:47 Send 1 -> queue 1 (msgs)
+(Consumer) ko.pml:9 Recv 1	<- queue 1 (msgs)
+(Consumer) ko.pml:9 Recv 1	<- queue 1 (msgs)
+
+spin: _spin_nvr.tmp:3, assertion violated
+spin: text of failed assertion: assert(!(!((count>=0))))
+Never claim moves to line 3	[assert(!(!((count>=0))))]
+\end{lstlisting}
+
+Additional examples and usage information are provided in the anonymous repository link: (link)
+
+
+%the user inputs a \promela model, a correctness property specified in LTL, a channel from the given \promela model, and an attacker model of choice. \korg will then generate an attacker model gadget corresponding to the selected attacker model with respect to the chosen channel. The attacker model gadget is then appended onto the given \promela model and evaluated against the LTL property with \spin. \korg will then either produce an attack trace demonstrating the precise actions the attacker took to violate the LTL property, or demonstrate the absence of an attack via an exhaustive state-space search.
+
+% Precise details of how to use the \korg implementation are provided in the anonymous repository: (link)