83 lines
7.4 KiB
TeX
83 lines
7.4 KiB
TeX
%! TeX program = lualatex
|
|
%! TeX root = ../../thesis.tex
|
|
\documentclass[../../thesis.tex]{subfiles}
|
|
|
|
\begin{document}
|
|
|
|
\chapter{Introduction}\label{ch:introduction}
|
|
|
|
Transient hardware faults can manifest in different types of errors such as \Gls{sdc} or \Glspl{due}.
|
|
This work focuses on \glspl{sdc} specifically as they can propagate silently through subsequent computations 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 differs between native execution and execution through \Gls{wamr} as an additional abstraction layer.
|
|
|
|
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 individual \Gls{fi} experiments~\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 control-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 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 whether 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 injected faults.
|
|
Additionally, the distribution of faults is examined to determine particularly vulnerable code paths in \Gls{wamr}.
|
|
|
|
\paragraph{How does the resilience of WAMR differ between interpreter mode and 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 precompiled 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 application-level hardening techniques applied to the source code reduce 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 Wasm program be hardened to reduce 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 individually at the application level, but may be infeasible 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 resource-constrained embedded systems, where constraints might limit the ability to use certain hardening strategies.
|
|
|
|
\todo[inline]{Taken from expose for reference}
|
|
|
|
\end{document}
|