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/00_introduction/00_00_introduction.tex
+90
View File
@@ -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}