Reorder chapters

chapters/01_introduction/01_00_introduction.tex

@@ -4,6 +4,8 @@
 
 \begin{document}
 
+\todo[inline]{Inconsistent usage of the words benchmark and experiment}
+
 \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.
@@ -14,20 +16,20 @@ The interpreter and \gls{aot} execution modes of \Gls{wamr} are compared under f
 
 \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.
 
@@ -40,19 +42,19 @@ The central objective is to analyze the effects of transient faults on \Gls{wamr
 \paragraph{How do transient hardware faults affect the correctness of programs executed in \Gls{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?}
 
 \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 \gls{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.
@@ -68,14 +70,14 @@ 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.
+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.
 
@@ -83,7 +85,7 @@ The hardening potential of this approach is compared to the hardening of the int
 
 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/04_experiment_setup/04_00_experiment_setup.tex

@@ -1,64 +0,0 @@
-%! TeX program = lualatex
-%! TeX root = ../../thesis.tex
-\documentclass[../../thesis.tex]{subfiles}
-
-\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?
-  \item Optimization theory
-        \begin{itemize}
-          \item Does the target program contain the expected instructions?
-          \item Does FAIL* treat the variables as not live? (volatile, fail\_stop\_trace(sum))
-          \item Trying more complex programs, as -O0 always writes intermediate results to memory
-          \item Swap fail\_marker\_positive and fail\_marker\_negative
-        \end{itemize}
-  \item Does the pruner clear those injections for some reason?
-  \item Does the disassembler not disassemble the .text subsections?
-  \item Is the TracingPlugin broken? (GDB -> No, but FAIL* doesn't trace register accesses)
-  \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_00_experiment_setup.tex

@@ -0,0 +1,84 @@
+%! TeX program = lualatex
+%! TeX root = ../../thesis.tex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\chapter{Experiment Setup}\label{ch:experimentsetup}
+
+\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{sec:wasmhostprogram}), \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 be functional.
+  \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}.
+
+\section{\Gls{wamr} Modifications}\label{sec:wamrmodifications}
+\begin{itemize}
+  \item WAMR baremetal platform
+  \item WAMR exception handler marker?
+\end{itemize}
+
+\section{Wasm Host Program}\label{sec:wasmhostprogram}
+\begin{itemize}
+  \item WAMR setup
+  \item WAMR memory allocators
+  \item Calling \code{FAIL\_MARKER}s (native functions)
+\end{itemize}
+
+\section{Experiment Variants}\label{sec:experimenttypes}
+\begin{itemize}
+  \item C only
+  \item WAMR AOT
+  \item WAMR interpreter
+\end{itemize}
+
+\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}
+
+\section{Controlling What Data Gets Extracted From The Experiments}
+\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}
+
+\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?
+  \item Optimization theory
+        \begin{itemize}
+          \item Does the target program contain the expected instructions?
+          \item Does FAIL* treat the variables as not live? (volatile, fail\_stop\_trace(sum))
+          \item Trying more complex programs, as -O0 always writes intermediate results to memory
+          \item Swap fail\_marker\_positive and fail\_marker\_negative
+        \end{itemize}
+  \item Does the pruner clear those injections for some reason?
+  \item Does the disassembler not disassemble the .text subsections?
+  \item Is the TracingPlugin broken? (GDB -> No, but FAIL* doesn't trace register accesses)
+  \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}