Reorder chapters + put abstract into frontmatter

.latexmkrc

@@ -6,6 +6,13 @@ $aux_dir       = ".aux";
 $bibtex        = "biber %O %S";
 $pdf_previewer = "zathura %O %S";
 
+# Count words after compiling the full thing
+$success_cmd = 'if [ %R = thesis ]; then ./wordcount.sh; fi';
+
+# Create minted output path
+use File::Path qw(make_path);
+make_path("$aux_dir/_minted");
+
 # Color output: https://tex.stackexchange.com/questions/617572/is-it-possible-to-make-latexmk-ouput-with-color
 {
     no warnings 'redefine';

Justfile

@@ -16,3 +16,7 @@ format:
 
 clean-format:
     rm thesis.fmt thesis.log thesis.tex.bbl thesis.tex.blg
+
+# Plot wordcounts.svg with ticks every n days (default: 7).
+plot-wordcounts days="7":
+    Rscript plot_wordcounts.R {{quote(days)}}

abstract.tex

@@ -0,0 +1,10 @@
+\addchap{Abstract}\label{ch:abstract}
+
+As semiconductor node sizes shrink, transient hardware faults pose a growing risk to computing systems, especially in environments where reliability is critical.
+WebAssembly (Wasm), a binary code format developed for the web, is increasingly used in embedded systems through standalone runtimes such as the WebAssembly Micro Runtime (WAMR)~\autocite{wamr}.
+This thesis investigates WAMR's compatibility with hardening techniques for transient hardware faults through systematic single-bit fault injection on a simulated IA-32 CPU using the Fault Injection Leveraged (FAIL*) fault-injection framework.
+
+The interpreter and ahead-of-time compiled execution modes of WAMR are compared under fault conditions and software-based hardening techniques are evaluated at two levels: (I) the language/application level, by hardening source programs before compilation to Wasm, and (II) the runtime level, by hardening WAMR itself.
+
+\todo[inline]{Abstract from expose, needs to be rewritten}
+\todo[inline]{Already link to glossary here? Already cite here?}

chapters/01_introduction/01_00_introduction.tex

@@ -6,28 +6,20 @@
 
 \chapter{Introduction}\label{ch:introduction}
 
-As semiconductor node sizes shrink, transient hardware faults pose a growing risk to computing systems, especially in environments where reliability is critical.
-\Gls{wasm}, a binary code format developed for the web, is increasingly used in embedded systems through standalone runtimes such as the \Gls{wamr}~\autocite{wamr}.
-This thesis investigates \Gls{wamr}'s compatibility with hardening techniques for transient hardware faults through systematic single-bit fault injection on a simulated IA-32 CPU using the \Gls{fail} \gls{fi} framework.
-
-The interpreter and \gls{aot} execution modes of \Gls{wamr} are compared under fault conditions and software-based hardening techniques are evaluated at two levels: (I) the language/application level, by hardening source programs before compilation to \Gls{wasm}, and (II) the runtime level, by hardening \Gls{wamr} itself.
-
-\todo[inline]{Abstract from expose, needs to be rewritten}
-
-Transient hardware faults can manifest in different types of errors such as \glspl{sdc} or  \glspl{due}.
-This work focuses on \glspl{sdc} specifically as they can propagate silently through subsequent data-/program-flow without causing detectable system failures, thus producing trusted but incorrect results.
+Transient hardware faults can manifest in different types of errors such as \Gls{sdc} or \Glspl{due}.
+This work focuses on \glspl{sdc} specifically as they can propagate silently through subsequent computations without causing detectable system failures, thus producing trusted but incorrect results.
 As \Gls{wasm} is adopted beyond the web, the resilience of \Gls{wasm} runtimes against these types of failures becomes a relevant question.
 
 \Gls{wamr}~\autocite{wamr} is designed for lightweight standalone execution of \Gls{wasm} modules.
 It supports interpretation (with and without \gls{jit} compilation) and \gls{aot} compilation, trading memory footprint and portability for performance.
 Besides platform independence, the \Gls{wasm} specification mandates additional safety features such as memory-isolated program execution and bounds-checked memory access.
-This raises the question of how fault resilience compares between executing a (hardened) program natively or introducing \Gls{wamr} as an additional abstraction layer to the execution environment.
+This raises the question of how fault resilience differs between native execution and execution through \Gls{wamr} as an additional abstraction layer.
 
 To answer these questions, this thesis uses the \Gls{fail} \gls{fi} framework~\autocite{schirmeierFAILVersatileFaultInjection2012} that allows injecting bit-level faults into a simulated CPU using the Bochs IA-32 emulator.
-\Gls{fail} is able to exhaustively cover the fault-space of possible bit flips by applying fault-similarity pruning to reduce the size of the fault-space and smart-hopping to accelerate single experiment simulations~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}.
+\Gls{fail} is able to exhaustively cover the fault-space of possible bit flips by applying fault-similarity pruning to reduce the size of the fault-space and smart-hopping to accelerate individual \Gls{fi} experiments~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}.
 
 To mitigate \Glspl{sdc}, software-based fault tolerance techniques are evaluated.
-\Glspl{anbcode}~\autocite{forinVitalCodedMicroprocessor1990} are a method of encoding and verifying data- and program-flow integrity during execution.
+\Glspl{anbcode}~\autocite{forinVitalCodedMicroprocessor1990} are a method of encoding and verifying data- and control-flow integrity during execution.
 \Gls{replication}~\autocite{polednaReplicaDeterminismDistributed1994} improves fault resilience by executing multiple independent copies of computations and using majority voting to detect or correct errors.
 Both techniques can be applied either at the application level, by hardening the program before compilation to \Gls{wasm}, or at the runtime level, by hardening \Gls{wamr} itself to transparently improve fault resilience.
 
