From 087b82af963e9f7ae1f88e490a732335b4a6fdf5 Mon Sep 17 00:00:00 2001 From: Christoph Urlacher Date: Tue, 7 Jul 2026 16:04:59 +0200 Subject: [PATCH] Small improvements after feedback (citing, footnotes, methodology) --- .../00_introduction/00_00_introduction.tex | 90 +++++++++++++++++++ .../01_introduction/01_00_introduction.tex | 38 -------- .../01_00_related_work.tex} | 0 chapters/02_methodology/02_00_methodology.tex | 11 +++ chapters/03_background/03_01_wasm.tex | 4 +- chapters/03_background/03_02_wamr.tex | 2 +- chapters/03_background/03_03_fail.tex | 2 +- chapters/06_discussion/06_00_discussion.tex | 52 ----------- glossary.tex | 2 +- references.bib | 2 +- thesis.tex | 7 +- 11 files changed, 112 insertions(+), 98 deletions(-) create mode 100644 chapters/00_introduction/00_00_introduction.tex delete mode 100644 chapters/01_introduction/01_00_introduction.tex rename chapters/{02_related_work/02_00_related_work.tex => 01_related_work/01_00_related_work.tex} (100%) create mode 100644 chapters/02_methodology/02_00_methodology.tex diff --git a/chapters/00_introduction/00_00_introduction.tex b/chapters/00_introduction/00_00_introduction.tex new file mode 100644 index 0000000..a01ed05 --- /dev/null +++ b/chapters/00_introduction/00_00_introduction.tex @@ -0,0 +1,90 @@ +%! TeX program = lualatex +%! TeX root = ../../thesis.tex +\documentclass[../../thesis.tex]{subfiles} + +\begin{document} + +\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 \glspl{sdc} or \glspl{due}. +This work focuses on \glspl{sdc} specifically as they can propagate silently through subsequent data-/program-flow 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. + +\Gls{wamr}~\autocite{wamr} is designed for lightweight standalone execution of \Gls{wasm} modules. +It supports interpretation (with and without \gls{jit} compilation) and \gls{aot} compilation, trading memory footprint and portability for performance. +Besides platform independence, the \Gls{wasm} specification mandates additional safety features such as memory-isolated program execution and bounds-checked memory access. +This raises the question of how fault resilience compares between executing a (hardened) program natively or introducing \Gls{wamr} as an additional abstraction layer to the execution environment. + +To answer these questions, this thesis uses the \Gls{fail} \gls{fi} framework~\autocite{schirmeierFAILVersatileFaultInjection2012} that allows injecting bit-level faults into a simulated CPU using the Bochs IA-32 emulator. +\Gls{fail} is able to exhaustively cover the fault-space of possible bit flips by applying fault-similarity pruning to reduce the size of the fault-space and smart-hopping to accelerate single experiment simulations~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}. + +To mitigate \Glspl{sdc}, software-based fault tolerance techniques are evaluated. +\Glspl{anbcode}~\autocite{forinVitalCodedMicroprocessor1990} are a method of encoding and verifying data- and program-flow integrity during execution. +\Gls{replication}~\autocite{polednaReplicaDeterminismDistributed1994} improves fault resilience by executing multiple independent copies of computations and using majority voting to detect or correct errors. +Both techniques can be applied either at the application level, by hardening the program before compilation to \Gls{wasm}, or at the runtime level, by hardening \Gls{wamr} itself to transparently improve fault resilience. + +The central objective is to analyze the effects of transient faults on \Gls{wamr} and assess the effectiveness of hardening techniques across execution modes. + +\todo[inline]{Introduction from expose, needs to be rewritten} + +\section{Research Questions} + +\paragraph{How do transient hardware faults affect the correctness of programs executed in \Gls{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 if 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 fault. +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?} + +\Gls{wamr} supports both \gls{aot} compilation and interpreted execution of \Gls{wasm} modules. +\Gls{aot} mode executes a \Gls{wasm} module pre-compiled to native code. +\Gls{wamr} sets up an execution environment that provides \Gls{wasm}-specific benefits such as isolated execution or checked memory access before jumping into native code. +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 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 \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}?} + +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. +The bytecode level also allows a more fine-grained approach to methods like software-based replication, as individual instructions can be replicated. + +\paragraph{How effectively can hardening techniques be applied directly to the WAMR runtime's interpreter execution mode?} + +In contrast to application-level hardening, this question investigates modifying the \Gls{wamr} runtime itself to improve reliability. +This could offer advantages since it eliminates the need to harden each program on the application level individually, but could be unfeasible to implement or introduce high performance penalties. +Key components of the interpreter loop, such as the opcode dispatch mechanism or arithmetic operations, could be hardened. +Additionally, other critical runtime components that contribute disproportionately to fault propagation are to be identified. +The evaluation focuses on the feasibility of hardening the \Gls{wamr} runtime, its impact on \gls{sdc} rates, and its runtime cost. + +\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. +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?} + +Fault tolerance mechanisms introduce computational overhead, which is especially important in resource-constrained environments. +This question compares the performance impact of application-level and runtime-level hardening to determine trade-offs between resilience and efficiency. +Performance is evaluated in the context of embedded/resource-restrained systems, where constraints might limit the ability to use certain hardening strategies. + +\todo[inline]{Taken from expose for reference} + +\end{document} diff --git a/chapters/01_introduction/01_00_introduction.tex b/chapters/01_introduction/01_00_introduction.tex deleted file mode 100644 index 8da2458..0000000 --- a/chapters/01_introduction/01_00_introduction.tex +++ /dev/null @@ -1,38 +0,0 @@ -%! TeX program = lualatex -%! TeX root = ../../thesis.tex -\documentclass[../../thesis.tex]{subfiles} - -\begin{document} - -\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 \glspl{sdc} or \glspl{due}. -This work focuses on \glspl{sdc} specifically as they can propagate silently through subsequent data-/program-flow 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. - -\Gls{wamr}~\autocite{wamr} is designed for lightweight standalone execution of \Gls{wasm} modules. -It supports interpretation (with and without \gls{jit} compilation) and \gls{aot} compilation, trading memory footprint and portability for performance. -Besides platform independence, the \Gls{wasm} specification mandates additional safety features such as memory-isolated program execution and bounds-checked memory access. -This raises the question of how fault resilience compares between executing a (hardened) program natively or introducing \Gls{wamr} as an additional abstraction layer to the execution environment. - -To answer these questions, this thesis uses the \Gls{fail} \gls{fi} framework~\autocite{schirmeierFAILVersatileFaultInjection2012} that allows injecting bit-level faults into a simulated CPU using the Bochs IA-32 emulator~\autocite{bochs}. -\Gls{fail} is able to exhaustively cover the fault-space of possible bit flips by applying fault-similarity pruning to reduce the size of the fault-space and smart-hopping to accelerate single experiment simulations~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}. - -To mitigate \Glspl{sdc}, software-based fault tolerance techniques are evaluated. -\Glspl{anbcode}~\autocite{forinVitalCodedMicroprocessor1990} are a method of encoding and verifying data- and program-flow integrity during execution. -\Gls{replication}~\autocite{polednaReplicaDeterminismDistributed1994} improves fault resilience by executing multiple independent copies of computations and using majority voting to detect or correct errors. -Both techniques can be applied either at the application level, by hardening the program before compilation to \Gls{wasm}, or at the runtime level, by hardening \Gls{wamr} itself to transparently improve fault resilience. - -The central objective is to analyze the effects of transient faults on \Gls{wamr} and assess the effectiveness of hardening techniques across execution modes. - -\todo[inline]{Introduction from expose, needs to be rewritten} - -\end{document} diff --git a/chapters/02_related_work/02_00_related_work.tex b/chapters/01_related_work/01_00_related_work.tex similarity index 100% rename from chapters/02_related_work/02_00_related_work.tex rename to chapters/01_related_work/01_00_related_work.tex diff --git a/chapters/02_methodology/02_00_methodology.tex b/chapters/02_methodology/02_00_methodology.tex new file mode 100644 index 0000000..e024f7a --- /dev/null +++ b/chapters/02_methodology/02_00_methodology.tex @@ -0,0 +1,11 @@ +%! TeX program = lualatex +%! TeX root = ../../thesis.tex +\documentclass[../../thesis.tex]{subfiles} + +\begin{document} + +\chapter{Methodology}\label{ch:methodology} + +Specific FARM-model variant for this research questions, fault model. + +\end{document} diff --git a/chapters/03_background/03_01_wasm.tex b/chapters/03_background/03_01_wasm.tex index 0dbb0b8..3792b85 100644 --- a/chapters/03_background/03_01_wasm.tex +++ b/chapters/03_background/03_01_wasm.tex @@ -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. diff --git a/chapters/03_background/03_02_wamr.tex b/chapters/03_background/03_02_wamr.tex index 8741b5e..e86376a 100644 --- a/chapters/03_background/03_02_wamr.tex +++ b/chapters/03_background/03_02_wamr.tex @@ -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. diff --git a/chapters/03_background/03_03_fail.tex b/chapters/03_background/03_03_fail.tex index 6ac933b..9f0dae4 100644 --- a/chapters/03_background/03_03_fail.tex +++ b/chapters/03_background/03_03_fail.tex @@ -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. diff --git a/chapters/06_discussion/06_00_discussion.tex b/chapters/06_discussion/06_00_discussion.tex index ef79dea..14f0653 100644 --- a/chapters/06_discussion/06_00_discussion.tex +++ b/chapters/06_discussion/06_00_discussion.tex @@ -6,56 +6,4 @@ \chapter{Discussion}\label{ch:discussion} -\section{Research Questions} - -\subsection{How do transient hardware faults affect the correctness of programs executed in \Gls{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 if 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 fault. -Additionally, the distribution of faults is examined to determine particularly vulnerable code paths in \Gls{wamr}. - -\subsection{How does the resilience of \Gls{wamr} differ between interpreter mode and \gls{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 pre-compiled to native code. -\Gls{wamr} sets up an execution environment that provides \Gls{wasm}-specific benefits such as isolated execution or checked memory access before jumping into native code. -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. - -\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 \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. - -\subsection{To what extent can the intermediate \Gls{wasm} program be hardened to reduce \gls{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. -The bytecode level also allows a more fine-grained approach to methods like software-based replication, as individual instructions can be replicated. - -\subsection{How effectively can hardening techniques be applied directly to the WAMR runtime's interpreter execution mode?} - -In contrast to application-level hardening, this question investigates modifying the \Gls{wamr} runtime itself to improve reliability. -This could offer advantages since it eliminates the need to harden each program on the application level individually, but could be unfeasible to implement or introduce high performance penalties. -Key components of the interpreter loop, such as the opcode dispatch mechanism or arithmetic operations, could be hardened. -Additionally, other critical runtime components that contribute disproportionately to fault propagation are to be identified. -The evaluation focuses on the feasibility of hardening the \Gls{wamr} runtime, its impact on \gls{sdc} rates, and its runtime cost. - -\subsection{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. -The hardening potential of this approach is compared to the hardening of the interpreter execution mode in the previous research question. - -\subsection{How do the runtime overheads of application- and runtime-level hardening compare?} - -Fault tolerance mechanisms introduce computational overhead, which is especially important in resource-constrained environments. -This question compares the performance impact of application-level and runtime-level hardening to determine trade-offs between resilience and efficiency. -Performance is evaluated in the context of embedded/resource-restrained systems, where constraints might limit the ability to use certain hardening strategies. - -\todo[inline]{Taken from expose for reference} - \end{document} diff --git a/glossary.tex b/glossary.tex index 6665d7c..e6a07c2 100644 --- a/glossary.tex +++ b/glossary.tex @@ -56,7 +56,7 @@ } \newglossaryentry{iwasm}{% name={iWasm}, - description={\Gls{wamr}'s standalone binary that provides a command-line interface to load and execute \Gls{wasm} modules} + description={\Gls{wamr}'s standalone binary that provides a command-line interface to load and execute \Gls{wasm} modules using \Gls{vmcore}} } \newglossaryentry{replication}{% name={Replication}, diff --git a/references.bib b/references.bib index a4f3731..b2159ae 100644 --- a/references.bib +++ b/references.bib @@ -33,7 +33,7 @@ urldate = {2026-03-28}, } -@software{bochs, +@comment{bochs, title = {{Bochs IA-32 Emulator Project}}, author = {Lawton, Kevin and {BOCHS Contributors}}, date = {}, diff --git a/thesis.tex b/thesis.tex index 50962f9..3b3ad17 100644 --- a/thesis.tex +++ b/thesis.tex @@ -8,10 +8,13 @@ % TODO: Double check the autofilled Zotero references -\subfile{chapters/01_introduction/01_00_introduction.tex} +\subfile{chapters/00_introduction/00_00_introduction.tex} \cleardoublepage% -\subfile{chapters/02_related_work/02_00_related_work.tex} +\subfile{chapters/01_related_work/01_00_related_work.tex} +\cleardoublepage% + +\subfile{chapters/02_methodology/02_00_methodology.tex} \cleardoublepage% \subfile{chapters/03_background/03_00_background.tex}