85 lines
4.9 KiB
TeX
85 lines
4.9 KiB
TeX
%! TeX program = lualatex
|
|
%! TeX root = ../../thesis.tex
|
|
\documentclass[../../thesis.tex]{subfiles}
|
|
|
|
\begin{document}
|
|
|
|
\chapter{Experiment Setup}\label{ch:experimentsetup}
|
|
|
|
\section{Execution Environment}\label{sec:executionenvironment}
|
|
|
|
To keep the experiment setup as simple as possible, experiments are executed in a bare-metal environment without any operating system.
|
|
This has the advantage of avoiding some sources of possible non-determinism (caused, e.g., by scheduling or interrupts) during fault injection.
|
|
It also prevents any operating system code from being targeted by the \Gls{fi} framework.
|
|
While a suitable and correctly configured statically linked real-time operating system inside a controlled, emulated environment is not prone to those issues, running experiments bare-metal excludes this category of possible problems entirely.
|
|
|
|
Instead, experiments are cross-compiled to freestanding executables using \code{i386-elf-gcc} with Newlib\footnote{\url[2026-08-12]{https://sourceware.org/newlib/}} libc.
|
|
To make Newlib work inside a bare-metal environment, certain system calls must be provided by the platform, although not all of them need to be functional\footnote{\url[2026-08-12]{https://sourceware.org/newlib/libgloss.html#Libraries-1}}:
|
|
\begin{itemize}
|
|
\item \code{sbrk()} is required for Newlib's \code{malloc()}, \code{calloc()} and \code{realloc()} memory-management functions. Although \Gls{wamr} uses its own memory allocator implementation (see \autoref{sec:wasmhostprogram}), \Gls{wasm} targets may still require a functional \code{sbrk()} if \Gls{wamr}'s \code{snprintf}/\code{vsnprintf} are used, depending on the format string.
|
|
\item \code{read()}, \code{write()}, \code{close()}, \code{fstat()} and \code{isatty()} stubs are required for \Gls{wamr} targets. Since no filesystem or console exists in the execution environment, they do not need to be functional.
|
|
\item \code{lseek()} is required for C and \Gls{wamr} targets. A stub suffices for the same reason as above.
|
|
\item \code{\_exit()}, \code{kill()} and \code{getpid()} are required for \Gls{wamr} targets. Implementations can be omitted, as the execution environment does not use processes.
|
|
\end{itemize}
|
|
|
|
For experiment execution, the executables are packed into Multiboot\footnote{\url[2026-07-13]{https://www.gnu.org/software/grub/manual/multiboot/multiboot.html}}-compatible disk images with GNU GRUB\footnote{\url[2026-08-12]{https://www.gnu.org/software/grub/}} embedded via \code{grub-mkrescue} and executed in \Gls{bochs} via \Gls{fail}.
|
|
|
|
\section{\Gls{wamr} Modifications}\label{sec:wamrmodifications}
|
|
\begin{itemize}
|
|
\item WAMR baremetal platform
|
|
\item WAMR exception handler marker?
|
|
\end{itemize}
|
|
|
|
\section{Wasm Host Program}\label{sec:wasmhostprogram}
|
|
\begin{itemize}
|
|
\item WAMR setup
|
|
\item WAMR memory allocators
|
|
\item Calling \code{FAIL\_MARKER}s (native functions)
|
|
\end{itemize}
|
|
|
|
\section{Experiment Variants}\label{sec:experimenttypes}
|
|
\begin{itemize}
|
|
\item C only
|
|
\item WAMR AOT
|
|
\item WAMR interpreter
|
|
\end{itemize}
|
|
|
|
\section{Controlling What Gets Injected/Memory Isolation}\label{sec:controllingmemoryisolation}
|
|
\begin{itemize}
|
|
\item How can the WAMR allocators be used to control what gets injected? They cannot. --catch-write-textsegment doesn't prevent injection, just writes of the regular program.
|
|
\item --catch-write-textsegment (does NOT prevent injections into the textsegment!)
|
|
\item --catch-outerspace
|
|
\end{itemize}
|
|
|
|
\section{Controlling What Data Gets Extracted From The Experiments}
|
|
\begin{itemize}
|
|
\item What queries are run?
|
|
\item How are the equivalence classes expanded?
|
|
\item What/How is the data filtered (e.g., to exclude WAMR's native call chain)?
|
|
\end{itemize}
|
|
|
|
\section{Missing FAIL\_MARKERs for AOT experiments}
|
|
\begin{itemize}
|
|
\item AOT Addressauflösung/Def-Use chain theory
|
|
\item Somehow caught by --catch-write-textsegment or --catch-outerspace because stuff was linked to .text?
|
|
\item Optimization theory
|
|
\begin{itemize}
|
|
\item Does the target program contain the expected instructions?
|
|
\item Does FAIL* treat the variables as not live? (volatile, fail\_stop\_trace(sum))
|
|
\item Trying more complex programs, as -O0 always writes intermediate results to memory
|
|
\item Swap fail\_marker\_positive and fail\_marker\_negative
|
|
\end{itemize}
|
|
\item Does the pruner clear those injections for some reason?
|
|
\item Does the disassembler not disassemble the .text subsections?
|
|
\item Is the TracingPlugin broken? (GDB -> No, but FAIL* doesn't trace register accesses)
|
|
\item Solution: Gap in the .elf symbol space (addresses that are not covered by some symbol). FAIL needs this to disassemble the Wasm AOT code to find the register accesses. FAIL also needs to find this AOT code, so it can't be relocated -> Needs --xip
|
|
\end{itemize}
|
|
|
|
\section{Target Programs}
|
|
\begin{itemize}
|
|
\item Toy examples
|
|
\item TacleBench~\autocite{TACLeBench,seidlerTACLeBenchWasmConverter2026}
|
|
\end{itemize}
|
|
|
|
\end{document}
|