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

Draft result filtering methodology section + expand wamr native call section

Browse Source
This commit is contained in:
christoph
2026-09-12 15:24:39 +02:00
parent f52ab00652
commit 2d2cd43dc5
12 changed files with 45 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapters/05_experiment_setup/05_03_workload_structure.tex
+8 -5
View File
@@ -71,9 +71,12 @@ To circumvent this, \Gls{wamr}'s native function invocation mechanism can be use
This registration populates a lookup table that maps the native function pointers to their names, so that \Gls{aot} programs can call \Gls{wamr}'s internal \code{aot\_invoke\_native} and interpreted programs can call \code{wasm\_interp\_call\_func\_native} to invoke those functions.
This indirection happens implicitly, on the application level no special steps need to be taken, functions can be called by their registered names.
To be compatible with the native function registration mechanism, functions need to accept the \Gls{wasm} execution environment as an argument (see \autoref{lst:wamrnativefunctions}).
It is important to consider that this native call mechanism introduces additional overhead that provides additional attack surface during fault-injection.
The return from the \code{fail\_start\_trace} call, the entry into the \code{fail\_stop\_trace} call and the entireties of any other marker calls within the traced region are susceptible to faults unintended in the experiment design: the source code instrumentation should only steer the fault-injection process, not interact with the workload execution itself.
How to counteract this limitation is described later, in \autoref{sec:resultfiltering} and \autoref{sec:resultextractionandqueries}.
\subsubsection{Wasm Module Instantiation and Execution}\label{sssec:wamrmoduleexecution}
To load the workload's \Gls{wasm} module and run it, a series of steps need to be executed:
@@ -85,12 +88,12 @@ To load the workload's \Gls{wasm} module and run it, a series of steps need to b
\item Call the exported entry function (\code{wasm\_runtime\_call\_wasm})
\end{enumerate}
In this thesis, compiled \Gls{wasm} modules are converted to C-style arrays using \code{xxd} and embedded into the program's source text.
This way, file access can be avoided and the module is loaded by simply passing a pointer to the correct function.
A simplified module call sequence is shown in \autoref{lst:wamrmodulecall}.
\begin{codeblock}[label=lst:wamrmodulecall]{Calling a \Gls{wasm} module from C.}{C++}
\inputminted{cpp}{listings/wamrmodulecall.cpp}
\end{codeblock}
In this thesis, compiled \Gls{wasm} modules are converted to C-style arrays using \code{xxd} and embedded into the program's source text.
This way, file access can be avoided and the module is loaded by simply passing a pointer to the correct function.
A simplified module call sequence is shown in \autoref{lst:wamrmodulecall}.
\end{document}
chapters/05_experiment_setup/05_06_results_filtering.tex
+1 -1
View File
@@ -4,7 +4,7 @@
\begin{document}
\section{Controlling What Data Gets Extracted From The Experiments}
\section{Result Extraction and Database Queries}\label{sec:resultextractionandqueries}
\begin{itemize}
\item What queries are run?