Small improvements after feedback (citing, footnotes, methodology)
This commit is contained in:
@@ -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}
|
||||
@@ -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}
|
||||
@@ -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}
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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}
|
||||
|
||||
+1
-1
@@ -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},
|
||||
|
||||
+1
-1
@@ -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 = {},
|
||||
|
||||
+5
-2
@@ -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}
|
||||
|
||||
Reference in New Issue
Block a user