@@ -37,29 +29,29 @@ The central objective is to analyze the effects of transient faults on \Gls{wamr
 
 \section{Research Questions}
 
-\paragraph{How do transient hardware faults affect the correctness of programs executed in \Gls{wamr} in comparison to native execution?}
+\paragraph{How do transient hardware faults affect the correctness of programs executed in WAMR in comparison to native execution?}
 
 \Gls{wamr} provides additional abstractions and safety features over native execution but brings increased complexity and a larger memory footprint.
-This question evaluates how these differences affect the rate of silent data corruption and if the increased fault surface outweighs the safety gains.
-The analysis distinguishes different experiment results such as correct execution, \gls{sdc} and \gls{due} to characterize the impact of \Gls{wamr} on system behavior under fault.
+This question evaluates how these differences affect the rate of silent data corruption and whether the increased fault surface outweighs the safety gains.
+The analysis distinguishes different experiment results such as correct execution, \gls{sdc} and \gls{due} to characterize the impact of \Gls{wamr} on system behavior under injected faults.
 Additionally, the distribution of faults is examined to determine particularly vulnerable code paths in \Gls{wamr}.
 
-\paragraph{How does the resilience of \Gls{wamr} differ between interpreter mode and \gls{aot} execution mode?}
+\paragraph{How does the resilience of WAMR differ between interpreter mode and AOT execution mode?}
 
 \Gls{wamr} supports both \gls{aot} compilation and interpreted execution of \Gls{wasm} modules.
-\Gls{aot} mode executes a \Gls{wasm} module pre-compiled to native code.
+\Gls{aot} mode executes a \Gls{wasm} module precompiled to native code.
 \Gls{wamr} sets up an execution environment that provides \Gls{wasm}-specific benefits such as isolated execution or checked memory access before jumping into native code.
 In contrast, interpreter mode executes \Gls{wasm} bytecode directly using one of \Gls{wamr}'s interpreter implementations.
 This question compares both modes under identical \gls{fi} campaigns to determine if the interpreters' additional runtime checks and safety mechanisms provide a more resilient execution environment than \gls{aot} mode.
 
-\paragraph{To what extent can source program hardening techniques applied to the source code reduce \gls{sdc}?}
+\paragraph{To what extent can application-level hardening techniques applied to the source code reduce SDC?}
 
 This question evaluates application-level hardening such as software \gls{replication} and \glspl{anbcode} before compilation to \Gls{wasm}.
 Techniques include the \Gls{cored}~\autocite{ulbrichEliminatingSinglePoints2012} approach, where programs are executed repeatedly before masking errors using the \glsdisp{anbcode}{ANB-coded} majority voter.
 The effectiveness of the tested methods is measured in terms of \gls{sdc} reduction in comparison to the non-hardened variants.
 Further considerations include the difference between detectable and correctable errors and the possibility of combining different hardening techniques.
 
-\paragraph{To what extent can the intermediate \Gls{wasm} program be hardened to reduce \gls{sdc}?}
+\paragraph{To what extent can the intermediate Wasm program be hardened to reduce SDC?}
 
 Instead of hardening the source program by modifying its source code, hardening techniques can be applied to the intermediate \Gls{wasm} bytecode representation.
 This allows exploiting properties of the source program that are not accessible in its source representation, such as \Gls{wasm}'s operand stack or its restricted control flow.
@@ -68,22 +60,22 @@ The bytecode level also allows a more fine-grained approach to methods like soft
 \paragraph{How effectively can hardening techniques be applied directly to the WAMR runtime's interpreter execution mode?}
 
 In contrast to application-level hardening, this question investigates modifying the \Gls{wamr} runtime itself to improve reliability.
-This could offer advantages since it eliminates the need to harden each program on the application level individually, but could be unfeasible to implement or introduce high performance penalties.
+This could offer advantages since it eliminates the need to harden each program individually at the application level, but may be infeasible to implement or introduce high performance penalties.
 Key components of the interpreter loop, such as the opcode dispatch mechanism or arithmetic operations, could be hardened.
 Additionally, other critical runtime components that contribute disproportionately to fault propagation are to be identified.
 The evaluation focuses on the feasibility of hardening the \Gls{wamr} runtime, its impact on \gls{sdc} rates, and its runtime cost.
 
 \paragraph{How effectively can hardening techniques be applied directly to the WAMR runtime's ahead-of-time execution mode?}
 
-To implement the safety features required by the \Gls{wasm} specification, \gls{wamr}'s \gls{aot} compiler (\textquote{\gls{wamrc}}) instruments the resulting native code with \textquote{glue}-code, for example to guard memory accesses or implement function lookups.
-Since transparently hardening \gls{aot} execution by modifying the compiler itself is out of scope for this thesis, this glue-code could be targeted instead.
+To implement the safety features required by the \Gls{wasm} specification, \gls{wamr}'s \gls{aot} compiler (\textquote{\gls{wamrc}}) instruments the resulting native code with \textquote{glue code}, for example to guard memory accesses or implement function lookups.
+Since transparently hardening \gls{aot} execution by modifying the compiler itself is out of scope for this thesis, this glue code could be targeted instead.
 The hardening potential of this approach is compared to the hardening of the interpreter execution mode in the previous research question.
 
 \paragraph{How do the runtime overheads of application- and runtime-level hardening compare?}
 
 Fault tolerance mechanisms introduce computational overhead, which is especially important in resource-constrained environments.
 This question compares the performance impact of application-level and runtime-level hardening to determine trade-offs between resilience and efficiency.
-Performance is evaluated in the context of embedded/resource-restrained systems, where constraints might limit the ability to use certain hardening strategies.
+Performance is evaluated in the context of resource-constrained embedded systems, where constraints might limit the ability to use certain hardening strategies.
 
 \todo[inline]{Taken from expose for reference}
 

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

@@ -12,36 +12,36 @@ It is developed and maintained by the World Wide Web Consortium (W3C)\iffalse{}\
 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 are equivalent, they represent the same underlying content differently for alternate purposes.
+Both formats represent the same underlying content, but serve different purposes.
 
 % \begin{codeblock}[label=lst:wasmexample]{\Gls{wasm} Binary Format}{.wasm}
-%   \inputminted{hex}{\subfix{listings/wat_example.hex}}
+%   \inputminted{hex}{listings/wat_example.hex}
 % \end{codeblock}
 
 \begin{codeblock}[label=lst:watexample]{\Gls{wasm} Text Format}{.wat}
-  \inputminted{wat}{\subfix{listings/wat_example.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} declares the shared function signature, the \code{func} then references this type and provides its implementation.
+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 \textquote{memory} and \textquote{main} function are exported, so the host environment can invoke the module and access its state.
+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 gets compiled to the \Gls{wasm} binary format using an LLVM-based toolchain, the binary is then executed in a web-based or standalone runtime 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 lastly, \textit{invoked}.
+To execute a program, the module is loaded from its binary format representation, \textit{decoded}, \textit{validated}, \textit{instantiated} and finally \textit{invoked}.
 
-During 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 achieved 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 and buffer overflows.
+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/hardware independence and well-definedness make \Gls{wasm} an interesting platform even for resource-constrained and security-critical systems.
+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}

chapters/02_background/02_03_wamr.tex

@@ -11,19 +11,20 @@
 \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.
+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, mainly targeted towards debugging purposes.
+  \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 lighweight compiler instead of LLVM, but trades some runtime performance.
+  \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.
+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 allows a simpler understanding of fault effects than the fast interpreter or \Glspl{jit} as no different code representations are involved.
+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

@@ -8,24 +8,24 @@
 
 \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\footnote{\url[2026-07-07]{https://bochs.sourceforge.io/}} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}.
+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 target backend, to fast-forward the target to the desired state and inject a fault.
+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}{\subfix{listings/tracefence.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 \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.
+\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.
+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.
@@ -50,7 +50,7 @@ Furthermore, different experiment outcomes are classified:
 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}}
+  \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/04_methodology/04_00_methodology.tex

@@ -6,6 +6,4 @@
 
 \chapter{Methodology}\label{ch:methodology}
 
-Specific FARM-model variant for this research questions, fault model.
-
 \end{document}

chapters/04_methodology/04_01_experimental_design.tex

@@ -0,0 +1,19 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Experimental Design}\label{sec:experimentaldesign}
+
+This thesis evaluates the effect of execution mode and software hardening on program behavior under injected faults.
+Each selected benchmark is evaluated under native execution, \Gls{aot} compiled \Gls{wasm} execution, and interpreted \Gls{wasm} execution.
+Comparisons are performed between corresponding benchmark variants using the same inputs and expected results.
+
+The execution mode is the factor that influences the experiment the most.
+For benchmarks with hardened implementations, the hardening techniques are additional influences.\todo{Open if I get to that, but preferably at least CoRed}
+The experiment outcomes describe if execution completes successfully with the expected result, detects an error, or terminates for other reasons, like timeouts.
+
+The experiments are designed to determine what changes when adding \Gls{wamr} to an unhardened or hardened benchmark, and specifically, what changes between \Gls{wamr}'s \Gls{aot} compiled and interpreted running modes.
+
+\end{document}

chapters/04_methodology/04_02_farm_model.tex

@@ -0,0 +1,103 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Applying the FARM-Model}\label{sec:applyingthefarmmodel}
+
+With \Gls{farm}~\autocite{arlatFaultInjectionDependability1990}, Arlat et al.\ introduced a model for applications of \Gls{fi} to clearly specify the faults introduced, the conditions under which the system works, and the interpretation of the observed outcomes.
+\Gls{farm} structures its specification into four sets: faults (\(F\)) describe the disturbances introduced into the system, activations (\(A\)) specify the execution conditions of the system, readouts (\(R\)) are the outcomes collected from experiment execution, and measures (\(M\)) finally derive quantities from the observations to evaluate the system's behavior.
+
+In this thesis, \Gls{farm} provides the framework to specify and compare the native, \Gls{aot}, and interpreted experiment variants and interpret the experiment results.
+
+\subsection{Faults}\label{ssec:farmfaults}
+
+The \Gls{fi} campaigns inject single-bit faults into the machine state exposed by the \Gls{bochs} simulator.
+Fault locations are separated into memory, register, and instruction-pointer categories that are evaluated separately.
+The injection locations and times are determined from a fault-free execution (\gls{goldenrun}) of the selected benchmark.
+The evaluated fault space is thus specific to the executed benchmark, its inputs, the execution mode and the chosen traced region.
+
+\todo[inline]{Write about comparability of results, equivalence classes etc.}
+
+The fault model excludes multiple simultaneous faults or multi-bit faults.
+After an injection, the program execution continues without intervention until an experiment outcome is reached.
+
+\subsection{Activations}\label{ssec:farmactivations}
+
+\todo[inline]{This reads more like a list of notes}
+
+Each benchmark defines a traced region through explicit start and stop markers.
+The \gls{goldenrun} records a fault-free execution trajectory of that region and provides the simulator starting state for each injection.
+Additionally, the \gls{goldenrun} determines the injection locations.
+The trace boundary alone determines which program activity contributes to the experiment.
+All benchmarks use equivalent boundaries on the source-level: state initialization and \Gls{wamr} runtime initialization lie outside of this boundary.
+In contrast to natively executed benchmark variants, the \Gls{aot} or interpreted variants may call \Gls{wamr} runtime code within the boundary.
+
+The effects of injected faults are later evaluated through the readouts described in \autoref{ssec:farmreadouts}.
+
+\subsection{Pruning}\label{ssec:farmpruning}
+
+Instead of injecting a single-bit fault at every possible location derived from the \gls{goldenrun}, the fault space is pruned before the campaign is run.
+Equivalence classes of faults leading to the same outcome are identified and represented by a single \gls{pilot} experiment, so the outcomes of all experiments that belong to an equivalence class can be determined by performing injections on only its \gls{pilot}.
+Because injections into different bits can cause different outcomes, only injections into the same bit can belong to a single equivalence class.
+Additionally, there must not be intervening accesses into a memory location within a single equivalence class.
+
+For example, if a single byte at the memory location \(m\) is written by the program under test at time \(t_{0}\) and read back (without \(m\) being accessed in between) at time \(t_{1}\) with \(t_{1} > t_{0}\), each injection into bit \(b\) of \(m\) during the time interval \([t_{0}, t_{1}]\) would cause the same outcome (multiple simultaneous faults are outside the scope of this thesis).
+Instead of performing \(t_{1} - t_{0} + 1\) individual injections into bit \(b\) of \(m\), the pruner marks \([t_{0}, t_{1}]\) as an equivalence class, represented by a single injection into bit \(b\) of \(m\) at time \(t_{1}\) (or any other \(t\in [t_{0}, t_{1}]\)).
+
+This example is a case of \textquote{def/use pruning}, as introduced by Smith et al.~\autocite{smithMethodDetermineEquivalent1995} and Güthoff and Sieh~\autocite{guthoffCombiningSoftwareimplementedSimulationbased1995}.
+
+\subsection{Readouts}\label{ssec:farmreadouts}
+
+Outcomes are classified by using explicit markers on the source level and listening for simulator events (possible outcomes are listed in \autoref{tab:experimentoutcomes}).
+The positive and negative markers report the result of the benchmark's success condition outside the trace boundary, the detected marker records a fault that manifested to an error but was detected by the program.
+In \Gls{wamr} benchmark variants, \Gls{wamr}'s exception handler reports an explicit outcome as well.
+Traps, timeouts and invalid memory accesses are reported by the simulator without the need for source-level instrumentation.
+
+\todo[inline]{Table is duplicated with background chapter on FAIL}
+
+\begin{table}[H]
+  \centering
+  \begin{tabularx}{\textwidth}{lX}
+    Marker Type               & Description                                                                         \\
+    \midrule
+    \code{OK\_MARKER}         & The experiment's success condition passed                                           \\
+    \code{FAIL\_MARKER}       & The experiment's success condition did not pass                                     \\
+    \code{DETECTED\_MARKER}   & The experiment signalled an error through some detection mechanism                  \\
+    \code{TRAP}               & The experiment did not complete because the CPU threw an exception                  \\
+    \code{TIMEOUT}            & The experiment did not complete in the time limit                                   \\
+    \code{ACCESS\_OUTERSPACE} & The program accessed an address outside the program's address space                 \\
+    \code{WRITE\_TEXTSEGMENT} & The program wrote to an address located inside the program's text segment           \\
+    \code{GROUP1\_MARKER}     & An \Gls{aot} or interpreted variant reached \Gls{wamr}'s internal exception handler \\
+  \end{tabularx}
+  \caption{Outcomes detected by \Gls{fail}'s experiment runner.}\label{tab:experimentoutcomes}
+\end{table}
+
+\subsection{Measures}\label{ssec:farmmeasures}
+
+To quantify the experiment outcomes, the evaluation must reconstruct weighted outcome totals using the \gls{pilot} outcomes with the corresponding sizes of the equivalence classes' fault spaces.
+The intuitive reason for this is, as Schirmeier et al.\ state in~\autocite{schirmeierAvoidingPitfallsFaultInjection2015}, that \textquote{the longer data lives in a memory cell, the more probable a soft error will affect it}.
+
+Continuing the example from \autoref{ssec:farmpruning}, an outcome observed for an injection into a particular bit of a memory location \(m\) represents \(t_{1} - t_{0} + 1\) possible injection times within the equivalence class.
+Its contribution to the weighted total for that outcome is therefore
+\[
+  w = t_{1} - t_{0} + 1.
+\]
+The weighting is applied separately to each injected bit because injections into different bits of \(m\) could produce different outcomes.
+For example, if \(m\) is one byte wide and injections into three of its eight bits produce \code{FAIL\_MARKER}, this interval contributes \(3w\) to the weighted \code{FAIL\_MARKER} total (and \(8w\) to the total weight across all outcomes).
+
+Generally, if \(C\) is the set of equivalence classes for a benchmark variant and outcome, \(s_{c}\) and \(e_{c}\) are the start and end times of each class \(c\in C\), \(B_{c}\) is the set of injected bits, and \(o_{c,b}\) is the outcome corresponding to the injection into bit \(b\in B_{c}\), then the weighted total for an outcome \(o\) is
+\[
+  W_o = \sum\limits_{c \in C} \sum\limits_{b \in B_c} (e_c - s_c + 1)\,\mathbf{1}\{o_{c,b} = o\},
+\]
+where \(\mathbf{1}\{o_{c,b} = o\}\) is the indicator function, which equals one if the recorded outcome matches \(o\), and zero otherwise.\footnote{%
+  In terms of \Gls{fail}'s database, this corresponds to summing \code{t.time2 - t.time1 + 1} after joining the trace intervals to their \gls{pilot} results and grouping them by outcome.
+  The join accounts for the individual injected bits, so no additional factor for the bit width is required in the sum.
+}
+\todo[inline]{Don't put this in a footnote, put it in controlling what data gets extracted from the experiments}
+
+Weighted outcome totals are reported separately for each fault category, execution mode and injection location (memory, registers or instruction-pointer).
+Outcome shares describe the composition of each variant's fault space, while absolute totals show differences in vulnerability caused by execution duration and memory footprint.
+
+\end{document}

chapters/04_methodology/04_03_result_filtering.tex

@@ -0,0 +1,15 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Result Filtering}\label{sec:resultfiltering}
+
+To analyze specific facets of a system under fault-injection, parts of the observed outcomes and generated measures can be excluded from evaluations.
+Experiments in this thesis aim to characterize program behavior under transient fault conditions regarding its execution mode, so additional overhead caused by, e.g., \Gls{wamr} runtime components is included in the analysis.
+Overhead introduced solely by fault-injection instrumentation is excluded, it is an artifact of the measurement process.
+
+\todo[inline]{Depending on what I do in the evaluations, this needs expansion}
+
+\end{document}

chapters/04_methodology/04_04_attribution.tex

@@ -0,0 +1,9 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Attributing Fault Observations to Runtime Components}\label{sec:attributiontoruntimecomponents}
+
+\end{document}

chapters/04_methodology/04_05_reproducibility.tex

@@ -0,0 +1,14 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Reproducibility}\label{sec:reproducibility}
+
+\begin{itemize}
+  \item What is needed to reproduce an experiment (experiment binary, experiment runner config, fail binary for the campaign/experiment definition, filter definitions, query definitions)
+  \item What of this is stored per experiment and what only once?
+\end{itemize}
+
+\end{document}

chapters/05_experiment_setup/05_00_experiment_setup.tex

@@ -0,0 +1,11 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\chapter{Experiment Setup}\label{ch:experimentsetup}
+
+\todo[inline]{Maybe split this chapter into two: Experiment Setup and Implementation}
+
+\end{document}

chapters/05_experiment_setup/05_01_execution_environment.tex

@@ -0,0 +1,25 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Execution Environment}\label{sec:executionenvironment}
+
+To keep the experiment setup as simple as possible, experiments are executed in a bare-metal environment without any operating system.
+This has the advantage of avoiding some sources of possible non-determinism (caused, e.g., by scheduling or interrupts) during fault injection.
+It also prevents any operating system code from being targeted by the \Gls{fi} framework.
+While a suitable and correctly configured statically linked real-time operating system inside a controlled, emulated environment is not prone to those issues, running experiments bare-metal excludes this category of possible problems entirely.
+
+Instead, experiments are cross-compiled to freestanding executables using \code{i386-elf-gcc} with Newlib\footnote{\url[2026-08-12]{https://sourceware.org/newlib/}} libc.
+To make Newlib work inside a bare-metal environment, certain system calls must be provided by the platform, although not all of them need to be functional\footnote{\url[2026-08-12]{https://sourceware.org/newlib/libgloss.html\#Libraries-1}}:
+\begin{itemize}
+  \item \code{sbrk()} is required for Newlib's \code{malloc()}, \code{calloc()} and \code{realloc()} memory-management functions. Although \Gls{wamr} uses its own memory allocator implementation (see \autoref{sssec:wamrmemoryallocation}), \Gls{wasm} targets may still require a functional \code{sbrk()} if \Gls{wamr}'s \code{snprintf}/\code{vsnprintf} are used, depending on the format string.
+  \item \code{read()}, \code{write()}, \code{close()}, \code{fstat()} and \code{isatty()} stubs are required for \Gls{wamr} targets. Since no filesystem or console exists in the execution environment, the stubs do not need to implement functional behavior.
+  \item \code{lseek()} is required for C and \Gls{wamr} targets. A stub suffices for the same reason as above.
+  \item \code{\_exit()}, \code{kill()} and \code{getpid()} are required for \Gls{wamr} targets. Implementations can be omitted, as the execution environment does not use processes.
+\end{itemize}
+
+For experiment execution, the executables are packed into Multiboot\footnote{\url[2026-07-13]{https://www.gnu.org/software/grub/manual/multiboot/multiboot.html}}-compatible disk images with GNU GRUB\footnote{\url[2026-08-12]{https://www.gnu.org/software/grub/}} embedded via \code{grub-mkrescue} and executed in \Gls{bochs} via \Gls{fail}.
+
+\end{document}

chapters/05_experiment_setup/05_02_wamr_modifications.tex

@@ -0,0 +1,43 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{WAMR Modifications}\label{sec:wamrmodifications}
+
+The experiments use a slightly modified version of \Gls{wamr} based on release 2.4.4\footnote{\url[2026-09-11]{https://github.com/wasm-micro-runtime/wasm-micro-runtime/releases/tag/WAMR-2.4.4}}.
+The modifications provide a platform port for the bare-metal execution environment described in \autoref{sec:executionenvironment} and an explicit marker call during runtime exceptions.
+
+\subsection{Bare-Metal Platform}\label{ssec:wamrbaremetal}
+
+\Gls{wamr} implements platform-specific details separately from the runtime inside its platform abstractions.
+The added \code{baremetal} platform only provides the subset of this layer that is required by the experiments.
+It is selected through \code{WAMR\_BUILD\_PLATFORM=baremetal} and compiled for 32-bit x86 using a freestanding cross-compiler.
+The build enables the classic interpreter and \Gls{aot} execution, while disabling the fast interpreter, the \Glspl{jit}, and WASI support.
+The modifications also remove the mandatory CMake thread-library lookup and disable the compiler option \code{-mindirect-branch-register}\todo{Option was disabled because gcc 5.4 didn't support it, now I'm using a newer cross compiler}.
+
+Since execution is single-threaded and no operating system is present, many platform functions are stubs.
+Platform initialization and mutex operations report success without performing any work, console output is discarded, and time queries return zero.
+The system allocation functions \code{os\_malloc} and \code{os\_realloc} return \code{NULL}.
+Instead, the host initializes \Gls{wamr} with a supplied memory pool or custom allocation callbacks, as described later in \autoref{sssec:wamrmemoryallocation}.
+
+\Gls{aot} experiment variants also require implementations of \code{os\_mmap} and \code{os\_mremap} to allocate memory for the loaded module text.
+The platform provides these using a static \SI{2}{\mega\byte} buffer and a simple bump allocator (allocator with monotonically increasing offset into the reserved memory region).
+Remapping allocates a new region and copies the old one, without reclaiming any memory.
+Unmapping does not reclaim memory, and \code{os\_mprotect} reports success without changing access permissions.
+Thus, these functions only supply storage for the loader without implementing any other virtual-memory or memory protection related functionalities.
+
+The \code{os\_mmap} buffer can optionally be placed in the linker section \code{.text.wamr\_mmap} by defining \code{WAMR\_MMAP\_IN\_TEXT}.
+The linker script fences this region with symbols so that faults can be attributed to this address range during \Gls{fail} experiment evaluation.
+
+\subsection{Runtime Exception Marker}\label{ssec:wamrexceptionmarker}
+
+To differentiate errors detected by the \Gls{wamr} runtime from other fault outcomes, a \code{fail\_marker\_group1} call is added to the \code{wasm\_set\_exception\_local} handler.
+Clearing an exception by passing \code{NULL} does not invoke the marker.
+This exception handler is utilized by both interpreted execution and \Gls{aot} execution, whose \code{aot\_set\_exception} forwards to \code{wasm\_set\_exception}.
+
+To enable the \code{fail\_marker\_group1} outcome, the marker function symbol has to be registered with \Gls{fail}'s experiment runner.
+\Gls{fail} then installs a breakpoint listener at this function's address and aborts the injection run if it fires.
+
+\end{document}

chapters/05_experiment_setup/05_03_workload_structure.tex

@@ -0,0 +1,99 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Workload Program Structure}\label{sec:workloadprogramstructure}
+
+\subsection{Shared Traced Region}\label{ssec:sharedtracedregion}
+
+All experiment variants (C, \Gls{aot} and interpreted) share the same traced region on the source level that contains the actual benchmarked workload.
+It is structured into three parts: the benchmark initialization, its execution and the success condition.
+Initialization and success condition lie outside the traced region (see \autoref{lst:workloadstructure}), so a workload under fault always starts with its intended initial state and its result evaluation is trustworthy.
+
+\begin{codeblock}[label=lst:workloadstructure]{Example of a shared workload.}{C++}
+  \inputminted{cpp}{listings/workloadstructure.cpp}
+\end{codeblock}
+
+The \code{EXPORT("fnct")} annotation expands to \code{\_\_attribute\_\_((export\_name("fnct")))}, a directive to the LLVM-based C-to-\Gls{wasm} compiler from the WASI SDK\footnote{\url[2026-09-11]{https://github.com/WebAssembly/wasi-sdk}} that controls the name of the exported \Gls{wasm} function, so it can later be found by \Gls{wamr} (see \autoref{sssec:wamrmoduleexecution}).
+
+Such a shared workload is then called from a variant-specific host program, as seen in the next two sections.
+
+\subsection{Native Host}\label{ssec:nativehost}
+
+The native host for C experiment variants (see \autoref{lst:nativehostprogram}) is the simplest of the two: it just calls the \code{wasm\_module} function described in \autoref{ssec:sharedtracedregion} and does not need to consider any runtime initialization.
+
+For debugging purposes, the native C variant can also be compiled for Linux instead of \Gls{fail}'s bare-metal environment.
+The \code{MAIN} and \code{RET} macros expand according to the appropriate entry function signature required by the target platform.
+
+\begin{codeblock}[label=lst:nativehostprogram]{Native workload host program.}{C++}
+  \inputminted{cpp}{listings/nativehost.cpp}
+\end{codeblock}
+
+\subsection{Wasm Host and WAMR Setup}\label{ssec:wasmhostandwamrsetup}
+
+The host program for \Gls{wasm} experiment variants needs to do additional work compared to the native one, mainly concerning the initialization of the \Gls{wamr} runtime\footnote{Described here: \url[2026-09-11]{https://wasmruntime.com/en/tutorials/wamr\#34-step-4-c-embedding-integration}}.
+
+\subsubsection{Runtime Initialization and Memory Allocation}\label{sssec:wamrmemoryallocation}
+
+\Gls{wamr} supports different allocators for the \Gls{wasm} runtime memory.
+Relevant for this thesis are \code{Alloc\_With\_Pool} and \code{Alloc\_With\_Allocator}.
+\code{Alloc\_With\_Pool} is the simplest one, as it only requires a memory pool, no custom allocator functions.
+\code{Alloc\_With\_Allocator} is slightly more involved, as it allows complete control over memory regions and allocation behavior by utilizing custom allocator functions.
+To use this allocator, \code{malloc}, \code{realloc} and \code{free} need to be implemented.
+In this thesis, a simple bump allocator is implemented, like the one used by \Gls{wamr} itself, described in \autoref{ssec:wamrbaremetal}.
+
+\begin{codeblock}[label=lst:wamrinit]{\Gls{wamr} initialization.}{C++}
+  \inputminted{cpp}{listings/wamrinitialization.cpp}
+\end{codeblock}
+
+The main advantage of the more complex \code{Alloc\_With\_Allocator} shows up when \Gls{wamr} is built with \code{WAMR\_BUILD\_ALLOC\_WITH\_USAGE=1}.
+This flag modifies the allocator function signatures to accept an additional \code{mem\_alloc\_usage\_t} argument, which can take the values \code{Alloc\_For\_Runtime} or \code{Alloc\_For\_LinearMemory}.
+Based on this value, memory allocations can be distributed across separate pools for \Gls{wamr} runtime memory and \Gls{wasm} linear memory, allowing a more in-depth experiment evaluation by attributing memory faults to different purposes or filtering faults originating from a specific memory pool entirely.
+
+How to initialize the runtime with the desired configuration is shown in \autoref{lst:wamrinit}.
+
+\subsubsection{Native Function Invocations}\label{sssec:wamrnativeinvocations}
+
+\Gls{fail} markers are realized as breakpoint handlers in \Gls{fail}'s simulator backend, with the breakpoints registered to native marker function invocations.
+This presents a small problem when markers need to be called from within a workload that has been compiled to \Gls{wasm}, as those function invocations are no longer present as native instructions.
+
+\begin{codeblock}[label=lst:wamrnativefunctions]{\Gls{wamr} native marker definitions.}{C++}
+  \inputminted{cpp}{listings/wamrnativefunctions.cpp}
+\end{codeblock}
+
+To circumvent this, \Gls{wamr}'s native function invocation mechanism can be used\footnote{Also described here: \url[2026-09-11]{https://wasmruntime.com/en/tutorials/wamr\#41-complete-example-logging-host-function}}: the breakpoint handlers are registered to native functions that are not compiled to \Gls{wasm} (see \autoref{lst:wamrnativefunctions}) but are registered to the \Gls{wamr} runtime instead (see \autoref{lst:wamrnativefunctionregistration}).
+
+\begin{codeblock}[label=lst:wamrnativefunctionregistration]{\Gls{wamr} native function registration.}{C++}
+  \inputminted{cpp}{listings/wamrnativefunctionregistration.cpp}
+\end{codeblock}
+
+This registration populates a lookup table that maps the native function pointers to their names, so that \Gls{aot} programs can call \Gls{wamr}'s internal \code{aot\_invoke\_native} and interpreted programs can call \code{wasm\_interp\_call\_func\_native} to invoke those functions.
+This indirection happens implicitly, on the application level no special steps need to be taken, functions can be called by their registered names.
+To be compatible with the native function registration mechanism, functions need to accept the \Gls{wasm} execution environment as an argument (see \autoref{lst:wamrnativefunctions}).
+
+It is important to consider that this native call mechanism introduces additional overhead that provides additional attack surface during fault-injection.
+The return from the \code{fail\_start\_trace} call, the entry into the \code{fail\_stop\_trace} call and the entirety of any other marker call within the traced region are susceptible to faults unintended by the experiment design: the source code instrumentation should only steer the fault-injection process, not interact with the workload execution itself.
+How to counteract this limitation is described later, in \autoref{sec:resultfiltering} and \autoref{sec:resultextractionandqueries}.
+
+\subsubsection{Wasm Module Instantiation and Execution}\label{sssec:wamrmoduleexecution}
+
+To load the workload's \Gls{wasm} module and run it, a series of steps need to be executed:
+\begin{enumerate}
+  \item Load the module (\code{wasm\_runtime\_load})
+  \item Instantiate the module (\code{wasm\_runtime\_instantiate})
+  \item Create a \Gls{wasm} execution environment (\code{wasm\_runtime\_create\_exec\_env})
+  \item Find the exported entry function (\code{wasm\_runtime\_lookup\_function})
+  \item Call the exported entry function (\code{wasm\_runtime\_call\_wasm})
+\end{enumerate}
+
+\begin{codeblock}[label=lst:wamrmodulecall]{Calling a \Gls{wasm} module from C.}{C++}
+  \inputminted{cpp}{listings/wamrmodulecall.cpp}
+\end{codeblock}
+
+In this thesis, compiled \Gls{wasm} modules are converted to C-style arrays using \code{xxd} and embedded into the program's source text.
+This way, file access can be avoided and the module is loaded by simply passing a pointer to the correct function.
+A simplified module call sequence is shown in \autoref{lst:wamrmodulecall}.
+
+\end{document}

chapters/05_experiment_setup/05_04_experiment_variants.tex

@@ -0,0 +1,19 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Experiment Variants}\label{sec:experimenttypes}
+
+\begin{itemize}
+  \item C only
+  \item WAMR AOT
+  \item WAMR interpreter
+  \item Different filters
+  \item Compiler settings, optimization settings (add tables to the appendix that include EVERY setting)
+  \item Memory sizes
+  \item Runner settings, timeout size
+\end{itemize}
+
+\end{document}

chapters/05_experiment_setup/05_05_controlling_injections.tex

@@ -0,0 +1,15 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Controlling What Gets Injected/Memory Isolation}\label{sec:controllingmemoryisolation}
+
+\begin{itemize}
+  \item How can the WAMR allocators be used to control what gets injected? They cannot. --catch-write-textsegment doesn't prevent injection, just writes of the regular program.
+  \item --catch-write-textsegment (does NOT prevent injections into the textsegment!)
+  \item --catch-outerspace
+\end{itemize}
+
+\end{document}

chapters/05_experiment_setup/05_06_results_filtering.tex

@@ -0,0 +1,15 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Result Extraction and Database Queries}\label{sec:resultextractionandqueries}
+
+\begin{itemize}
+  \item What queries are run?
+  \item How are the equivalence classes expanded?
+  \item What/How is the data filtered (e.g., to exclude WAMR's native call chain)?
+\end{itemize}
+
+\end{document}

chapters/05_experiment_setup/05_07_missing_fail_markers.tex

@@ -4,41 +4,8 @@
 
 \begin{document}
 
-\chapter{Experiment Setup}\label{ch:experimentsetup}
-
-\section{Execution Environment}
-\begin{itemize}
-  \item Baremetal execution in BOCHS
-\end{itemize}
-
-\section{\Gls{wamr} Modifications}\label{sec:wamrmodifications}
-\begin{itemize}
-  \item Cross-compiler issues
-  \item Which platform functions?
-  \item WAMR exception handler marker?
-\end{itemize}
-
-\section{Wasm Host Program}
-\begin{itemize}
-  \item WAMR setup
-  \item WAMR memory allocators
-  \item Calling \code{FAIL\_MARKER}s (native functions)
-\end{itemize}
-
-\section{Experiment Types}
-\begin{itemize}
-  \item C only
-  \item WAMR AOT
-  \item WAMR interpreter
-\end{itemize}
-
-\section{Controlling What Gets Injected/Memory Isolation}
-\begin{itemize}
-  \item --catch-write-textsegment (does NOT prevent injections into the textsegment!)
-  \item --catch-outerspace
-\end{itemize}
-
 \section{Missing FAIL\_MARKERs for AOT experiments}
+
 \begin{itemize}
   \item AOT Addressauflösung/Def-Use chain theory
   \item Somehow caught by --catch-write-textsegment or --catch-outerspace because stuff was linked to .text?
@@ -55,10 +22,4 @@
   \item Solution: Gap in the .elf symbol space (addresses that are not covered by some symbol). FAIL needs this to disassemble the Wasm AOT code to find the register accesses. FAIL also needs to find this AOT code, so it can't be relocated -> Needs --xip
 \end{itemize}
 
-\section{Target Programs}
-\begin{itemize}
-  \item Toy examples
-  \item TacleBench~\autocite{TACLeBench,seidlerTACLeBenchWasmConverter2026}
-\end{itemize}
-
 \end{document}

chapters/05_experiment_setup/05_08_target_programs.tex

@@ -0,0 +1,14 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{Target Programs}
+
+\begin{itemize}
+  \item Toy examples
+  \item TacleBench~\autocite{TACLeBench,seidlerTACLeBenchWasmConverter2026}
+\end{itemize}
+
+\end{document}

chapters/05_experiment_setup/listings/nativehost.cpp

@@ -0,0 +1,15 @@
+// Define FAIL* marker symbols
+void fail_start_trace(void) {}
+void fail_stop_trace(void) {}
+void fail_marker_positive(void) {}
+void fail_marker_negative(void) {}
+void fail_marker_detected(void) {}
+
+// Forward declare workload
+int wasm_module(void);
+
+// Execute
+MAIN {
+  int retval = wasm_module();
+  RET(retval);
+}

chapters/05_experiment_setup/listings/wamrinitialization.cpp

@@ -0,0 +1,18 @@
+static RuntimeInitArgs init_args;
+memset(&init_args, 0, sizeof(RuntimeInitArgs));
+
+#ifdef ALLOC_WITH_ALLOCATOR
+init_args.mem_alloc_type = Alloc_With_Allocator;
+init_args.mem_alloc_option.allocator.malloc_func = (void *)wamr_malloc;
+init_args.mem_alloc_option.allocator.realloc_func = (void *)wamr_realloc;
+init_args.mem_alloc_option.allocator.free_func = (void *)wamr_free;
+#else // Alloc_With_Pool
+init_args.mem_alloc_type = Alloc_With_Pool;
+init_args.mem_alloc_option.pool.heap_buf = global_heap_buf;
+init_args.mem_alloc_option.pool.heap_size = sizeof(global_heap_buf);
+#endif
+
+init_args.max_thread_num = 1;
+if (!wasm_runtime_full_init(&init_args)) {
+  goto error_cleanup;
+}

chapters/05_experiment_setup/listings/wamrmodulecall.cpp

@@ -0,0 +1,23 @@
+// Error handling is omitted
+char error_buf[128];
+
+wasm_module_t module = wasm_runtime_load(
+  module_array, module_array_length, error_buf, sizeof(error_buf));
+
+wasm_module_inst_t module_inst = wasm_runtime_instantiate(
+  module, STACK_SIZE, HEAP_SIZE, error_buf, sizeof(error_buf));
+
+wasm_exec_env_t exec_env = wasm_runtime_create_exec_env(
+  module_inst, STACK_SIZE);
+
+wasm_function_inst_t func = wasm_runtime_lookup_function(
+  module_inst, "wasm_module");
+
+// Arguments can be supplied to the function
+// by passing a pointer to an args buffer.
+// No arguments are set here, but a single
+// slot is reserved for the return value.
+uint32_t argv[1];
+uint32_t argc = 0;
+wasm_runtime_call_wasm(exec_env, func, argc, argv);
+uint32_t retval = argv[0];

chapters/05_experiment_setup/listings/wamrnativefunctionregistration.cpp

@@ -0,0 +1,12 @@
+static NativeSymbol native_symbols[] = {
+  {"fail_start_trace", (void *)host_fail_start_trace, "()", NULL},
+  {"fail_stop_trace", (void *)host_fail_stop_trace, "()", NULL},
+  {"fail_marker_positive", (void *)host_fail_marker_positive, "()", NULL},
+  {"fail_marker_negative", (void *)host_fail_marker_negative, "()", NULL},
+  {"fail_marker_detected", (void *)host_fail_marker_detected, "()", NULL},
+};
+
+int count = sizeof(native_symbols) / sizeof(NativeSymbol);
+if (!wasm_runtime_register_natives("env", native_symbols, count)) {
+  goto error_cleanup;
+}

chapters/05_experiment_setup/listings/wamrnativefunctions.cpp

@@ -0,0 +1,23 @@
+// Define FAIL* marker symbols
+void fail_start_trace(void) {}
+void fail_stop_trace(void) {}
+void fail_marker_positive(void) {}
+void fail_marker_negative(void) {}
+void fail_marker_detected(void) {}
+
+// Those functions can be called from within Wasm after registration
+void host_fail_start_trace(wasm_exec_env_t exec_env) {
+  fail_start_trace();
+}
+void host_fail_stop_trace(wasm_exec_env_t exec_env) {
+  fail_stop_trace();
+}
+void host_fail_marker_positive(wasm_exec_env_t exec_env) {
+  fail_marker_positive();
+}
+void host_fail_marker_negative(wasm_exec_env_t exec_env) {
+  fail_marker_negative();
+}
+void host_fail_marker_detected(wasm_exec_env_t exec_env) {
+  fail_marker_detected();
+}

chapters/05_experiment_setup/listings/workloadstructure.cpp

@@ -0,0 +1,18 @@
+extern "C" EXPORT("wasm_module") int wasm_module(void) {
+  // Workload initialization
+  int x = 0;
+
+  fail_start_trace();
+  // Workload execution
+  x = x + 1;
+  fail_stop_trace();
+
+  // Success condition
+  if (x == 1) {
+    fail_marker_positive();
+    return 0;
+  } else {
+    fail_marker_negative();
+    return 1;
+  }
+}

chapters/0A_compilation_options/0A_00_compilation_options.tex

@@ -0,0 +1,10 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+% \addchap{Compilation Options}\label{ch:compilationoptions}
+\chapter{Compilation Options}\label{ch:compilationoptions}
+
+\end{document}

chapters/0B_results/0B_00_results.tex

@@ -0,0 +1,10 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+% \addchap{Experiment Results}\label{ch:experimentresults}
+\chapter{Experiment Results}\label{ch:experimentresults}
+
+\end{document}

chapters/0C_sanity/0C_00_sanity_checks.tex

@@ -5,9 +5,7 @@
 \begin{document}
 
 % \addchap{Examples}\label{ch:examples}
-\chapter{Examples}\label{ch:examples}
-
-\todo[inline]{Sanity check so everything looks correct}
+\chapter{Sanity Checks}\label{ch:examples}
 
 This is \code{inline code}.
 This is a reference to \Gls{fail}.
@@ -21,25 +19,28 @@ This is a formula: \( \sum\limits_{f=1}^{\infty}\frac{o}{r}\cdot m_{u} + l^{a} \
 This is \textbf{bold text that is slightly bold}, so underwhelming.
 In contrast, \sansbf{this text is very strong}, very cool\footnote{very cool}.
 
-\begin{codeblock}[label=lst:examplelisting]{This is a listing}{C++}
-  \inputminted{cpp}{\subfix{listings/example.cpp}}
-\end{codeblock}
-
 \begin{figure}[H]
   \centering
   \begin{subfigure}[b]{0.85\textwidth}
-    \includesvg[width=1.0\linewidth]{\subfix{figures/example.svg}}
+    \includesvg[width=1.0\linewidth]{figures/example.svg}
   \end{subfigure}
   \caption{This is a figure.}\label{fig:examplefigure}
 \end{figure}
 
-\begin{figure}[H]
+\begin{codeblock}[label=lst:examplelisting]{This is a listing.}{C++}
+  \inputminted{cpp}{listings/example.cpp}
+\end{codeblock}
+
+\begin{table}[H]
   \centering
-  \begin{subfigure}[b]{0.95\textwidth}
-    \includesvg[width=1.0\linewidth]{\subfix{figures/heatmap2.svg}}
-  \end{subfigure}
-  \caption{This is another figure.}\label{fig:exampleheatmap}
-\end{figure}
+  \begin{tabularx}{\textwidth}{lX}
+    Column A & Column B                                                                                                                 \\
+    \midrule
+    This is  & a table where the right column does automatic line breaking, so long cell contents don't exceed the page boundary. Cool. \\
+    This is  & an second row.                                                                                                           \\
+  \end{tabularx}
+  \caption{This is a table.}\label{tab:exampletable}
+\end{table}
 
 \lipsum%
 

glossary.tex

@@ -49,15 +49,34 @@
   text={ANBD-code},
   description={Arithmetic coding scheme protecting against operand, operator and operation errors}
 }
+\newglossaryentry{bochs}{%
+  name={Bochs},
+  description={IA-32 emulator used by \Gls{fail}}
+}
 \newglossaryentry{cored}{%
   name={Combined Redundancy},
   first={Combined Redundancy (CoRed)},
   description={Hardening technique utilizing \Gls{replication} in combination with an \glsdisp{anbcode}{ANB-coded} majority voter},
 }
+\newglossaryentry{farm}{%
+  name={FARM Model},
+  text={FARM},
+  description={Model to specify \Gls{fi} applications by structuring them into four sets: faults (\(F\)), activations (\(A\)), readouts (\(R\)), and measures (\(M\))}
+}
+\newglossaryentry{goldenrun}{%
+  name={Golden Run},
+  text={golden run},
+  description={A recording of a fault-free execution of the program under test}
+}
 \newglossaryentry{iwasm}{%
   name={iWasm},
   description={\Gls{wamr}'s standalone binary that provides a command-line interface to load and execute \Gls{wasm} modules using \Gls{vmcore}}
 }
+\newglossaryentry{pilot}{%
+  name={Pilot},
+  text={pilot},
+  description={A single \Gls{fi} experiment representing an equivalence class of experiments with the same outcome}
+}
 \newglossaryentry{replication}{%
   name={Replication},
   text={replication},
@@ -68,6 +87,6 @@
   description={\Gls{wamr}'s runtime libraries for \Gls{wasm} module loading and execution}
 }
 \newglossaryentry{wamrc}{%
-  name={WamrC},
+  name={WAMR-C},
   description={\Gls{wamr}'s \gls{aot} compiler for \Gls{wasm}}
 }

plot_wordcounts.R

@@ -0,0 +1,84 @@
+#!/usr/bin/env Rscript
+# Usage: Rscript plot_wordcounts.R [tick_days] [input.csv] [output.svg]
+# By default, label every seven days, independently of the data points.
+
+library(ggplot2)
+
+args <- commandArgs(trailingOnly = TRUE)
+if (length(args) > 3L) {
+  stop("Usage: Rscript plot_wordcounts.R [tick_days] [input.csv] [output.svg]")
+}
+tick_days <- if (length(args) >= 1L) {
+  as.numeric(args[1])
+} else {
+  7
+}
+
+script_arg <- grep("^--file=", commandArgs(), value = TRUE)[1]
+script_dir <- dirname(normalizePath(sub("^--file=", "", script_arg)))
+input <- if (length(args) >= 2L) {
+  args[2]
+} else {
+  file.path(script_dir, "wordcounts.csv")
+}
+output <- if (length(args) >= 3L) {
+  args[3]
+} else {
+  file.path(script_dir, "wordcounts.svg")
+}
+
+counts <- read.csv(input, colClasses = "character")
+
+timezone <- Sys.getenv("TZ", unset = "Europe/Berlin")
+if (!nzchar(timezone)) {
+  timezone <- "Europe/Berlin"
+}
+normalized <- sub("([+-][0-9]{2}):([0-9]{2})$", "\\1\\2", counts$date)
+counts$timestamp <- as.POSIXct(
+  normalized,
+  format = "%Y-%m-%dT%H:%M:%S%z",
+  tz = timezone
+)
+date_only <- grepl("^[0-9]{4}-[0-9]{2}-[0-9]{2}$", counts$date)
+counts$timestamp[date_only] <- as.POSIXct(
+  counts$date[date_only],
+  format = "%Y-%m-%d",
+  tz = timezone
+)
+counts$wordcount <- as.numeric(counts$wordcount)
+counts <- counts[order(counts$timestamp), ]
+
+# Fixed time intervals
+start <- as.POSIXct(
+  format(min(counts$timestamp), "%Y-%m-%d", tz = timezone),
+  tz = timezone
+)
+interval <- tick_days * 86400
+span <- as.numeric(difftime(max(counts$timestamp), start, units = "secs"))
+ticks <- start + seq(0, max(1, ceiling(span / interval))) * interval
+
+plot <- ggplot(counts, aes(x = timestamp, y = wordcount)) +
+  scale_x_datetime(
+    breaks = ticks,
+    limits = range(ticks),
+    date_labels = "%Y-%m-%d",
+    timezone = timezone,
+    minor_breaks = NULL
+  ) +
+  scale_y_continuous(labels = scales::label_comma()) +
+  labs(
+    title = "Thesis Word Count",
+    x = "Date",
+    y = "Words"
+  ) +
+  theme_minimal(base_size = 12) +
+  theme(
+    axis.text.x = element_text(angle = 45, hjust = 1),
+    panel.grid.minor = element_blank()
+  )
+if (nrow(counts) > 1L) {
+  plot <- plot + geom_line(linewidth = 0.5)
+}
+
+ggsave(output, plot, width = 10, height = 5, dpi = 180, bg = "white")
+message("Saved ", output)

preamble.tex

@@ -23,7 +23,7 @@
 
 % Tables
 \usepackage{booktabs}
-% \usepackage{tabularx}
+\usepackage{tabularx}
 % \usepackage{tablefootnote}
 % \usepackage{makecell}
 % \usepackage{color,colortbl}
@@ -194,6 +194,7 @@
     \frontmatter%
     \pagestyle{plain}
     \pagenumbering{Roman}
+    \input{abstract}
     \tableofcontents%
     \cleardoublepage%
 
@@ -275,7 +276,7 @@
   nobeforeafter,
   boxrule=0pt,
   colback=languagebg,
-  arc=2pt,
+  arc=3pt,
   boxsep=0pt,
   left=3pt,
   right=3pt,
@@ -300,11 +301,11 @@
       top color=codebg,
       bottom color=codebg
     },
-  boxrule=0.5pt, % Border width
-  arc=2pt, % Rounded corners
+  boxrule=1pt, % Border width
+  arc=4pt, % Rounded corners
   width=\linewidth,
   fonttitle=\normalsize,
-  adjusted title=\textbf{\texttt{\thetcbcounter}\hspace{0.75em}\texttt{#2}},
+  adjusted title=\textbf{\texttt{Listing \thetcbcounter.}\hspace{0.75em}\texttt{#2}},
   list entry=\thetcbcounter\quad\texttt{#2}, % List of listings
   list text={\hspace*{1ex}#2}, % Chapter - Caption spacing in list of listings
   after title={% Display used language
@@ -319,7 +320,8 @@
   top=1mm,
   bottom=1mm,
   right=0mm,
-  left=5mm,
+  left=4.6mm,
+  drop shadow=titlebg!50!white,
   #1 % Extra args, e.g. a label
 }
 
@@ -341,20 +343,77 @@
 }
 
 % A box surrounding inline code-type text
-\newtcbox{\codehighlight}{nobeforeafter,boxrule=.5pt,colback=black!5,colframe=black!35,
-  arc=2pt,boxsep=0pt,left=2pt,right=2pt,top=2pt,bottom=2pt, tcbox raise base}
+\newtcbox{\codehighlight}{
+  nobeforeafter,
+  boxrule=.5pt,
+  colback=black!5,
+  colframe=black!35,
+  arc=2pt,
+  boxsep=0pt,
+  left=2pt,
+  right=2pt,
+  top=2pt,
+  bottom=2pt,
+  tcbox raise base
+}
 
 % Quickly place inline codehighlight boxes
 \newcommand{\code}[1]{\codehighlight{\texttt{\small{#1}}}}
 
-% A box surrounding figures
-\tcolorboxenvironment{figure}{
-  enhanced,
-  float=htb,
-  arc=2pt,
-  boxrule=0.5pt,
-  colframe=black,
-  colback=white,
-  before skip=\intextsep,
-  after skip=\intextsep,
+% Boxes for figures and tables use the same title bar as code listings.
+% Existing \caption and \label commands still work.
+\tcbset{captionbox/.style={
+      enhanced,
+      arc=4pt,
+      boxrule=1pt,
+      boxsep=1mm,
+      left=4mm, right=4mm,
+      lefttitle=4mm, righttitle=4mm,
+      colbacktitle=titlebg,
+      coltitle=titlecolor,
+      colframe=titlebg,
+      colback=white,
+      fonttitle=\normalsize\bfseries\ttfamily,
+      drop shadow=titlebg!50!white,
+    }}
+
+% Captions
+\captionsetup[captionbox]{
+  font={normalsize,bf,tt,color=titlecolor},
+  labelfont={bf,tt},
+  labelsep=quad,
+  margin=0pt,
+  justification=raggedright,
+  singlelinecheck=false,
+  skip=0pt,
 }
+
+% Subcaptions
+\captionsetup[sub]{
+  font={normalfont,small,color=black},
+  labelfont={normalfont,bf},
+}
+\makeatletter
+\newcommand{\fs@captionbox}{%
+  \fs@plain%
+  \def\@fs@pre{%
+    \begin{tcolorbox}[captionbox,title={\unvbox\@floatcapt}]
+      }
+      \def\@fs@post{\end{tcolorbox}}
+  \def\@fs@mid{}
+  \let\@fs@iftopcapt\iffalse%
+}
+\makeatother
+
+% Reserve padding
+\newcommand{\captionboxwidth}{%
+  \hsize=\dimexpr\linewidth-10mm-1pt\relax
+  \linewidth=\hsize
+  \textwidth=\hsize
+}
+\floatstyle{captionbox}
+\restylefloat{figure}
+\restylefloat{table}
+\floatevery{figure}{\captionboxwidth}
+\floatevery{table}{\captionboxwidth}
+\floatstyle{plain}

thesis.tex

@@ -6,40 +6,65 @@
 
 \begin{document}
 
-% TODO: Double check the autofilled Zotero references
+\addchap*{General ToDo}
+\todo[inline]{Double check the autofilled Zotero references}
+\todo[inline]{Inconsistent usage of the words benchmark and experiment}
+\todo[inline]{Glossary entries are all over the place, some things don't need to be linked}
+\todo[inline]{Too many footnotes, some are unnecessary}
+\todo[inline]{Make fault-injection and fault injection consistent}
 
-\subfile{chapters/00_introduction/00_00_introduction.tex}
+\subfile{chapters/01_introduction/01_00_introduction.tex}
 \cleardoublepage%
 
-\subfile{chapters/01_related_work/01_00_related_work.tex}
+\subfile{chapters/02_background/02_00_background.tex}
+\subfile{chapters/02_background/02_01_fault_chain.tex}
+\subfile{chapters/02_background/02_02_wasm.tex}
+\subfile{chapters/02_background/02_03_wamr.tex}
+\subfile{chapters/02_background/02_04_fail.tex}
+\subfile{chapters/02_background/02_05_software_based_hardening.tex}
 \cleardoublepage%
 
-\subfile{chapters/02_methodology/02_00_methodology.tex}
+\subfile{chapters/03_related_work/03_00_related_work.tex}
 \cleardoublepage%
 
-\subfile{chapters/03_background/03_00_background.tex}
-\subfile{chapters/03_background/03_01_wasm.tex}
-\subfile{chapters/03_background/03_02_wamr.tex}
-\subfile{chapters/03_background/03_03_fail.tex}
-% TODO: Write about faults/errors/fault chain?
+\subfile{chapters/04_methodology/04_00_methodology.tex}
+\subfile{chapters/04_methodology/04_01_experimental_design.tex}
+\subfile{chapters/04_methodology/04_02_farm_model.tex}
+\subfile{chapters/04_methodology/04_03_result_filtering.tex}
+\subfile{chapters/04_methodology/04_04_attribution.tex}
+\subfile{chapters/04_methodology/04_05_reproducibility.tex}
 \cleardoublepage%
 
-\subfile{chapters/04_experiment_setup/04_00_experiment_setup.tex}
+\subfile{chapters/05_experiment_setup/05_00_experiment_setup.tex}
+\subfile{chapters/05_experiment_setup/05_01_execution_environment.tex}
+\subfile{chapters/05_experiment_setup/05_02_wamr_modifications.tex}
+\subfile{chapters/05_experiment_setup/05_03_workload_structure.tex}
+\subfile{chapters/05_experiment_setup/05_04_experiment_variants.tex}
+\subfile{chapters/05_experiment_setup/05_05_controlling_injections.tex}
+\subfile{chapters/05_experiment_setup/05_06_results_filtering.tex}
+\subfile{chapters/05_experiment_setup/05_07_missing_fail_markers.tex}
+\subfile{chapters/05_experiment_setup/05_08_target_programs.tex}
 \cleardoublepage%
 
-\subfile{chapters/05_results/05_00_results.tex}
+\subfile{chapters/06_results/06_00_results.tex}
 \cleardoublepage%
 
-\subfile{chapters/06_discussion/06_00_discussion.tex}
+\subfile{chapters/07_discussion/07_00_discussion.tex}
 \cleardoublepage%
 
-\subfile{chapters/07_conclusion/07_00_conclusion.tex}
+\subfile{chapters/08_conclusion/08_00_conclusion.tex}
 \cleardoublepage%
 
 \appendix
 % \pagenumbering{Roman}
 
-\subfile{chapters/examples/examples.tex}
+\subfile{chapters/0A_compilation_options/0A_00_compilation_options.tex}
+\cleardoublepage%
+
+\subfile{chapters/0B_results/0B_00_results.tex}
+\cleardoublepage%
+
+\subfile{chapters/0C_sanity/0C_00_sanity_checks.tex}
 \cleardoublepage%
 
 \end{document}

titlepage.tex

@@ -15,7 +15,7 @@
 
   \begin{center}
 
-    \includegraphics[width=6cm]{tud_logo_rgb.jpg}
+    \includegraphics[width=8cm]{tud_logo_rgb.jpg}
 
     \vspace{0.75cm}
 

wordcount.sh

@@ -0,0 +1,13 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Relative paths
+cd -- "$(dirname -- "${BASH_SOURCE[0]}")"
+
+wordcount=$(pdftotext .out/thesis.pdf - | wc -w)
+timestamp=$(date +%FT%T%:z)
+
+if [[ ! -s wordcounts.csv ]]; then
+    printf 'date,wordcount\n' >> wordcounts.csv
+fi
+printf '%s,%s\n' "$timestamp" "${wordcount//[[:space:]]/}" >> wordcounts.csv

wordcounts.csv

@@ -0,0 +1,150 @@
+date,wordcount
+2026-06-23T12:00:00+02:00,496
+2026-06-30T12:00:00+02:00,2210
+2026-07-01T10:00:00+02:00,3745
+2026-07-01T12:00:00+02:00,4587
+2026-07-02T12:00:00+02:00,5058
+2026-07-05T12:00:00+02:00,5783
+2026-07-07T12:00:00+02:00,5538
+2026-09-11T11:24:33+02:00,8603
+2026-09-11T11:26:13+02:00,8603
+2026-09-11T11:31:20+02:00,8596
+2026-09-11T11:42:48+02:00,8727
+2026-09-11T11:43:08+02:00,8727
+2026-09-11T11:47:47+02:00,8746
+2026-09-11T12:01:42+02:00,8812
+2026-09-11T12:03:40+02:00,8860
+2026-09-11T12:07:01+02:00,8887
+2026-09-11T12:07:14+02:00,8888
+2026-09-11T12:07:31+02:00,8884
+2026-09-11T12:08:51+02:00,8892
+2026-09-11T12:09:39+02:00,8894
+2026-09-11T12:11:27+02:00,8913
+2026-09-11T12:12:29+02:00,8924
+2026-09-11T12:13:22+02:00,8920
+2026-09-11T12:13:42+02:00,8927
+2026-09-11T12:14:31+02:00,8927
+2026-09-11T12:15:46+02:00,8946
+2026-09-11T12:20:47+02:00,9070
+2026-09-11T12:23:46+02:00,9099
+2026-09-11T12:24:02+02:00,9102
+2026-09-11T12:24:42+02:00,9109
+2026-09-11T12:26:15+02:00,9109
+2026-09-11T12:26:25+02:00,9109
+2026-09-11T12:26:38+02:00,9109
+2026-09-11T12:30:20+02:00,9137
+2026-09-11T12:30:35+02:00,9137
+2026-09-11T12:31:24+02:00,9115
+2026-09-11T12:34:33+02:00,9124
+2026-09-11T12:36:17+02:00,9129
+2026-09-11T12:36:44+02:00,9113
+2026-09-11T12:42:09+02:00,9167
+2026-09-11T12:42:35+02:00,9167
+2026-09-11T12:53:02+02:00,9235
+2026-09-11T12:53:46+02:00,9234
+2026-09-11T12:54:27+02:00,9235
+2026-09-11T12:55:42+02:00,9235
+2026-09-11T12:56:42+02:00,9250
+2026-09-11T12:58:59+02:00,9379
+2026-09-11T12:59:54+02:00,9389
+2026-09-11T13:00:27+02:00,9389
+2026-09-11T13:00:43+02:00,9389
+2026-09-11T13:04:39+02:00,9427
+2026-09-11T13:04:55+02:00,9485
+2026-09-11T13:06:04+02:00,9488
+2026-09-11T13:07:00+02:00,9496
+2026-09-11T13:09:11+02:00,9494
+2026-09-11T13:10:20+02:00,9504
+2026-09-11T13:10:37+02:00,9509
+2026-09-11T13:10:45+02:00,9508
+2026-09-11T13:12:12+02:00,9510
+2026-09-11T13:17:28+02:00,9639
+2026-09-11T13:20:11+02:00,9686
+2026-09-11T13:20:35+02:00,9686
+2026-09-11T13:30:23+02:00,9704
+2026-09-11T13:31:28+02:00,9713
+2026-09-11T13:34:02+02:00,9740
+2026-09-11T13:34:11+02:00,9738
+2026-09-11T13:36:51+02:00,9771
+2026-09-11T13:37:45+02:00,9768
+2026-09-11T13:39:55+02:00,9778
+2026-09-11T13:40:19+02:00,9779
+2026-09-11T13:40:55+02:00,9779
+2026-09-11T13:41:22+02:00,9779
+2026-09-11T13:44:40+02:00,9800
+2026-09-11T13:44:47+02:00,9801
+2026-09-11T13:45:09+02:00,9801
+2026-09-11T13:47:18+02:00,9801
+2026-09-11T13:47:55+02:00,9801
+2026-09-11T13:49:17+02:00,9769
+2026-09-11T13:50:04+02:00,9906
+2026-09-11T16:31:06+02:00,9952
+2026-09-11T16:32:21+02:00,9967
+2026-09-11T16:40:24+02:00,10123
+2026-09-11T16:40:56+02:00,10123
+2026-09-11T16:41:08+02:00,10127
+2026-09-11T16:43:54+02:00,10166
+2026-09-11T16:44:23+02:00,10170
+2026-09-11T16:44:54+02:00,10170
+2026-09-11T16:45:46+02:00,10170
+2026-09-11T16:46:07+02:00,10170
+2026-09-12T11:57:09+02:00,10170
+2026-09-12T12:05:20+02:00,10170
+2026-09-12T12:05:36+02:00,10169
+2026-09-12T13:09:05+02:00,10172
+2026-09-12T13:10:19+02:00,10188
+2026-09-12T13:10:53+02:00,10197
+2026-09-12T13:12:10+02:00,10201
+2026-09-12T13:14:00+02:00,10242
+2026-09-12T13:14:23+02:00,10228
+2026-09-12T13:15:51+02:00,10227
+2026-09-12T13:17:15+02:00,10230
+2026-09-12T13:18:49+02:00,10224
+2026-09-12T13:25:07+02:00,10225
+2026-09-12T13:26:35+02:00,10236
+2026-09-12T13:27:44+02:00,10236
+2026-09-12T13:28:26+02:00,10237
+2026-09-12T13:58:35+02:00,10237
+2026-09-12T14:31:54+02:00,10252
+2026-09-12T14:32:24+02:00,10254
+2026-09-12T15:01:16+02:00,10317
+2026-09-12T15:01:42+02:00,10317
+2026-09-12T15:01:56+02:00,10315
+2026-09-12T15:02:10+02:00,10315
+2026-09-12T15:02:50+02:00,10315
+2026-09-12T15:06:17+02:00,10324
+2026-09-12T15:11:33+02:00,10397
+2026-09-12T15:15:52+02:00,10400
+2026-09-12T15:19:31+02:00,10407
+2026-09-12T15:22:01+02:00,10476
+2026-09-12T15:22:34+02:00,10510
+2026-09-13T21:29:35+02:00,10508
+2026-09-13T21:31:15+02:00,10508
+2026-09-13T21:31:37+02:00,10508
+2026-09-13T21:32:35+02:00,10508
+2026-09-13T21:32:48+02:00,10508
+2026-09-13T21:33:14+02:00,10508
+2026-09-13T21:33:28+02:00,10508
+2026-09-13T21:33:53+02:00,10508
+2026-09-13T21:34:07+02:00,10508
+2026-09-13T21:34:33+02:00,10508
+2026-09-13T21:35:07+02:00,10505
+2026-09-13T21:35:41+02:00,10505
+2026-09-13T21:36:03+02:00,10506
+2026-09-13T21:36:30+02:00,10507
+2026-09-13T21:38:40+02:00,10507
+2026-09-13T21:39:17+02:00,10539
+2026-09-13T21:40:15+02:00,10539
+2026-09-13T21:42:13+02:00,10566
+2026-09-13T21:43:56+02:00,10559
+2026-09-13T21:47:12+02:00,10689
+2026-09-13T21:48:44+02:00,10536
+2026-09-13T21:49:32+02:00,10535
+2026-09-13T21:50:06+02:00,10537
+2026-09-13T21:50:29+02:00,10692
+2026-09-13T21:50:56+02:00,10690
+2026-09-13T21:51:54+02:00,10691
+2026-09-13T21:52:19+02:00,10693
+2026-09-13T21:54:39+02:00,10732
+2026-09-13T21:55:57+02:00,10738
+2026-09-13T21:56:50+02:00,10740

zotero.bib

@@ -13,7 +13,7 @@
   author = {Arlat, J. and Aguera, M. and Amat, L. and Crouzet, Y. and Fabre, J.-C. and Laprie, J.-C. and Martins, E. and Powell, D.},
   date = {1990-02},
   journaltitle = {IEEE Transactions on Software Engineering},
-  shortjournal = {IIEEE Trans. Software Eng.},
+  shortjournal = {IEEE Trans. Softw. Eng.},
   volume = {16},
   number = {2},
   pages = {166--182},
@@ -66,7 +66,7 @@
   author = {Forin, P.},
   date = {1990-09},
   journaltitle = {IFAC Proceedings Volumes},
-  shortjournal = {IFAC Proceedings Volumes},
+  shortjournal = {IFAC Proc. Vol.},
   volume = {23},
   number = {2},
   pages = {79--84},
@@ -96,6 +96,24 @@
   file = {/home/christoph/Notes/Zotero/storage/WI2QDM9X/Goloubeva et al. - 2003 - Soft-error detection using control flow assertions.pdf}
 }
 
+@inproceedings{guthoffCombiningSoftwareimplementedSimulationbased1995,
+  title = {Combining Software-Implemented and Simulation-Based Fault Injection into a Single Fault Injection Method},
+  booktitle = {Twenty-{{Fifth International Symposium}} on {{Fault-Tolerant Computing}}. {{Digest}} of {{Papers}}},
+  author = {Guthoff, J. and Sieh, V.},
+  date = {1995},
+  pages = {196--206},
+  publisher = {IEEE Comput. Soc. Press},
+  location = {Pasadena, CA, USA},
+  doi = {10.1109/FTCS.1995.466978},
+  url = {http://ieeexplore.ieee.org/document/466978/},
+  urldate = {2026-09-10},
+  abstract = {Fault/error injection has emerged as a valuable meansfor evaluating the dependubility of a system. In particular, sopware-based techniques, which can be described as software-implemented and sitnulation-based techniques, have become verypopular because of the relative simplicity of injecting faults. Afrer discussing the advantages and drawbacks of these techniques, two approaches are introduced which try to overcome crucial problems when using software-based fault injection techniques. The first one improves the accuracy of software-implemented fault injection experiments. The second one offers detailed insights into the system dynamics in the presence of faults. Withthis knowledge, the number offault injections, U major concern in simulation-based.fault injection, can be sign\$cantly reduced. These approaches can be joined together offering accuracy offault injection results us well as transparency of the system dynamics in the presence of faults. A case study, in which the defacto dependabilityproperties of a standard component, a Motorola MC88100 RISC processor, are evaluated shows that.},
+  eventtitle = {Twenty-{{Fifth International Symposium}} on {{Fault-Tolerant Computing}}. {{Digest}} of {{Papers}}},
+  isbn = {978-0-8186-7079-4},
+  langid = {english},
+  file = {/home/christoph/Notes/Zotero/storage/4AHIQGKC/Guthoff and Sieh - 1995 - Combining software-implemented and simulation-based fault injection into a single fault injection me.pdf}
+}
+
 @article{hammingErrorDetectingError,
   title = {Error Detecting and Error Correcting Codes},
   author = {Hamming, Richard W},
@@ -109,7 +127,7 @@
   author = {Hoffmann, Martin and Ulbrich, Peter and Dietrich, Christian and Schirmeier, Horst and Lohmann, Daniel and Schröder-Preikschat, Wolfgang},
   date = {2016-03},
   journaltitle = {Software Quality Journal},
-  shortjournal = {Software Qual J},
+  shortjournal = {Softw. Qual. J.},
   volume = {24},
   number = {1},
   pages = {87--113},
@@ -173,7 +191,7 @@
   author = {Poledna, Stefan},
   date = {1994-05},
   journaltitle = {Real-Time Systems},
-  shortjournal = {Real-Time Syst},
+  shortjournal = {Real-Time Syst.},
   volume = {6},
   number = {3},
   pages = {289--316},
@@ -246,6 +264,24 @@
   file = {/home/christoph/Notes/Zotero/storage/7BXMSTFW/Hardware_Error_Detection_Using_AN_Codes.pdf}
 }
 
+@inproceedings{schirmeierAvoidingPitfallsFaultInjection2015,
+  title = {Avoiding {{Pitfalls}} in {{Fault-Injection Based Comparison}} of {{Program Susceptibility}} to {{Soft Errors}}},
+  booktitle = {2015 45th {{Annual IEEE}}/{{IFIP International Conference}} on {{Dependable Systems}} and {{Networks}}},
+  author = {Schirmeier, Horst and Borchert, Christoph and Spinczyk, Olaf},
+  date = {2015-06},
+  pages = {319--330},
+  publisher = {IEEE},
+  location = {Rio de Janeiro, Brazil},
+  doi = {10.1109/DSN.2015.44},
+  url = {https://ieeexplore.ieee.org/document/7266861},
+  urldate = {2026-08-18},
+  abstract = {Since the first identification of physical causes for soft errors in memory circuits, fault injection (FI) has grown into a standard methodology to assess the fault resilience of computer systems. A variety of FI techniques trying to mimic these physical causes has been developed to measure and compare program susceptibility to soft errors.},
+  eventtitle = {2015 45th {{Annual IEEE}}/{{IFIP International Conference}} on {{Dependable Systems}} and {{Networks}} ({{DSN}})},
+  isbn = {978-1-4799-8629-3},
+  langid = {english},
+  file = {/home/christoph/Notes/Zotero/storage/Z5YD828W/Schirmeier et al. - 2015 - Avoiding Pitfalls in Fault-Injection Based Comparison of Program Susceptibility to Soft Errors.pdf}
+}
+
 @incollection{schirmeierDependabilityAspectsConfigurable2021,
   title = {Dependability {{Aspects}} in {{Configurable Embedded Operating Systems}}},
   booktitle = {Dependable {{Embedded Systems}}},
@@ -355,13 +391,30 @@
   file = {/home/christoph/Notes/Zotero/storage/82VVGKJV/Sletten - 2021 - WebAssembly the definitive guide safe, fast, and portable code.pdf}
 }
 
+@inproceedings{smithMethodDetermineEquivalent1995,
+  title = {A Method to Determine Equivalent Fault Classes for Permanent and Transient Faults},
+  booktitle = {Annual {{Reliability}} and {{Maintainability Symposium}} 1995 {{Proceedings}}},
+  author = {Smith, D.T. and Johnson, B.W. and Profeta, J.A. and Bozzolo, D.G.},
+  date = {1995},
+  pages = {418--424},
+  publisher = {IEEE},
+  location = {Washington, DC, USA},
+  doi = {10.1109/RAMS.1995.513278},
+  url = {http://ieeexplore.ieee.org/document/513278/},
+  urldate = {2026-09-10},
+  abstract = {CONCLUSIONS The expanding size and complexity of dependable computing systems has significantly incrcased their cost while complicating the estimation of system dependability attributes such as fault coverage and latency.The increasing requirements of safety and reliability for a dependable system, however, have made the evaluation of dependability attributes a crucial task. One approach to performing such an evaluation is through fault injection. The development of a method which enumerates the equivalent faults associated with a given fault injection experiment would significantly reduce the amount of effort required to measure dependability parameters to the desired degree of accuracy and confidence.This research has developed a new method for detcrmining the set of equivalent faults for either a permanent or transient fault injection experiment. The primary objective of the research effort was to expand the data obtained from a single fault injection experiment into a set of data associated with the equivalent fault set. The end result is an automated method for determining equivalent faults from a set of fault injection experiments. The expanded equivalent data sets are then evaluated to determine dependability parameter estimates for fault coverage and error latency.},
+  eventtitle = {Annual {{Reliability}} and {{Maintainability Symposium}} 1995},
+  isbn = {978-0-7803-2470-1},
+  langid = {english},
+  file = {/home/christoph/Notes/Zotero/storage/IGW4FNVP/Smith et al. - 1995 - A method to determine equivalent fault classes for permanent and transient faults.pdf}
+}
+
 @article{soloukiDependabilityEmbeddedSystems2024,
   title = {Dependability in {{Embedded Systems}}: {{A Survey}} of {{Fault Tolerance Methods}} and {{Software-Based Mitigation Techniques}}},
   shorttitle = {Dependability in {{Embedded Systems}}},
   author = {Solouki, Mohammadreza Amel and Angizi, Shaahin and Violante, Massimo},
   date = {2024},
   journaltitle = {IEEE Access},
-  shortjournal = {IEEE Access},
   volume = {12},
   pages = {180939--180967},
   issn = {2169-3536},