Reorder chapters + put abstract into frontmatter

chapters/02_background/02_00_background.tex

@@ -0,0 +1,9 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\chapter{Background}\label{ch:background}
+
+\end{document}

chapters/02_background/02_01_fault_chain.tex

@@ -0,0 +1,9 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Faults, Errors and Failures}\label{sec:faultchain}
+
+\end{document}

chapters/02_background/02_02_wasm.tex

@@ -0,0 +1,51 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{WebAssembly}\label{sec:wasm}
+
+The open \Acrfull{wasm} standard defines a portable virtual instruction set architecture, binary code format and text format for execution inside a virtual (stack) machine~\autocite{wasm3spec}.
+\Gls{wasm} instructions operate on an operand stack instead of registers: values are pushed and consumed through stack operations, similar to Java's virtual machine.
+It is developed and maintained by the World Wide Web Consortium (W3C)\iffalse{}\footnote{\url[2026-07-01]{https://w3.org/}}\fi to support high-performance applications in web-based environments.
+While the initial implementations of \Gls{wasm} runtime environments were confined to web browsers\footnote{In 2016, experimental \Gls{wasm} runtimes were implemented in Firefox, Google Chrome and Microsoft Edge: \url[2026-07-01]{https://hacks.mozilla.org/2016/03/a-webassembly-milestone/}}, \Gls{wasm} does not make any web-specific assumptions, so many different standalone runtimes like \textquote{Wasmtime}\footnote{\url[2026-07-01]{https://github.com/bytecodealliance/wasmtime/}} or the \Acrfull{wamr} (see \autoref{sec:wamr}) have emerged since.
+
+Besides instructions or execution behavior, two file formats are defined by the \Gls{wasm} standard: the \Gls{wasm} \textquote{Binary Format} \iffalse{}(see \autoref{lst:wasmexample})\fi for space-efficient representation and fast transmission, and the Lisp-like \Gls{wasm} \textquote{Text Format} for human readability (see \autoref{lst:watexample}).
+Both formats represent the same underlying content, but serve different purposes.
+
+% \begin{codeblock}[label=lst:wasmexample]{\Gls{wasm} Binary Format}{.wasm}
+%   \inputminted{hex}{listings/wat_example.hex}
+% \end{codeblock}
+
+\begin{codeblock}[label=lst:watexample]{\Gls{wasm} Text Format}{.wat}
+  \inputminted{wat}{listings/wat_example.wat}
+\end{codeblock}
+
+% TODO: Info on wat (module, type, func, memory, global, export)
+\autoref{lst:watexample} shows a minimal \Gls{wasm} module in text format.
+The \code{module} declaration groups all definitions of the compilation unit.
+A \code{type} declaration defines a shared function signature, the \code{func} references this type and provides an implementation.
+The module uses two pages of \code{memory} and defines the stack pointer as a mutable \code{global}.
+At the end, the memory and the \textquote{main} function are exported, so the host environment can invoke the module and access its state.
+Not visible in the above example are \code{import} statements, which allow the \Gls{wasm} program to access functions, variables or memory from the host environment.
+
+In a typical workflow, a program written in a high-level language like C or Rust is compiled to the \Gls{wasm} binary format using an LLVM-based toolchain; the resulting binary is then executed in a web-based or standalone runtime environment.
+The binaries mainly consist of \textit{values}, \textit{instructions}, \textit{functions} and \textit{memory}, bundled into \textit{modules}. % TODO: This is already visible in the watexample...
+To execute a program, the module is loaded from its binary format representation, \textit{decoded}, \textit{validated}, \textit{instantiated} and finally \textit{invoked}.
+
+At runtime, \Gls{wasm} provides memory safety, control flow integrity and independent execution (sandboxing)\footnote{\url[2026-07-01]{https://webassembly.org/docs/security/}}.
+Memory safety is improved through a bounds-checked linear memory with an inaccessible call stack\footnote{The call stack is not part of \Gls{wasm}'s linear memory but the execution environment: \url[2026-07-01]{https://bytecodealliance.github.io/wamr.dev/blog/the-wamr-memory-model/}}, preventing arbitrary memory accesses outside of the program's linear memory.
+The linear memory is a contiguous and growable byte array that is shared between the module and host.
+Control flow integrity stems from structured control flow: branches target verifiable positions and function calls are index-based and verified against the function table\iffalse{}\footnote{\url[2026-07-01]{https://clang.llvm.org/docs/ControlFlowIntegrity.html}}\fi.
+Additionally, the running program cannot observe its (immutable) source code to prevent control flow hijacking.
+Sandboxing is enforced by isolating each module's state: a module can only interact with the outside world through explicitly imported functions and resources provided by its host runtime.
+
+Its safety features, portability, language and hardware independence, and well-definedness make \Gls{wasm} an interesting platform even for resource-constrained and security-critical systems.
+
+% \subsection{\Glsdesc*{wasm} Binary Format}\label{ssec:wasmbinaryformat}
+% \subsection{\Glsdesc*{wasm} Text Format}\label{ssec:wasmtextformat}
+% \subsection{\Glsdesc*{wasm} Memories}\label{ssec:wasmmemories}
+% \subsection{\Glsdesc*{wasm} Control Flow}\label{ssec:wasmcontrolflow}
+
+\end{document}

chapters/02_background/02_03_wamr.tex

@@ -0,0 +1,30 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{WebAssembly Micro Runtime}\label{sec:wamr}
+
+\Acrfull{wamr}~\autocite{wamr} is a lightweight standalone \Gls{wasm} runtime by the \textquote{Bytecode Alliance}\iffalse{}\footnote{\url[2026-07-02]{https://bytecodealliance.org/}}\fi, designed for embedded devices.
+
+\Gls{wamr} includes three main components: The runtime libraries required to load and execute \Gls{wasm} modules (the decode, validate, instantiate, invoke process mentioned in \autoref{sec:wasm}) are called \textquote{\Gls{vmcore}}.
+\Gls{vmcore} can be embedded in C/C++ host applications.
+A standalone version of \Gls{vmcore} is provided by the \textquote{\gls{iwasm}} program.
+It acts as the host application and allows running \code{.wasm} files directly from the command line.
+The last component is \textquote{\gls{wamrc}}, a compiler transforming \code{.wasm} to \Gls{aot} compiled native code, necessary when not using one of \Gls{wamr}'s interpreter implementations.
+
+\Gls{wasm} modules can be executed in five different running modes using \Gls{vmcore}\footnote{\url[2026-07-01]{https://bytecodealliance.github.io/wamr.dev/blog/introduction-to-wamr-running-modes/}}:
+\begin{itemize}
+  \item \sansbf{\Gls{aot}} mode sacrifices platform-independence for performance and runtime size efficiency. The \Gls{wasm} module is compiled to platform-native code with \Gls{wasm}-specific scaffolding to retain \Gls{wasm}'s security features.
+  \item \sansbf{Classic Interpreter} is \Gls{wamr}'s slow reference implementation of a \Gls{wasm} interpreter, primarily intended for debugging.
+  \item \sansbf{Fast Interpreter} provides a speed boost over the classic interpreter by using a custom internal intermediate representation of \Gls{wasm} opcodes.
+  \item \sansbf{LLVM \Gls{jit}} achieves the highest performance (excluding \Gls{aot} mode) by utilizing the LLVM framework for compilation.
+  \item \sansbf{Fast \Gls{jit}} improves startup time over the LLVM \Gls{jit} by utilizing a lightweight compiler instead of LLVM at the cost of some execution performance.
+\end{itemize}
+In \Gls{aot} mode the \Gls{wasm} module is invoked by jumping into its native code; the interpreted modes follow a traditional opcode fetch, decode, execute loop.
+
+Of those five modes, this thesis is concerned with \Gls{aot} mode and the classic interpreter for analyzability reasons: \Gls{aot} mode is most similar to native execution without the additional \Gls{wasm} layer.
+The classic interpreter makes fault effects easier to analyze than the fast interpreter or \Glspl{jit} as no different code representations are involved.
+
+\end{document}

chapters/02_background/02_04_fail.tex

@@ -0,0 +1,56 @@
+%! 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 \Gls{bochs}\footnote{\url[2026-07-07]{https://bochs.sourceforge.io/}} 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 backend, advance execution to the desired state and inject.
+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}{listings/tracefence.cpp}
+\end{codeblock}
+\Gls{fail} then records the instruction pointer changes and memory accesses inside this region during the so-called \gls{goldenrun}: a faultless execution of the program that determines which injections should be performed during the campaign.
+Then, the \gls{goldenrun} is enriched with the traced region's disassembly to take into account the register reads and writes.
+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}{listings/classificationmarkers.cpp}
+\end{codeblock}
+
+\end{document}

chapters/02_background/02_05_software_based_hardening.tex

@@ -0,0 +1,15 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Software-Based Hardening}\label{sec:faultchain}
+
+\subsection{Software Replication}\label{ssec:softwarereplication}
+
+\subsection{ANBD-Codes}\label{ssec:anbdcodes}
+
+\subsection{CoRed: Combined Redundancy}\label{ssec:combinedredundancy}
+
+\end{document}

chapters/02_background/listings/classificationmarkers.cpp

@@ -0,0 +1,6 @@
+// Continuation of previous example
+if (sum == 100) {
+  fail_marker_positive();
+} else {
+  fail_marker_negative();
+}

chapters/02_background/listings/tracefence.cpp

@@ -0,0 +1,8 @@
+fail_start_trace();
+
+int sum = 0;
+for (int i = 0; i < 100; ++i) {
+  ++sum;
+}
+
+fail_stop_trace();

chapters/02_background/listings/wat_example.hex

@@ -0,0 +1,5 @@
+0000000 6100 6d73 0001 0000 0501 6001 0100 037f
+0000010 0102 0500 0103 0200 0806 7f01 4101 8880
+0000020 0b04 1107 0602 656d 6f6d 7972 0002 6d04
+0000030 6961 006e 0a00 0106 0004 2a41 000b     
+000003d

chapters/02_background/listings/wat_example.wat

@@ -0,0 +1,8 @@
+(module $wat_example.wasm
+  (type (;0;) (func (result i32)))
+  (func $main (type 0) (result i32)
+    i32.const 42)
+  (memory (;0;) 2)
+  (global $__stack_pointer (mut i32) (i32.const 66560))
+  (export "memory" (memory 0))
+  (export "main" (func $main)))