Start background chapter

2026-07-01 23:53:27 +02:00
parent 446f82205a
commit c3a06b4e43
13 changed files with 138 additions and 34 deletions
@@ -6,7 +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}.
+\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.
@@ -5,27 +5,8 @@

 \chapter{Background}\label{ch:background}

-\section{WebAssembly}
-\begin{itemize}
-  \item What is it
-  \item WebAssembly text format
-  \item WebAssembly memory, containerization, restricted controlflow
-\end{itemize}
-
-
-\section{WebAssembly Micro Runtime}
-\begin{itemize}
-  \item Memory allocators (pool, usage), linear memory, memory usage
-  \item Different interpreters + JiTs + AoT (information + tradeoffs)
-\end{itemize}
-\todo[inline]{Not sure where the Wasm/WAMR separation is}
-
-\section{Fault-Injection Leveraged~\autocite{schirmeierFAILOpenVersatile2015}}
-\begin{itemize}
-  \item FAIL* architecture
-  \item FAIL*Bochs backend, how does FAIL* inject
-  \item FAIL*'s generic-experiment
-  \item How to perform a FAIL* experiment
-\end{itemize}
+\subfile{03_01_wasm.tex}
+\subfile{03_02_wamr.tex}
+\subfile{03_03_fail.tex}

 \end{document}
@@ -0,0 +1,40 @@
+%! TeX program = lualatex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{\Glsdesc*{wasm}}\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}.
+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.
+
+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.
+
+% \begin{codeblock}[label=lst:wasmexample]{\Gls{wasm} Binary Format}{.wasm}
+%   \inputminted{hex}{\subfix{listings/wat_example.hex}}
+% \end{codeblock}
+
+\begin{codeblock}[label=lst:watexample]{\Gls{wasm} Text Format}{.wat}
+  \inputminted{wat}{\subfix{listings/wat_example.wat}}
+\end{codeblock}
+
+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}.
+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.
+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.
+
+Its safety features, portability, language/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}
+% \subsection{\Glsdesc*{wasm} Memories}\label{ssec:wasmmemories}
+% \subsection{\Glsdesc*{wasm} Control Flow}\label{ssec:wasmcontrolflow}
+
+\end{document}
@@ -0,0 +1,13 @@
+%! TeX program = lualatex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{\Glsdesc*{wamr}}\label{sec:wamr}
+
+\begin{itemize}
+  \item Memory allocators (pool, usage), linear memory, memory usage
+  \item Different interpreters + JiTs + AoT (information + tradeoffs)
+\end{itemize}
+
+\end{document}
@@ -0,0 +1,15 @@
+%! TeX program = lualatex
+\documentclass[../../thesis.tex]{subfiles}
+
+\begin{document}
+
+\section{\Glsdesc*{fail}}\label{sec:fail}
+
+\begin{itemize}
+  \item FAIL*~\autocite{schirmeierFAILOpenVersatile2015} architecture
+  \item FAIL*Bochs backend, how does FAIL* inject
+  \item FAIL*'s generic-experiment
+  \item How to perform a FAIL* experiment
+\end{itemize}
+
+\end{document}
@@ -0,0 +1,5 @@
+0000000 6100 6d73 0001 0000 0501 6001 0100 037f
+0000010 0102 0500 0103 0200 0806 7f01 4101 8880
+0000020 0b04 1107 0602 656d 6f6d 7972 0002 6d04
+0000030 6961 006e 0a00 0106 0004 2a41 000b     
+000003d
@@ -0,0 +1,8 @@
+(module $wat_example.wasm
+  (type (;0;) (func (result i32)))
+  (func $main (type 0) (result i32)
+    i32.const 42)
+  (memory (;0;) 2)
+  (global $__stack_pointer (mut i32) (i32.const 66560))
+  (export "memory" (memory 0))
+  (export "main" (func $main)))
@@ -25,7 +25,7 @@ This question compares both modes under identical \gls{fi} campaigns to determin
 \subsection{To what extent can source program 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 \gls{anbcode}d majority voter.
+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.