77 lines
3.8 KiB
TeX
77 lines
3.8 KiB
TeX
\TUchapter{Utilization OF MESSAGE PASSING INTERFACE}
|
|
|
|
\TUsection{Introduction to MPI Utilization for Attack Graph Generation}
|
|
|
|
\TUsection{Necessary Components}
|
|
\TUsubsection{Serialization}
|
|
In order to distribute workloads across nodes in a distributed system, various
|
|
types of data will need to be sent and received. Support and mechanisms vary based
|
|
on the MPI implementation, but most fundamental data types such as integers, doubles,
|
|
characters, and Booleans are incorporated into the MPI implementation. While this does
|
|
simplify some of the messages that need to be sent and received in the MPI approaches of
|
|
attack graph generation, it does not cover the vast majority of them.
|
|
|
|
RAGE implements many custom classes and structs that are used throughout the generation process.
|
|
Qualities, topologies, network states, and exploits are a few such examples. Rather than breaking
|
|
each of these down into fundamental types manually, serialization functions are leveraged to handle
|
|
most of this. RAGE already incorporates Boost graph libraries for auxiliary support, so this work
|
|
extended this further to utilize the serialization libraries also provided by Boost. These
|
|
libraries also include support for serializing all STL classes, and many of the RAGE
|
|
classes have members that make use of the STL classes. One additional advantage of the Boost
|
|
library approach is that many of the RAGE class members are nested. For example, the NetworkState
|
|
class has a member vector of Quality classes. When serializing the NetworkState class, boost will
|
|
recursively serialize all members, including the custom class members, assuming they also have
|
|
serialization functions.
|
|
|
|
When using the serialization libraries, this work opted to use the intrusive route, where the
|
|
class instances are altered directly. This was preferable to the non-intrusive approach, since
|
|
the class instances were able to be altered with relative ease, and many of the class instances
|
|
did not expose enough information for the non-intrusive approach to be viable.
|
|
\TUsubsection{Data Consistency}
|
|
|
|
\TUsection{Tasking Approach}
|
|
\TUsubsection{Introduction to the Tasking Approach}
|
|
The high-level overview of the RAGE Data Flow Diagram was presented by the author of
|
|
\cite{cook_rage_2018}, and can be seen in Figure \ref{fig:RAGE_chart}. This diagram
|
|
includes an attack graph generation block that can be broken down into six main tasks.
|
|
These tasks are described in Figure \ref{fig:tasks}. Prior works such as that seen by the
|
|
authors of \cite{li_concurrency_2019} work to parallelize the attack graph generation using
|
|
OpenMP by dividing the frontier. This approach, however, utilizes Message Passing Interface (MPI)
|
|
to distribute the six tasks to examine the effect on speedup, efficiency, and scalability for
|
|
attack graph generation.
|
|
\begin{figure}[htp]
|
|
\includegraphics[width=\linewidth]{"./Chapter5_img/RAGE_Chart.png"}
|
|
\vspace{.2truein} \centerline{}
|
|
\caption{Generation Flowchart of RAGE}
|
|
\label{fig:RAGE_chart}
|
|
\end{figure}
|
|
\begin{figure}[htp]
|
|
\includegraphics[width=\linewidth]{"./Chapter5_img/horiz_task.drawio.png"}
|
|
\vspace{.2truein} \centerline{}
|
|
\caption{Task Overview of the Attack Graph Generation Process}
|
|
\label{fig:tasks}
|
|
\end{figure}
|
|
|
|
\TUsubsection{Algorithm Design}
|
|
\TUsubsubsection{Communication Structure}
|
|
\TUsubsubsection{Task Zero}
|
|
\TUsubsubsection{Task One}
|
|
\TUsubsubsection{Task Two}
|
|
\TUsubsubsection{Task Three}
|
|
\TUsubsubsection{Task Four}
|
|
\TUsubsubsection{Task Five}
|
|
|
|
\TUsubsection{Performance Expectations}
|
|
|
|
\TUsection{Subgraphing Approach}
|
|
\TUsubsection{Introduction to the Subgraphing Approach}
|
|
|
|
\TUsubsection{Algorithm Design}
|
|
\TUsubsubsection{Communication Structure}
|
|
\TUsubsubsection{Worker Nodes}
|
|
\TUsubsubsection{Root Node}
|
|
\TUsubsubsection{Database Node}
|
|
|
|
\TUsubsection{Performance Expectations}
|
|
|