christoph/experimental-evaluation-of-webassembly-under-transient-fault-conditions-for-safety-critical-systems
1
Fork 0
Code Activity

Slight updates to background chapter language

Browse Source
This commit is contained in:
christoph
2026-09-10 17:15:30 +02:00
parent e2d97e7773
commit f52052f5f0
4 changed files with 20 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapters/03_background/03_00_background.tex
+4
View File
@@ -6,4 +6,8 @@
\chapter{Background}\label{ch:background}
\begin{enumerate}
\item Fault -> Error -> Failure (fault chain terminology). Also SDC/DUE differentiation
\end{enumerate}
\end{document}
chapters/03_background/03_01_wasm.tex
+7 -7
View File
@@ -12,7 +12,7 @@ It is developed and maintained by the World Wide Web Consortium (W3C)\iffalse{}\
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.
Both formats represent the same underlying content, but serve different purposes.
% \begin{codeblock}[label=lst:wasmexample]{\Gls{wasm} Binary Format}{.wasm}
% \inputminted{hex}{\subfix{listings/wat_example.hex}}
@@ -25,23 +25,23 @@ Both formats are equivalent, they represent the same underlying content differen
% 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.
A \code{type} declaration defines a shared function signature, the \code{func} references this type and provides an 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.
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 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.
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 lastly, \textit{invoked}.
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/}}.
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.
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.
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.
Its safety features, portability, language and 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}
chapters/03_background/03_02_wamr.tex
+5 -4
View File
@@ -11,19 +11,20 @@
\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.
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 \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{Classic Interpreter} is \Gls{wamr}'s slow reference implementation of a \Gls{wasm} interpreter, primarily intended for debugging.
\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.
\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.
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.
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.
\end{document}
chapters/03_background/03_03_fail.tex
+4 -4
View File
@@ -8,12 +8,12 @@
\Gls{fail}~\autocite{schirmeierFAILOpenVersatile2015} is an emulation-based vulnerability analysis tool.
It provides a toolset to perform \gls{fi} experiments to analyze the vulnerability of software to transient hardware faults.
In contrast to other \gls{fi} tools\todo{give examples}, \Gls{fail} enables deep simulator state access while simultaneously supporting multiple simulator backends, like BOCHS\footnote{\url[2026-07-07]{https://bochs.sourceforge.io/}} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}.
In contrast to other \gls{fi} tools\todo{give examples}, \Gls{fail} enables deep simulator state access while simultaneously supporting multiple simulator backends, like \Gls{bochs}\footnote{\url[2026-07-07]{https://bochs.sourceforge.io/}} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}.
\Gls{fail} is split into different components: A \textit{campaign} consists of multiple \gls{fi} \textit{experiments}, where each experiment injects a single fault.
The \textit{campaign controller} distributes those experiments to running \Gls{fail} instances.
Campaigns can be parallelized by running multiple instances on different systems or cores.
Each experiment utilizes \Gls{fail}'s \textit{simulator abstraction layer} to control the target backend, to fast-forward the target to the desired state and inject a fault.
Each experiment utilizes \Gls{fail}'s \textit{simulator abstraction layer} to control the backend, advance execution to the desired state and inject.
This abstraction layer allows switching out backends to support different target platforms.
To perform a vulnerability analysis, the examined program needs to be instrumented with fences that define the region to trace (see \autoref{lst:tracefencemarkers}).
@@ -21,11 +21,11 @@ To perform a vulnerability analysis, the examined program needs to be instrument
\inputminted{cpp}{\subfix{listings/tracefence.cpp}}
\end{codeblock}
\Gls{fail} then records the instruction pointer changes and memory accesses inside this region during the so-called \textquote{golden run}: a faultless execution of the program that determines which injections should be performed during the campaign.
Then, the golden run is enriched with the traced region's disassembly to take into account the read and written registers.
Then, the golden run is enriched with the traced region's disassembly to take into account the register reads and writes.
The last step before campaign execution is the \textit{prune} step, where the collected data is translated into corresponding experiments.
Different data points from the trace that result in the same \textquote{fault-similarity class} (as used by Schirmeier~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}) are removed from the campaign.
Two experiments belong to the same similarity class if the \textit{relevant} parts of their resulting simulator state are identical.
From the pruned instruction pointer changes, memory accesses, and register accesses \Gls{fail} constructs a number of \textit{pilots}: representatives of the existing fault-similarity classes.
From the pruned instruction pointer changes, memory accesses, and register accesses, \Gls{fail} constructs a number of \textit{pilots}: representatives of the existing fault-similarity classes.
Each pilot then corresponds to a single experiment.
\Gls{fail}'s campaigns are event-driven: the user specifies conditions, for example an access to a certain memory region.