Reorder chapters + put abstract into frontmatter

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,15 +6,7 @@
 
 \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 \Gls{sdc} or  \Glspl{due}.
+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.
 
@@ -37,14 +29,14 @@ 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 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 precompiled to native code.
@@ -52,14 +44,14 @@ Additionally, the distribution of faults is examined to determine particularly v
 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 application-level 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.
@@ -76,7 +68,7 @@ The evaluation focuses on the feasibility of hardening the \Gls{wamr} runtime, i
 \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.
+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?}

chapters/02_background/02_00_background.tex

@@ -6,8 +6,4 @@
 
 \chapter{Background}\label{ch:background}
 
-\begin{enumerate}
-  \item Fault -> Error -> Failure (fault chain terminology). Also SDC/DUE differentiation
-\end{enumerate}
-
 \end{document}

chapters/02_background/02_02_wasm.tex

@@ -30,11 +30,11 @@ The module uses two pages of \code{memory} and defines the stack pointer as a mu
 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.
+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}.
 
-During runtime, \Gls{wasm} provides memory safety, control flow integrity and independent execution (sandboxing)\footnote{\url[2026-07-01]{https://webassembly.org/docs/security/}}.
+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.

chapters/02_background/02_03_wamr.tex

@@ -22,7 +22,7 @@ The last component is \textquote{\gls{wamrc}}, a compiler transforming \code{.wa
   \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.
+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.

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_02_farm_model.tex

@@ -40,7 +40,8 @@ The effects of injected faults are later evaluated through the readouts describe
 
 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.
+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}]\)).
@@ -97,6 +98,6 @@ where \(\mathbf{1}\{o_{c,b} = o\}\) is the indicator function, which equals one
 \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 executaion duration and memory footprint.
+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

@@ -6,7 +6,7 @@
 
 \section{Result Filtering}\label{sec:resultfiltering}
 
-To analyse specific facets of a system under fault-injection, parts of the observed outcomes and generated measures can be excluded from evaluations.
+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.
 

chapters/05_experiment_setup/05_00_experiment_setup.tex

@@ -6,4 +6,6 @@
 
 \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

@@ -15,7 +15,7 @@ Instead, experiments are cross-compiled to freestanding executables using \code{
 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, they do not need to implement functional behavior.
+  \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}

chapters/05_experiment_setup/05_03_workload_structure.tex

@@ -9,7 +9,7 @@
 \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.
+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++}
@@ -33,7 +33,7 @@ The \code{MAIN} and \code{RET} macros expand according to the appropriate entry
 
 \subsection{Wasm Host and WAMR Setup}\label{ssec:wasmhostandwamrsetup}
 
-The host program for \Gls{wasm} experiment variants needs to do a lot of 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}}.
+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}
 
@@ -42,7 +42,7 @@ Relevant for this thesis are \code{Alloc\_With\_Pool} and \code{Alloc\_With\_All
 \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}
+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}
@@ -74,7 +74,7 @@ This indirection happens implicitly, on the application level no special steps n
 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 entireties of any other marker calls within the traced region are susceptible to faults unintended in the experiment design: the source code instrumentation should only steer the fault-injection process, not interact with the workload execution itself.
+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}

glossary.tex

@@ -87,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}}
 }

preamble.tex

@@ -194,6 +194,7 @@
     \frontmatter%
     \pagestyle{plain}
     \pagenumbering{Roman}
+    \input{abstract}
     \tableofcontents%
     \cleardoublepage%
 

thesis.tex

@@ -6,22 +6,25 @@
 
 \begin{document}
 
+\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/01_introduction/01_00_introduction.tex}
 \cleardoublepage%
 
-\subfile{chapters/02_related_work/02_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/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_fault_chain.tex}
-\subfile{chapters/03_background/03_04_fail.tex}
+\subfile{chapters/03_related_work/03_00_related_work.tex}
 \cleardoublepage%
 
 \subfile{chapters/04_methodology/04_00_methodology.tex}

wordcounts.csv

@@ -118,3 +118,33 @@ date,wordcount
 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