WIP: background section

chapters/03_background/03_01_wasm.tex

@@ -3,9 +3,10 @@
 
 \begin{document}
 
-\section{\Glsdesc*{wasm}}\label{sec:wasm}
+\section{WebAssembly}\label{sec:wasm}
 
 The open \Acrfull{wasm} standard defines a portable virtual instruction set architecture, binary code format and text format for execution inside a virtual (stack) machine~\autocite{wasm3spec}.
+\Gls{wasm} instructions operate on an operand stack instead of registers: values are pushed and consumed through stack operations, similar to Java's virtual machine.
 It is developed and maintained by the World Wide Web Consortium (W3C)\footnote{\url[2026-07-01]{https://w3.org/}} to support high-performance applications in web-based environments.
 While the initial implementations of \Gls{wasm} runtime environments were confined to web browsers\footnote{In 2016, experimental \Gls{wasm} runtimes were implemented in Firefox, Google Chrome and Microsoft Edge: \url[2026-07-01]{https://hacks.mozilla.org/2016/03/a-webassembly-milestone/}}, \Gls{wasm} does not make any web-specific assumptions, so many different standalone runtimes like \textquote{Wasmtime}\footnote{\url[2026-07-01]{https://github.com/bytecodealliance/wasmtime/}} or the \Acrfull{wamr} (see \autoref{sec:wamr}) have emerged since.
 
@@ -20,12 +21,21 @@ Both formats are equivalent, they represent the same underlying content differen
   \inputminted{wat}{\subfix{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.
+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.
+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.
-The binaries mainly consist of \textit{values}, \textit{instructions}, \textit{functions} and \textit{memory}, bundled into \textit{modules}.
+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}.
 
 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.
+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\footnote{\url[2026-07-01]{https://clang.llvm.org/docs/ControlFlowIntegrity.html}}.
 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.

chapters/03_background/03_02_wamr.tex

@@ -3,11 +3,26 @@
 
 \begin{document}
 
-\section{\Glsdesc*{wamr}}\label{sec:wamr}
+\section{WebAssembly Micro Runtime}\label{sec:wamr}
 
+\Acrfull{wamr}~\autocite{wamr} is a lightweight standalone \Gls{wasm} runtime by the \textquote{Bytecode Alliance}\footnote{\url[2026-07-02]{https://bytecodealliance.org/}}, designed for embedded devices.
+
+\Gls{wamr} includes three main components: The runtime libraries required to load and execute \Gls{wasm} modules (the decode, validate, instantiate, invoke process mentioned in \autoref{sec:wasm}) are called \textquote{\Gls{vmcore}}.
+\Gls{vmcore} can be embedded in C/C++ host applications.
+A standalone version of \Gls{vmcore} is provided by the \textquote{\gls{iwasm}} program.
+It acts as the host application and allows running \code{.wasm} files directly from the command-line.
+The last component is \textquote{\gls{wamrc}}, a compiler transforming \code{.wasm} to \Gls{aot} compiled native code, necessary when not using one of \Gls{wamr}'s interpreter implementations.
+
+\Gls{wasm} modules can be executed in five different running modes using \Gls{vmcore}\footnote{\url[2026-07-01]{https://bytecodealliance.github.io/wamr.dev/blog/introduction-to-wamr-running-modes/}}:
 \begin{itemize}
-  \item Memory allocators (pool, usage), linear memory, memory usage
-  \item Different interpreters + JiTs + AoT (information + tradeoffs)
+  \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{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.
 \end{itemize}
+In \Gls{aot} mode the \Gls{wasm} module is invoked by jumping into its native code, the interpreted modes follow a traditional opcode fetch, decode, execute loop.
+
+Of those five modes, this thesis is concerned with \Gls{aot} mode and the classic interpreter for analyzability reasons: \Gls{aot} mode is most similar to native execution without the additional \Gls{wasm} layer. The classic interpreter allows a simpler understanding of fault effects than the fast interpreter or \Glspl{jit} as no different code representations are involved.
 
 \end{document}

chapters/03_background/03_03_fail.tex

@@ -3,7 +3,7 @@
 
 \begin{document}
 
-\section{\Glsdesc*{fail}}\label{sec:fail}
+\section{Fault-Injection Leveraged}\label{sec:fail}
 
 \begin{itemize}
   \item FAIL*~\autocite{schirmeierFAILOpenVersatile2015} architecture
@@ -12,4 +12,6 @@
   \item How to perform a FAIL* experiment
 \end{itemize}
 
+\Gls{fail}~\autocite{schirmeierFAILOpenVersatile2015}
+
 \end{document}