Add "placeholder" text from proposal

2026-07-01 15:38:19 +02:00
parent 914325fdbe
commit ef81fcee56
12 changed files with 222 additions and 70 deletions
@@ -5,4 +5,56 @@

 \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 \gls{anbcode}d 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}