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

Small improvements after feedback (citing, footnotes, methodology)

Browse Source
This commit is contained in:
christoph
2026-07-07 16:04:59 +02:00
parent 112159f893
commit 087b82af96
11 changed files with 112 additions and 98 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapters/03_background/03_01_wasm.tex
+2 -2
View File
@@ -8,7 +8,7 @@
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.
It is developed and maintained by the World Wide Web Consortium (W3C)\iffalse{}\footnote{\url[2026-07-01]{https://w3.org/}}\fi 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}).
@@ -37,7 +37,7 @@ To execute a program, the module is loaded from its binary format representation
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}}.
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.
chapters/03_background/03_02_wamr.tex
+1 -1
View File
@@ -6,7 +6,7 @@
\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.
\Acrfull{wamr}~\autocite{wamr} is a lightweight standalone \Gls{wasm} runtime by the \textquote{Bytecode Alliance}\iffalse{}\footnote{\url[2026-07-02]{https://bytecodealliance.org/}}\fi, 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.
chapters/03_background/03_03_fail.tex
+1 -1
View File
@@ -8,7 +8,7 @@
\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~\autocite{bochs} 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 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.