Reorder chapters + put abstract into frontmatter

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?}