57 lines
4.7 KiB
TeX
57 lines
4.7 KiB
TeX
%! TeX program = lualatex
|
|
%! TeX root = ../../thesis.tex
|
|
\documentclass[../../thesis.tex]{subfiles}
|
|
|
|
\begin{document}
|
|
|
|
\section{Fault-Injection Leveraged}\label{sec:fail}
|
|
|
|
\Gls{fail}~\autocite{schirmeierFAILOpenVersatile2015} is an emulation-based vulnerability analysis tool.
|
|
It provides a toolset to perform \gls{fi} experiments to analyze the vulnerability of software to transient hardware faults.
|
|
In contrast to other \gls{fi} tools\todo{give examples}, \Gls{fail} enables deep simulator state access while simultaneously supporting multiple simulator backends, like BOCHS~\autocite{bochs} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}.
|
|
|
|
\Gls{fail} is split into different components: A \textit{campaign} consists of multiple \gls{fi} \textit{experiments}, where each experiment injects a single fault.
|
|
The \textit{campaign controller} distributes those experiments to running \Gls{fail} instances.
|
|
Campaigns can be parallelized by running multiple instances on different systems or cores.
|
|
Each experiment utilizes \Gls{fail}'s \textit{simulator abstraction layer} to control the target backend, to fast-forward the target to the desired state and inject a fault.
|
|
This abstraction layer allows switching out backends to support different target platforms.
|
|
|
|
To perform a vulnerability analysis, the examined program needs to be instrumented with fences that define the region to trace (see \autoref{lst:tracefencemarkers}).
|
|
\begin{codeblock}[label=lst:tracefencemarkers]{Trace Region Fence}{.cpp}
|
|
\inputminted{cpp}{\subfix{listings/tracefence.cpp}}
|
|
\end{codeblock}
|
|
\Gls{fail} then records the instruction pointer changes and memory accesses inside this region during the so-called \textquote{golden run}: a faultless execution of the program that determines which injections should be performed during the campaign.
|
|
Then, the golden run is enriched with the traced region's disassembly to take into account the read and written registers.
|
|
The last step before campaign execution is the \textit{prune} step, where the collected data is translated into corresponding experiments.
|
|
Different data points from the trace that result in the same \textquote{fault-similarity class} (as used by Schirmeier~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}) are removed from the campaign.
|
|
Two experiments belong to the same similarity class if the \textit{relevant} parts of their resulting simulator state are identical.
|
|
From the pruned instruction pointer changes, memory accesses, and register accesses \Gls{fail} constructs a number of \textit{pilots}: representatives of the existing fault-similarity classes.
|
|
Each pilot then corresponds to a single experiment.
|
|
|
|
\Gls{fail}'s campaigns are event-driven: the user specifies conditions, for example an access to a certain memory region.
|
|
Once a condition is reached, a user-defined action is performed, like injecting a fault or registering a certain experiment outcome.
|
|
Users do not have to write every campaign from scratch, as \Gls{fail} includes a \textquote{generic experiment} which can be used as a starting point.
|
|
The generic experiment performs three types of fault injections by default:
|
|
\begin{itemize}
|
|
\item \sansbf{Memory} injections: Before the program reads from a memory address, a fault is injected.
|
|
\item \sansbf{Register} injections: Before the program reads from a register, a fault is injected.
|
|
\item \sansbf{Instruction Pointer} injections: The instruction pointer's value is randomized to disturb the program flow and introduce random jumps.
|
|
\end{itemize}
|
|
Furthermore, different experiment outcomes are classified:
|
|
\begin{itemize}
|
|
\item \sansbf{Trap}: The injected fault caused the simulated CPU to throw an exception.
|
|
\item \sansbf{Timeout}: The injected fault caused the program to stall.
|
|
\item \sansbf{Ok Marker} (\code{fail\_marker\_positive()}): The program executed correctly even with the injected fault.
|
|
\item \sansbf{Detected Marker} (\code{fail\_marker\_detected()}): The injected fault was detected by the program.
|
|
\item \sansbf{Fail Marker} (\code{fail\_marker\_negative()}): The injected fault was not detected by the program.
|
|
\item \sansbf{Access Outerspace}: Caught if the program reads or writes anywhere outside valid ELF addresses.
|
|
\item \sansbf{Write Textsegment}: Caught if the program writes to addresses inside the \code{.text} section of the program.
|
|
\end{itemize}
|
|
Ok/Detected/Fail outcomes are classified by instrumenting the tested code with \textquote{markers} (see \autoref{lst:classificationmarkers}).
|
|
If the program execution passes a marker, the experiment outcome is classified accordingly.
|
|
\begin{codeblock}[label=lst:classificationmarkers]{Classification Markers}{.cpp}
|
|
\inputminted{cpp}{\subfix{listings/classificationmarkers.cpp}}
|
|
\end{codeblock}
|
|
|
|
\end{document}
|