%! TeX program = lualatex
%! TeX root = ../../thesis.tex
\documentclass[../../thesis.tex]{subfiles}

\begin{document}

\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}
