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

Add "placeholder" text from proposal

Browse Source
This commit is contained in:
christoph
2026-07-01 15:38:19 +02:00
parent 914325fdbe
commit ef81fcee56
12 changed files with 222 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapters/01_introduction/01_00_introduction.tex
+28 -1
View File
@@ -5,6 +5,33 @@
\chapter{Introduction}\label{ch:introduction}
\lipsum%
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}