Update zotero.bib

Small improvements after feedback (citing, footnotes, methodology)
Update zotero.bib
2026-07-07 16:12:02 +02:00 · 2026-07-07 16:04:59 +02:00 · 2026-07-06 22:55:33 +02:00 · 2026-07-05 23:46:00 +02:00 · 2026-07-05 23:45:52 +02:00 · 2026-07-03 20:17:45 +02:00
21 changed files with 4319 additions and 541 deletions
@@ -1,424 +1,3 @@
-# Created by https://www.toptal.com/developers/gitignore/api/windows,linux,macos,visualstudiocode,sublimetext,latex
+**/.aux
-# Edit at https://www.toptal.com/developers/gitignore?templates=windows,linux,macos,visualstudiocode,sublimetext,latex
+**/.out
-
+**/svg-inkscape
 ### LaTeX ###
 ## Core latex/pdflatex auxiliary files:
 *.aux
 *.lof
 *.log
 *.lot
 *.fls
 *.out
 *.toc
 *.fmt
 *.fot
 *.cb
 *.cb2
 .*.lb
 ## Intermediate documents:
 *.dvi
 *.xdv
 *-converted-to.*
 *.ist
 # these rules might exclude image files for figures etc.
 # *.ps
 # *.eps
 # *.pdf
 ## Generated if empty string is given at "Please type another file name for output:"
 .pdf
 ## Bibliography auxiliary files (bibtex/biblatex/biber):
 *.bbl
 *.bcf
 *.blg
 *-blx.aux
 *-blx.bib
 *.run.xml
 ## Build tool auxiliary files:
 *.fdb_latexmk
 *.synctex
 *.synctex(busy)
 *.synctex.gz
 *.synctex.gz(busy)
 *.pdfsync
 **/build
 ## Build tool directories for auxiliary files
 # latexrun
 latex.out/
 svg-inkscape/
 _minted-*/
 ## Auxiliary and intermediate files from other packages:
 # algorithms
 *.alg
 *.loa
 # achemso
 acs-*.bib
 # amsthm
 *.thm
 # beamer
 *.nav
 *.pre
 *.snm
 *.vrb
 # changes
 *.soc
 # comment
 *.cut
 # cprotect
 *.cpt
 # elsarticle (documentclass of Elsevier journals)
 *.spl
 # endnotes
 *.ent
 # fixme
 *.lox
 # feynmf/feynmp
 *.mf
 *.mp
 *.t[1-9]
 *.t[1-9][0-9]
 *.tfm
 #(r)(e)ledmac/(r)(e)ledpar
 *.end
 *.?end
 *.[1-9]
 *.[1-9][0-9]
 *.[1-9][0-9][0-9]
 *.[1-9]R
 *.[1-9][0-9]R
 *.[1-9][0-9][0-9]R
 *.eledsec[1-9]
 *.eledsec[1-9]R
 *.eledsec[1-9][0-9]
 *.eledsec[1-9][0-9]R
 *.eledsec[1-9][0-9][0-9]
 *.eledsec[1-9][0-9][0-9]R
 # glossaries
 *.acn
 *.acr
 *.glg
 *.glo
 *.gls
 *.*-glg
 *.*-glo
 *.*-gls
 *.glsdefs
 *.lzo
 *.lzs
 # uncomment this for glossaries-extra (will ignore makeindex's style files!)
 # *.ist
 # gnuplottex
 *-gnuplottex-*
 # gregoriotex
 *.gaux
 *.gtex
 # htlatex
 *.4ct
 *.4tc
 *.idv
 *.lg
 *.trc
 *.xref
 # hyperref
 *.brf
 # knitr
 *-concordance.tex
 # TODO Comment the next line if you want to keep your tikz graphics files
 *.tikz
 *-tikzDictionary
 # listings
 *.lol
 # luatexja-ruby
 *.ltjruby
 # makeidx
 *.idx
 *.ilg
 *.ind
 # minitoc
 *.maf
 *.mlf
 *.mlt
 *.mtc
 *.mtc[0-9]*
 *.slf[0-9]*
 *.slt[0-9]*
 *.stc[0-9]*
 # minted
 _minted*
 *.pyg
 # morewrites
 *.mw
 # nomencl
 *.nlg
 *.nlo
 *.nls
 # pax
 *.pax
 # pdfpcnotes
 *.pdfpc
 # sagetex
 *.sagetex.sage
 *.sagetex.py
 *.sagetex.scmd
 # scrwfile
 *.wrt
 # sympy
 *.sout
 *.sympy
 sympy-plots-for-*.tex/
 # pdfcomment
 *.upa
 *.upb
 # pythontex
 *.pytxcode
 pythontex-files-*/
 # tcolorbox
 *.listing
 # thmtools
 *.loe
 # TikZ & PGF
 *.dpth
 *.md5
 *.auxlock
 # todonotes
 *.tdo
 # vhistory
 *.hst
 *.ver
 # easy-todo
 *.lod
 # xcolor
 *.xcp
 # xmpincl
 *.xmpi
 # xindy
 *.xdy
 # xypic precompiled matrices and outlines
 *.xyc
 *.xyd
 # endfloat
 *.ttt
 *.fff
 # Latexian
 TSWLatexianTemp*
 ## Editors:
 # WinEdt
 *.bak
 *.sav
 # Texpad
 .texpadtmp
 # LyX
 *.lyx~
 # Kile
 *.backup
 # gummi
 .*.swp
 # KBibTeX
 *~[0-9]*
 # TeXnicCenter
 *.tps
 # auto folder when using emacs and auctex
 ./auto/*
 *.el
 # expex forward references with \gathertags
 *-tags.tex
 # standalone packages
 *.sta
 # Makeindex log files
 *.lpz
 # REVTeX puts footnotes in the bibliography by default, unless the nofootinbib
 # option is specified. Footnotes are the stored in a file with suffix Notes.bib.
 # Uncomment the next line to have this generated file ignored.
 #*Notes.bib
 ### LaTeX Patch ###
 # LIPIcs / OASIcs
 *.vtc
 # glossaries
 *.glstex
 ### Linux ###
 *~
 # temporary files which can be created if a process still has a handle open of a deleted file
 .fuse_hidden*
 # KDE directory preferences
 .directory
 # Linux trash folder which might appear on any partition or disk
 .Trash-*
 # .nfs files are created when an open file is removed but is still being accessed
 .nfs*
 ### macOS ###
 # General
 .DS_Store
 .AppleDouble
 .LSOverride
 # Icon must end with two \r
 Icon
 # Thumbnails
 ._*
 # Files that might appear in the root of a volume
 .DocumentRevisions-V100
 .fseventsd
 .Spotlight-V100
 .TemporaryItems
 .Trashes
 .VolumeIcon.icns
 .com.apple.timemachine.donotpresent
 # Directories potentially created on remote AFP share
 .AppleDB
 .AppleDesktop
 Network Trash Folder
 Temporary Items
 .apdisk
 ### SublimeText ###
 # Cache files for Sublime Text
 *.tmlanguage.cache
 *.tmPreferences.cache
 *.stTheme.cache
 # Workspace files are user-specific
 *.sublime-workspace
 # Project files should be checked into the repository, unless a significant
 # proportion of contributors will probably not be using Sublime Text
 # *.sublime-project
 # SFTP configuration file
 sftp-config.json
 # Package control specific files
 Package Control.last-run
 Package Control.ca-list
 Package Control.ca-bundle
 Package Control.system-ca-bundle
 Package Control.cache/
 Package Control.ca-certs/
 Package Control.merged-ca-bundle
 Package Control.user-ca-bundle
 oscrypto-ca-bundle.crt
 bh_unicode_properties.cache
 # Sublime-github package stores a github token in this file
 # https://packagecontrol.io/packages/sublime-github
 GitHub.sublime-settings
 ### VisualStudioCode ###
 .vscode/*
 !.vscode/tasks.json
 !.vscode/launch.json
 *.code-workspace
 ### VisualStudioCode Patch ###
 # Ignore all local history of files
 .history
 .ionide
 ### Windows ###
 # Windows thumbnail cache files
 Thumbs.db
 Thumbs.db:encryptable
 ehthumbs.db
 ehthumbs_vista.db
 # Dump file
 *.stackdump
 # Folder config file
 [Dd]esktop.ini
 # Recycle Bin used on file shares
 $RECYCLE.BIN/
 # Windows Installer files
 *.cab
 *.msi
 *.msix
 *.msm
 *.msp
 # Windows shortcuts
 *.lnk
 # End of https://www.toptal.com/developers/gitignore/api/windows,linux,macos,visualstudiocode,sublimetext,latex
 # Ignore compiled pdf documents (I don't have any .pdf graphics)
 *.pdf
 # Ignore latexindent backups
 *.bak*
 # Ignore tcblistof output
 *.listings
@@ -1,5 +1,5 @@
-$pdf_mode = 1;
+$pdf_mode = 4;
-$pdflatex =
+$lualatex =
 q{lualatex -shell-escape -interaction=nonstopmode %O %S 2>&1 | perl -pe 's/(^!.*)/\e[1;31m$1\e[0m/; s/([Ww]arning)/\e[1;33m$1\e[0m/'};
 $out_dir       = ".out";
 $aux_dir       = ".aux";
@@ -6,7 +6,7 @@ build:
    FILE=$(find . -type f \( -path './chapters/*' -name '*.tex' ! -name 'template.tex' \) -o -name 'thesis.tex' | sed 's|^\./||' | sort | fzf)
    DIR=$(dirname "$FILE")
    BASE=$(basename "$FILE" .tex)
-    kitty -e sh -c "cd '$DIR' && BIBINPUTS='$ROOT:' {{ LATEXMK }} '$BASE.tex'" > /dev/null 2>&1 &
+    kitty -e sh -c "cd '$DIR' && BIBINPUTS='$ROOT:' {{ LATEXMK }} -r '$ROOT/.latexmkrc' '$BASE.tex'" > /dev/null 2>&1 &
 clean:
    find . -type d \( -name build -o -name svg-inkscape -o -name .aux -o -name .out \) -exec rm -rf {} +
@@ -0,0 +1,90 @@
 %! TeX program = lualatex
 %! TeX root = ../../thesis.tex
 \documentclass[../../thesis.tex]{subfiles}
 \begin{document}
 \chapter{Introduction}\label{ch:introduction}
 As semiconductor node sizes shrink, transient hardware faults pose a growing risk to computing systems, especially in environments where reliability is critical.
 \Gls{wasm}, a binary code format developed for the web, is increasingly used in embedded systems through standalone runtimes such as the \Gls{wamr}~\autocite{wamr}.
 This thesis investigates \Gls{wamr}'s compatibility with hardening techniques for transient hardware faults through systematic single-bit fault injection on a simulated IA-32 CPU using the \Gls{fail} \gls{fi} framework.
 The interpreter and \gls{aot} execution modes of \Gls{wamr} are compared under fault conditions and software-based hardening techniques are evaluated at two levels: (I) the language/application level, by hardening source programs before compilation to \Gls{wasm}, and (II) the runtime level, by hardening \Gls{wamr} itself.
 \todo[inline]{Abstract from expose, needs to be rewritten}
 Transient hardware faults can manifest in different types of errors such as \glspl{sdc} or  \glspl{due}.
 This work focuses on \glspl{sdc} specifically as they can propagate silently through subsequent data-/program-flow 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 compares between executing a (hardened) program natively or introducing \Gls{wamr} as an additional abstraction layer to the execution environment.
 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 single experiment simulations~\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 program-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 \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}.
 \paragraph{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.
 \paragraph{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.
 \paragraph{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.
 \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 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.
 \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 embedded/resource-restrained systems, where constraints might limit the ability to use certain hardening strategies.
 \todo[inline]{Taken from expose for reference}
 \end{document}
@@ -1,38 +0,0 @@
 %! TeX program = lualatex
 %! TeX root = ../../thesis.tex
 \documentclass[../../thesis.tex]{subfiles}
 \begin{document}
 \chapter{Introduction}\label{ch:introduction}
 As semiconductor node sizes shrink, transient hardware faults pose a growing risk to computing systems, especially in environments where reliability is critical.
 \Gls{wasm}, a binary code format developed for the web, is increasingly used in embedded systems through standalone runtimes such as the \Gls{wamr}~\autocite{wamr}.
 This thesis investigates \Gls{wamr}'s compatibility with hardening techniques for transient hardware faults through systematic single-bit fault injection on a simulated IA-32 CPU using the \Gls{fail} \gls{fi} framework.
 The interpreter and \gls{aot} execution modes of \Gls{wamr} are compared under fault conditions and software-based hardening techniques are evaluated at two levels: (I) the language/application level, by hardening source programs before compilation to \Gls{wasm}, and (II) the runtime level, by hardening \Gls{wamr} itself.
 \todo[inline]{Abstract from expose, needs to be rewritten}
 Transient hardware faults can manifest in different types of errors such as \glspl{sdc} or  \glspl{due}.
 This work focuses on \glspl{sdc} specifically as they can propagate silently through subsequent data-/program-flow 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 compares between executing a (hardened) program natively or introducing \Gls{wamr} as an additional abstraction layer to the execution environment.
 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~\autocite{bochs}.
 \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 single experiment simulations~\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 program-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}
 \end{document}
@@ -0,0 +1,11 @@
 %! TeX program = lualatex
 %! TeX root = ../../thesis.tex
 \documentclass[../../thesis.tex]{subfiles}
 \begin{document}
 \chapter{Methodology}\label{ch:methodology}
 Specific FARM-model variant for this research questions, fault model.
 \end{document}
@@ -8,7 +8,7 @@
 The open \Acrfull{wasm} standard defines a portable virtual instruction set architecture, binary code format and text format for execution inside a virtual (stack) machine~\autocite{wasm3spec}.
 \Gls{wasm} instructions operate on an operand stack instead of registers: values are pushed and consumed through stack operations, similar to Java's virtual machine.
-It is developed and maintained by the World Wide Web Consortium (W3C)\footnote{\url[2026-07-01]{https://w3.org/}} to support high-performance applications in web-based environments.
+It is developed and maintained by the World Wide Web Consortium (W3C)\iffalse{}\footnote{\url[2026-07-01]{https://w3.org/}}\fi to support high-performance applications in web-based environments.
 While the initial implementations of \Gls{wasm} runtime environments were confined to web browsers\footnote{In 2016, experimental \Gls{wasm} runtimes were implemented in Firefox, Google Chrome and Microsoft Edge: \url[2026-07-01]{https://hacks.mozilla.org/2016/03/a-webassembly-milestone/}}, \Gls{wasm} does not make any web-specific assumptions, so many different standalone runtimes like \textquote{Wasmtime}\footnote{\url[2026-07-01]{https://github.com/bytecodealliance/wasmtime/}} or the \Acrfull{wamr} (see \autoref{sec:wamr}) have emerged since.
 Besides instructions or execution behavior, two file formats are defined by the \Gls{wasm} standard: the \Gls{wasm} \textquote{Binary Format} \iffalse{}(see \autoref{lst:wasmexample})\fi for space-efficient representation and fast transmission, and the Lisp-like \Gls{wasm} \textquote{Text Format} for human readability (see \autoref{lst:watexample}).
@@ -37,7 +37,7 @@ To execute a program, the module is loaded from its binary format representation
 During runtime, \Gls{wasm} provides memory safety, control flow integrity and independent execution (sandboxing)\footnote{\url[2026-07-01]{https://webassembly.org/docs/security/}}.
 Memory safety is achieved through a bounds-checked linear memory with an inaccessible call stack\footnote{The call stack is not part of \Gls{wasm}'s linear memory but the execution environment: \url[2026-07-01]{https://bytecodealliance.github.io/wamr.dev/blog/the-wamr-memory-model/}}, preventing arbitrary memory accesses and buffer overflows.
 The linear memory is a contiguous and growable byte array that is shared between the module and host.
-Control flow integrity stems from structured control flow: branches target verifiable positions and function calls are index-based and verified against the function table\footnote{\url[2026-07-01]{https://clang.llvm.org/docs/ControlFlowIntegrity.html}}.
+Control flow integrity stems from structured control flow: branches target verifiable positions and function calls are index-based and verified against the function table\iffalse{}\footnote{\url[2026-07-01]{https://clang.llvm.org/docs/ControlFlowIntegrity.html}}\fi.
 Additionally, the running program cannot observe its (immutable) source code to prevent control flow hijacking.
 Sandboxing is enforced by isolating each module's state: a module can only interact with the outside world through explicitly imported functions and resources provided by its host runtime.
@@ -6,7 +6,7 @@
 \section{WebAssembly Micro Runtime}\label{sec:wamr}
-\Acrfull{wamr}~\autocite{wamr} is a lightweight standalone \Gls{wasm} runtime by the \textquote{Bytecode Alliance}\footnote{\url[2026-07-02]{https://bytecodealliance.org/}}, designed for embedded devices.
+\Acrfull{wamr}~\autocite{wamr} is a lightweight standalone \Gls{wasm} runtime by the \textquote{Bytecode Alliance}\iffalse{}\footnote{\url[2026-07-02]{https://bytecodealliance.org/}}\fi, designed for embedded devices.
 \Gls{wamr} includes three main components: The runtime libraries required to load and execute \Gls{wasm} modules (the decode, validate, instantiate, invoke process mentioned in \autoref{sec:wasm}) are called \textquote{\Gls{vmcore}}.
 \Gls{vmcore} can be embedded in C/C++ host applications.
@@ -6,17 +6,51 @@
 \section{Fault-Injection Leveraged}\label{sec:fail}
 \begin{itemize}
  \item FAIL*~\autocite{schirmeierFAILOpenVersatile2015} architecture
  \item FAIL*Bochs backend, how does FAIL* inject
  \item FAIL*'s generic-experiment
  \item How to perform a FAIL* experiment
 \end{itemize}
 \Gls{fail}~\autocite{schirmeierFAILOpenVersatile2015} is an emulation-based vulnerability analysis tool.
 It provides a toolset to perform \gls{fi} experiments to analyze the vulnerability of software to transient hardware faults.
-In contrast to other \gls{fi} tools, \Gls{fail} enables deep simulator state access while simultaneously supporting multiple simulator backends, like BOCHS~\autocite{bochs} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}. % TODO: Give examples for other FI frameworks
+In contrast to other \gls{fi} tools\todo{give examples}, \Gls{fail} enables deep simulator state access while simultaneously supporting multiple simulator backends, like BOCHS\footnote{\url[2026-07-07]{https://bochs.sourceforge.io/}} or gem5\footnote{\url[2026-07-02]{https://www.gem5.org/}}.
-% FAIL components/structure/architecture
+\Gls{fail} is split into different components: A \textit{campaign} consists of multiple \gls{fi} \textit{experiments}, where each experiment injects a single fault.
 The \textit{campaign controller} distributes those experiments to running \Gls{fail} instances.
 Campaigns can be parallelized by running multiple instances on different systems or cores.
 Each experiment utilizes \Gls{fail}'s \textit{simulator abstraction layer} to control the target backend, to fast-forward the target to the desired state and inject a fault.
 This abstraction layer allows switching out backends to support different target platforms.
 To perform a vulnerability analysis, the examined program needs to be instrumented with fences that define the region to trace (see \autoref{lst:tracefencemarkers}).
 \begin{codeblock}[label=lst:tracefencemarkers]{Trace Region Fence}{.cpp}
  \inputminted{cpp}{\subfix{listings/tracefence.cpp}}
 \end{codeblock}
 \Gls{fail} then records the instruction pointer changes and memory accesses inside this region during the so-called \textquote{golden run}: a faultless execution of the program that determines which injections should be performed during the campaign.
 Then, the golden run is enriched with the traced region's disassembly to take into account the read and written registers.
 The last step before campaign execution is the \textit{prune} step, where the collected data is translated into corresponding experiments.
 Different data points from the trace that result in the same \textquote{fault-similarity class} (as used by Schirmeier~\autocite{schirmeierEfficientFaultInjectionbasedAssessment}) are removed from the campaign.
 Two experiments belong to the same similarity class if the \textit{relevant} parts of their resulting simulator state are identical.
 From the pruned instruction pointer changes, memory accesses, and register accesses \Gls{fail} constructs a number of \textit{pilots}: representatives of the existing fault-similarity classes.
 Each pilot then corresponds to a single experiment.
 \Gls{fail}'s campaigns are event-driven: the user specifies conditions, for example an access to a certain memory region.
 Once a condition is reached, a user-defined action is performed, like injecting a fault or registering a certain experiment outcome.
 Users do not have to write every campaign from scratch, as \Gls{fail} includes a \textquote{generic experiment} which can be used as a starting point.
 The generic experiment performs three types of fault injections by default:
 \begin{itemize}
  \item \sansbf{Memory} injections: Before the program reads from a memory address, a fault is injected.
  \item \sansbf{Register} injections: Before the program reads from a register, a fault is injected.
  \item \sansbf{Instruction Pointer} injections: The instruction pointer's value is randomized to disturb the program flow and introduce random jumps.
 \end{itemize}
 Furthermore, different experiment outcomes are classified:
 \begin{itemize}
  \item \sansbf{Trap}: The injected fault caused the simulated CPU to throw an exception.
  \item \sansbf{Timeout}: The injected fault caused the program to stall.
  \item \sansbf{Ok Marker} (\code{fail\_marker\_positive()}): The program executed correctly even with the injected fault.
  \item \sansbf{Detected Marker} (\code{fail\_marker\_detected()}): The injected fault was detected by the program.
  \item \sansbf{Fail Marker} (\code{fail\_marker\_negative()}): The injected fault was not detected by the program.
  \item \sansbf{Access Outerspace}: Caught if the program reads or writes anywhere outside valid ELF addresses.
  \item \sansbf{Write Textsegment}: Caught if the program writes to addresses inside the \code{.text} section of the program.
 \end{itemize}
 Ok/Detected/Fail outcomes are classified by instrumenting the tested code with \textquote{markers} (see \autoref{lst:classificationmarkers}).
 If the program execution passes a marker, the experiment outcome is classified accordingly.
 \begin{codeblock}[label=lst:classificationmarkers]{Classification Markers}{.cpp}
  \inputminted{cpp}{\subfix{listings/classificationmarkers.cpp}}
 \end{codeblock}
 \end{document}
@@ -0,0 +1,6 @@
 // Continuation of previous example
 if (sum == 100) {
  fail_marker_positive();
 } else {
  fail_marker_negative();
 }
@@ -0,0 +1,8 @@
 fail_start_trace();
 int sum = 0;
 for (int i = 0; i < 100; ++i) {
  ++sum;
 }
 fail_stop_trace();
@@ -6,56 +6,4 @@
 \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}
@@ -13,6 +13,9 @@ This is \code{inline code}.
 This is a reference to \Gls{fail}.
 This is another reference to \Gls{fail}.
 This is a citation~\autocite{polednaReplicaDeterminismDistributed1994}.
 \section{This is a section}\label{sec:examplesection}
 This is a reference to \autoref{ch:introduction}.
 This is a formula: \( \sum\limits_{f=1}^{\infty}\frac{o}{r}\cdot m_{u} + l^{a} \).
 This is \textbf{bold text that is slightly bold}, so underwhelming.
@@ -24,12 +27,20 @@ In contrast, \sansbf{this text is very strong}, very cool\footnote{very cool}.
 \begin{figure}[H]
  \centering
-  \begin{subfigure}[b]{0.55\textwidth}
+  \begin{subfigure}[b]{0.85\textwidth}
    \includesvg[width=1.0\linewidth]{\subfix{figures/example.svg}}
  \end{subfigure}
  \caption{This is a figure.}\label{fig:examplefigure}
 \end{figure}
 \begin{figure}[H]
  \centering
  \begin{subfigure}[b]{0.95\textwidth}
    \includesvg[width=1.0\linewidth]{\subfix{figures/heatmap2.svg}}
  \end{subfigure}
  \caption{This is another figure.}\label{fig:exampleheatmap}
 \end{figure}
 \lipsum%
 \end{document}
@@ -55,8 +55,8 @@
  description={Hardening technique utilizing \Gls{replication} in combination with an \glsdisp{anbcode}{ANB-coded} majority voter},
 }
 \newglossaryentry{iwasm}{%
-  name={iwasm},
+  name={iWasm},
-  description={\Gls{wamr}'s standalone binary that provides a command-line interface to load and execute \Gls{wasm} modules}
+  description={\Gls{wamr}'s standalone binary that provides a command-line interface to load and execute \Gls{wasm} modules using \Gls{vmcore}}
 }
 \newglossaryentry{replication}{%
  name={Replication},
@@ -68,6 +68,6 @@
  description={\Gls{wamr}'s runtime libraries for \Gls{wasm} module loading and execution}
 }
 \newglossaryentry{wamrc}{%
-  name={wamrc},
+  name={WamrC},
  description={\Gls{wamr}'s \gls{aot} compiler for \Gls{wasm}}
 }
@@ -35,6 +35,7 @@
 \usepackage{tikz}
 \usetikzlibrary{shadings, backgrounds}
 \usepackage[minted]{tcolorbox}
 \setminted{style=default}
 \tcbuselibrary{skins} % breakable
 % Math
@@ -60,8 +61,8 @@
 % Pagestyle
 \KOMAoptions{%
-  chapterprefix,
+  % chapterprefix,
-  appendixprefix,
+  % appendixprefix,
  headsepline,
  % footsepline,
  % cleardoublepage=current, % linenumbers and headers on interleaf pages
@@ -69,6 +70,17 @@
  footnotes=multiple, % TODO: Doesn't work, maybe because of hyperref?
 }
 % Chapter style
 \renewcommand*{\chapterformat}{%
  {\huge\mdseries\chapapp~\thechapter\autodot\enskip}%
 }
 \setkomafont{chapter}{\huge\bfseries}
 \renewcommand{\chapterlinesformat}[3]{%
  #2{\MakeUppercase{#3}}%
  \par\nobreak\vspace{.3\baselineskip}%
  \rule{\textwidth}{.5pt}%
 }
 % Various stuff
 \usepackage[page]{appendix} % [toc]
 \usepackage{lipsum}
@@ -79,13 +91,16 @@
 \usepackage{siunitx}
 \sisetup{detect-all}
 \usepackage[l2tabu,orthodox]{nag}
-% \usepackage{etoolbox} % For \ifstrequal
+\usepackage{etoolbox} % For \ifstrequal
 \usepackage[autostyle]{csquotes} % Correct quotation marks with \textquote{}
 \usepackage{silence} % Silence warnings
 % \usepackage[intoc]{nomencl} % Nomenclature
 \usepackage[luatex,colorlinks]{hyperref} % Load late, hidelinks
 \usepackage{bookmark} % Needed for hyperref with scrbook
 \usepackage[acronym,automake=immediate,nonumberlist,nogroupskip,toc]{glossaries} % Load after hyperref, toc
 \setacronymstyle{long-short}
 \setglossarystyle{super}
 \renewcommand{\glsnamefont}[1]{\sansbf{#1}}
 \usepackage{xurl} % xurl does url-line-breaks in contrast to url
 % Multi-file
@@ -182,10 +197,10 @@
    \tableofcontents%
    \cleardoublepage%
    \phantomsection%
    \todototoc\listoftodos%
    \cleardoublepage%
    \setacronymstyle{long-short}
    \printacronyms%
    \cleardoublepage%
    \printglossary%
@@ -210,7 +225,7 @@
  \sloppy%
  \printbibliography[heading=bibintoc]
  % \printbibliography%
-  \endsloppy%
+  \fussy%
  \cleardoublepage%
  % Only compile lists/declaration with the main document
@@ -33,7 +33,7 @@
  urldate = {2026-03-28},
 }
-@software{bochs,
+@comment{bochs,
  title = {{Bochs IA-32 Emulator Project}},
  author = {Lawton, Kevin and {BOCHS Contributors}},
  date = {},
@@ -8,16 +8,20 @@
 % TODO: Double check the autofilled Zotero references
-\subfile{chapters/01_introduction/01_00_introduction.tex}
+\subfile{chapters/00_introduction/00_00_introduction.tex}
 \cleardoublepage%
-\subfile{chapters/02_related_work/02_00_related_work.tex}
+\subfile{chapters/01_related_work/01_00_related_work.tex}
 \cleardoublepage%
 \subfile{chapters/02_methodology/02_00_methodology.tex}
 \cleardoublepage%
 \subfile{chapters/03_background/03_00_background.tex}
 \subfile{chapters/03_background/03_01_wasm.tex}
 \subfile{chapters/03_background/03_02_wamr.tex}
 \subfile{chapters/03_background/03_03_fail.tex}
 % TODO: Write about faults/errors/fault chain?
 \cleardoublepage%
 \subfile{chapters/04_experiment_setup/04_00_experiment_setup.tex}
@@ -1,3 +1,31 @@
@article{aidemarkGOOFIGenericObjectOriented,
  title = {{{GOOFI}} : {{Generic Object-Oriented Fault Injection Tool}}},
  author = {Aidemark, Joakim and Vinter, Jonny and Folkesson, Peter and Karlsson, Johan},
  date = {2001},
  abstract = {In this paper, we present a new fault injection tool called GOOFI (Generic Object-Oriented Fault Injection). GOOFI is designed to be adaptable to various target systems and different fault injection techniques. The tool is highly portable between different host platforms since it relies on the Java programming language and a SQL compatible database. The current version of the tool supports pre-runtime Software Implemented Fault Injection and Scan-Chain Implemented Fault Injection.},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/3RK6XB92/Aidemark et al. - 2001 - GOOFI  Generic Object-Oriented Fault Injection Tool.pdf}
 }
@article{arlatFaultInjectionDependability1990,
  title = {Fault Injection for Dependability Validation: A Methodology and Some Applications},
  shorttitle = {Fault Injection for Dependability Validation},
  author = {Arlat, J. and Aguera, M. and Amat, L. and Crouzet, Y. and Fabre, J.-C. and Laprie, J.-C. and Martins, E. and Powell, D.},
  date = {1990-02},
  journaltitle = {IEEE Transactions on Software Engineering},
  shortjournal = {IIEEE Trans. Software Eng.},
  volume = {16},
  number = {2},
  pages = {166--182},
  issn = {00985589},
  doi = {10.1109/32.44380},
  url = {http://ieeexplore.ieee.org/document/44380/},
  urldate = {2026-07-07},
  abstract = {This paper addresses the problem of the dependability validation of fault-tolerant computing systems and more specifically the validation of the fault-tolerance mechanisms. The presented approach is based on the use of fault-injection at the physical level on a hardwarelsoftware prototype of the considered system. The place of this approach in a validation directed design process, as well as its place with respect to related works on fault-injection, is clearly identified. The major requirements and problems related to the development and application of a validation methodology based on fault injection are presented and discussed. Emphasis is put on the definition, analysis, and use of the experimental dependability measures that can be obtained. The proposed methodology has been implemented through the realization of a general pin-level fault injection tool (MESSALINE) and its usefulness is demonstrated by the application of MESSALINE to the experimental validation of two systems: 1) a subsystem of a centralized computerized inerlocking system for railway control applications and 2) a distributed system corresponding to the current implementation of the dependable communication system of the ESPRIT Delta-4 Project.},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/7J6HHXRR/Arlat et al. - 1990 - Fault injection for dependability validation a methodology and some applications.pdf}
 }
@inproceedings{chenImprovingJavaVirtual2005,
  title = {Improving Java Virtual Machine Reliability for Memory-Constrained Embedded Systems},
  booktitle = {Proceedings of the 42nd Annual Conference on {{Design}} Automation  - {{DAC}} '05},
@@ -16,6 +44,23 @@
  file = {/home/christoph/Notes/Zotero/storage/FKKICG9F/Chen and Kandemir - 2005 - Improving java virtual machine reliability for memory-constrained embedded systems.pdf}
 }
@inproceedings{fidalgoUsingNEXUSCompliant2006,
  title = {Using {{NEXUS}} Compliant Debuggers for Real Time Fault Injection on Microprocessors},
  booktitle = {Proceedings of the 19th Annual Symposium on {{Integrated}} Circuits and Systems Design},
  author = {Fidalgo, André and Gericota, Manuel and Alves, Gustavo and Ferreira, José},
  date = {2006-08-28},
  pages = {214--219},
  publisher = {ACM},
  location = {Ouro Preto MG Brazil},
  doi = {10.1145/1150343.1150397},
  url = {https://dl.acm.org/doi/10.1145/1150343.1150397},
  urldate = {2026-07-06},
  eventtitle = {{{SBCCI06}}: 19th {{Symposium}} on {{Integrated Circuits}} and {{System Design}}},
  isbn = {978-1-59593-479-6},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/LDE6FJQF/Fidalgo et al. - 2006 - Using NEXUS compliant debuggers for real time fault injection on microprocessors.pdf}
 }
@article{forinVitalCodedMicroprocessor1990,
  title = {Vital {{Coded Microprocessor Principles}} and {{Application}} for {{Various Transit Systems}}},
  author = {Forin, P.},
@@ -33,6 +78,50 @@
  file = {/home/christoph/Notes/Zotero/storage/77H4FFUQ/Forin - 1990 - Vital Coded Microprocessor Principles and Application for Various Transit Systems.pdf}
 }
@inproceedings{goloubevaSofterrorDetectionUsing2003,
  title = {Soft-Error Detection Using Control Flow Assertions},
  booktitle = {Proceedings 18th {{IEEE Symposium}} on {{Defect}} and {{Fault Tolerance}} in {{VLSI Systems}}},
  author = {Goloubeva, O. and Rebaudengo, M. and Sonza Reorda, M. and Violante, M.},
  date = {2003},
  pages = {581--588},
  publisher = {IEEE},
  location = {Boston, MA, USA},
  doi = {10.1109/DFTVS.2003.1250158},
  url = {https://ieeexplore.ieee.org/document/1250158/},
  urldate = {2026-07-06},
  abstract = {Over the last years, an increasing number of safety-critical tasks have been demanded to computer systems. In this paper, a software-based approach for developing safety-critical applications is analyzed. The technique is based on the introduction of additional executable assertions to check the correct execution of the program control flow. By applying the proposed technique, several benchmark applications have been hardened against transient errors. Fault Injection campaigns have been performed to evaluate the fault detection capability of the proposed technique in comparison with state-of-the-art alternative assertionbased methods. Experimental results show that the proposed approach is far more effective than the other considered techniques in terms of fault detection capability, at the cost of a limited increase in memory requirements and in performance overhead.},
  eventtitle = {Proceedings. 18th {{IEEE International Symposium}} on {{Defect}} and {{Fault Tolerance}} in {{VLSI Systems}}},
  isbn = {978-0-7695-2042-1},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/WI2QDM9X/Goloubeva et al. - 2003 - Soft-error detection using control flow assertions.pdf}
 }
@article{hammingErrorDetectingError,
  title = {Error Detecting and Error Correcting Codes},
  author = {Hamming, Richard W},
  date = {1950-04},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/AYGVTSAN/Hamming - 1950 - Error detecting and error correcting codes.pdf}
 }
@article{hoffmannExperiencesSoftwarebasedSofterror2016,
  title = {Experiences with Software-Based Soft-Error Mitigation Using {{AN}} Codes},
  author = {Hoffmann, Martin and Ulbrich, Peter and Dietrich, Christian and Schirmeier, Horst and Lohmann, Daniel and Schröder-Preikschat, Wolfgang},
  date = {2016-03},
  journaltitle = {Software Quality Journal},
  shortjournal = {Software Qual J},
  volume = {24},
  number = {1},
  pages = {87--113},
  issn = {0963-9314, 1573-1367},
  doi = {10.1007/s11219-014-9260-4},
  url = {http://link.springer.com/10.1007/s11219-014-9260-4},
  urldate = {2026-07-06},
  abstract = {Arithmetic error coding schemes are a well known and effective technique for soft error mitigation. Although the underlying coding theory is generally a complex area of mathematics, its practical implementation is comparatively simple in general. However, compliance with the theory can be lost easily while moving towards an actual implementation, which finally jeopardizes the aspired fault-tolerance characteristics and effectiveness. In this paper, we present our experiences and lessons learned from implementing arithmetic error coding schemes (AN codes) in the context of our Combined Redundancy fault-tolerance approach. We focus on the challenges and pitfalls in the transition from maths to machine code for a binary computer from a systems perspective. Our results show, that practical misconceptions (such as the use of prime numbers) and architecture-dependent implementation glitches occur at every stage of this transition. We identify typical pitfalls and describe practical measures to find and resolve them. This allowed us to eliminate all remaining silent data corruptions in the Combined Redundancy framework, which we validated by an extensive fault-injection campaign covering the entire fault space of 1-bit and 2-bit errors.},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/UU2JZ5HL/Hoffmann et al. - 2016 - Experiences with software-based soft-error mitigation using AN codes.pdf}
 }
@inproceedings{hoffmannPractitionersGuideSoftwareBased2014,
  title = {A {{Practitioner}}'s {{Guide}} to {{Software-Based Soft-Error Mitigation Using AN-Codes}}},
  booktitle = {2014 {{IEEE}} 15th {{International Symposium}} on {{High-Assurance Systems Engineering}}},
@@ -51,6 +140,33 @@
  file = {/home/christoph/Notes/Zotero/storage/CY3ULLCA/Hoffmann et al. - 2014 - A Practitioner's Guide to Software-Based Soft-Error Mitigation Using AN-Codes.pdf}
 }
@inproceedings{kuvaiskiiAmpampx0394EncodingPracticalEncoded2015,
  title = {Delta-{{Encoding}}: {{Practical Encoded Processing}}},
  shorttitle = {\&amp;Amp;\#x0394;-{{Encoding}}},
  booktitle = {2015 45th {{Annual IEEE}}/{{IFIP International Conference}} on {{Dependable Systems}} and {{Networks}}},
  author = {Kuvaiskii, Dmitrii and Fetzer, Christof},
  date = {2015-06},
  pages = {13--24},
  publisher = {IEEE},
  location = {Rio de Janeiro, Brazil},
  doi = {10.1109/DSN.2015.20},
  url = {https://ieeexplore.ieee.org/document/7266834},
  urldate = {2026-07-06},
  abstract = {Transient and permanent errors in memory and CPUs occur with alarming frequency. Although most of these errors are masked at the hardware level or result in crashes, a non-negligible number of them leads to Silent Data Corruptions (SDCs), i.e., incorrect results of computations. Safety-critical programs require a very high level of confidence that such faults are detected and not propagated to the outside. Unfortunately, state-of-the-art fault detection techniques generally assume a limited Single Event Upset fault model, concentrating only on transient faults.},
  eventtitle = {2015 45th {{Annual IEEE}}/{{IFIP International Conference}} on {{Dependable Systems}} and {{Networks}} ({{DSN}})},
  isbn = {978-1-4799-8629-3},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/XBMRFFTE/Kuvaiskii and Fetzer - 2015 - Delta-Encoding Practical Encoded Processing.pdf}
 }
@thesis{munkSoftwareFaultToleranceMechanism,
  title = {A Software Fault-Tolerance Mechanism for Mixed-Critical Real-Time Applications on Consumer-Grade Many-Core Processors},
  author = {Munk, Peter},
  date = {2016-07},
  langid = {ngerman},
  file = {/home/christoph/Notes/Zotero/storage/8QKA739L/Munk - 2016 - A Software Fault-Tolerance Mechanism for Mixed-Critical Real-Time Applications on Consumer-Grade Man.pdf}
 }
@article{polednaReplicaDeterminismDistributed1994,
  title = {Replica Determinism in Distributed Real-Time Systems: {{A}} Brief Survey},
  shorttitle = {Replica Determinism in Distributed Real-Time Systems},
@@ -70,6 +186,33 @@
  file = {/home/christoph/Notes/Zotero/storage/DB8GU2TK/Poledna - 1994 - Replica determinism in distributed real-time systems A brief survey.pdf}
 }
@article{raabSafeSoftwareProcessing,
  title = {Safe Software Processing by Concurrent Execution in a Real-Time Operating System},
  author = {Raab, Peter and Kramer, Stefan and Mottok, Jurgen and Meier, Hans and Racek, Stanislav},
  date = {2011-09},
  abstract = {The requirements for safety-related software systems increases rapidly. To detect arbitrary hardware faults, there are applicable coding mechanism, that add redundancy to the software. In this way it is possible to replace conventional multi-channel hardware and so reduce costs. Arithmetic codes are one possibility of coded processing and are used in this approach. A further approach to increase fault tolerance is the multiple execution of certain critical parts of software. This kind of time redundancy is easily realized by the parallel processing in an operating system. Faults in the program flow can be monitored. No special compilers, that insert additional generated code into the existing program, are required. The usage of multi-core processors would further increase the performance of such multi-channel software systems. In this paper we present the approach of program flow monitoring combined with coded processing, which is encapsulated in a library of coded data types. The program flow monitoring is indirectly realized by means of an operating system.},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/MJAVLTNB/Raab et al. - 2011 - Safe software processing by concurrent execution in a real-time operating system.pdf}
 }
@inproceedings{rebaudengoSofterrorDetectionSoftware1999,
  title = {Soft-Error Detection through Software Fault-Tolerance Techniques},
  booktitle = {Proceedings 1999 {{IEEE International Symposium}} on {{Defect}} and {{Fault Tolerance}} in {{VLSI Systems}} ({{EFT}}'99)},
  author = {Rebaudengo, M. and Sonza Reorda, M. and Torchiano, M. and Violante, M.},
  date = {1999},
  pages = {210--218},
  publisher = {IEEE Comput. Soc},
  location = {Albuquerque, NM, USA},
  doi = {10.1109/DFTVS.1999.802887},
  url = {http://ieeexplore.ieee.org/document/802887/},
  urldate = {2026-07-06},
  abstract = {The paper describes a systematic approach for automatically introducing data and code redundancy into an existing program written using a high-level language. The transformations aim at making the program able to detect most of the soft-errors affecting data and code, independently of the Error Detection Mechanisms (EDMs) possibly implemented by the hardware. Since the transformations can be automatically applied as a pre-compilation phase, the programmer is freed from the cost and responsibility of introducing suitable EDMs in its code. Preliminary experimental results are reported, showing the fault coverage obtained by the method, as well as some figures concerning the slow-down and code size increase it causes.},
  eventtitle = {1999 {{IEEE International Symposium}} on {{Defect}} and {{Fault Tolerance}} in {{VLSI Systems}}},
  isbn = {978-0-7695-0325-7},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/HFQUUT6L/Rebaudengo et al. - 1999 - Soft-error detection through software fault-tolerance techniques.pdf}
 }
@incollection{schiffelANBANBDmemEncodingDetecting2010,
  title = {{{ANB-}} and {{ANBDmem-Encoding}}: {{Detecting Hardware Errors}} in {{Software}}},
  shorttitle = {{{ANB-}} and {{ANBDmem-Encoding}}},
@@ -103,6 +246,24 @@
  file = {/home/christoph/Notes/Zotero/storage/7BXMSTFW/Hardware_Error_Detection_Using_AN_Codes.pdf}
 }
@incollection{schirmeierDependabilityAspectsConfigurable2021,
  title = {Dependability {{Aspects}} in {{Configurable Embedded Operating Systems}}},
  booktitle = {Dependable {{Embedded Systems}}},
  author = {Schirmeier, Horst and Borchert, Christoph and Hoffmann, Martin and Dietrich, Christian and Martens, Arthur and Kapitza, Rüdiger and Lohmann, Daniel and Spinczyk, Olaf},
  editor = {Henkel, Jörg and Dutt, Nikil},
  date = {2021},
  pages = {85--116},
  publisher = {Springer International Publishing},
  location = {Cham},
  doi = {10.1007/978-3-030-52017-5_4},
  url = {http://link.springer.com/10.1007/978-3-030-52017-5_4},
  urldate = {2026-07-06},
  abstract = {Abstract                            As all conceptual layers in the software stack depend on the operating system (OS) to reliably provide resource-management services and isolation, it can be considered the “reliable computing base” that must be hardened for correct operation under fault models such as transient hardware faults in the memory hierarchy. In this chapter, we approach the problem of system-software hardening in three complementary scenarios. (1) We address the following research question: Where do the general reliability limits of               static               system-software stacks lie, if designed from scratch with reliability as a first-class design goal? In order to reduce the proverbial “attack surface” as far as possible, we harness static application knowledge from an AUTOSAR-compliant task set, and protect the whole OS kernel with AN-encoding. This static approach yields an extremely reliable software system, but is constrained to specific application domains. (2) We investigate how reliable a               dynamic               COTS embedded OS can become if hardened with programming-language and compiler-based fault-tolerance techniques. We show that aspect-oriented programming is an appropriate means to encapsulate generic software-implemented hardware fault tolerance mechanisms that can be application-specifically applied to a selection of OS components. (3) We examine how system-software stacks can survive even more adverse fault models like whole-system outages, using emerging persistent memory (PM) technology as a vehicle for state conservation. Our findings include that software transactional memory facilitates maintaining consistent state within PM and allows fast recovery.},
  isbn = {978-3-030-52016-8 978-3-030-52017-5},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/WAVR4R62/Schirmeier et al. - 2021 - Dependability Aspects in Configurable Embedded Operating Systems.pdf}
 }
@thesis{schirmeierEfficientFaultInjectionbasedAssessment,
  type = {phdthesis},
  title = {Efficient {{Fault-Injection-based Assessment}} of {{Software-Implemented Hardware Fault Tolerance}}},
@@ -142,6 +303,43 @@
  file = {/home/christoph/Notes/Zotero/storage/G9SATNLR/Schirmeier et al. - FAIL Towards a Versatile Fault-Injection Experiment Framework.pdf}
 }
@article{schusterDemystifyingSoftErrorMitigation2017,
  title = {Demystifying {{Soft-Error Mitigation}} by {{Control-Flow Checking}} -- {{A New Perspective}} on Its {{Effectiveness}}},
  author = {Schuster, Simon and Ulbrich, Peter and Stilkerich, Isabella and Dietrich, Christian and SchröDer-Preikschat, Wolfgang},
  date = {2017-10-31},
  journaltitle = {ACM Transactions on Embedded Computing Systems},
  shortjournal = {ACM Trans. Embed. Comput. Syst.},
  volume = {16},
  pages = {1--19},
  issn = {1539-9087, 1558-3465},
  doi = {10.1145/3126503},
  url = {https://dl.acm.org/doi/10.1145/3126503},
  urldate = {2026-07-06},
  abstract = {Soft errors are a challenging and urging problem in the domain of safety-critical embedded systems. For decades, checking schemes have been investigated and improved to mitigate soft-error effects for the class of control-flow faults, with current industrial standards strongly recommending their use.             However, reality looks different: Taking a systems perspective, we implemented four representative Control-Flow Checking (CFC) schemes and put them through their paces in 396 fault-injection campaigns. In contrast to previous work, which typically relied on probability-based vulnerability metrics, we accounted for the influence of memory and time overheads on the fault-space dimensions and applied those in full-scan fault injections. This change in procedure alone severely degraded the perceived effectiveness of CFC.             In addition, we expanded the perspective to data-flow faults and their influence on the overall susceptibility, an aspect that so far has been largely ignored. Our results suggest that, without accompanying measures, any improvement regarding control-flow faults is dominated by the increase in data faults caused by the increased attack surface in terms of memory and runtime overhead. Moreover, CFC performance less depended on the detection capabilities than on general aspects of the concrete binary compilation and execution.             In conclusion, incorporating CFC is not as straightforward as often assumed and the vulnerability of systems with hardened control-flow may in many cases even be increased by the schemes themselves.},
  issue = {5s},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/BLKUCBAD/Schuster et al. - 2017 - Demystifying Soft-Error Mitigation by Control-Flow Checking -- A New Perspective on its Effectivenes.pdf}
 }
@inproceedings{skarinGOOFI2ToolExperimental2010,
  title = {{{GOOFI-2}}: {{A}} Tool for Experimental Dependability Assessment},
  shorttitle = {{{GOOFI-2}}},
  booktitle = {2010 {{IEEE}}/{{IFIP International Conference}} on {{Dependable Systems}} \& {{Networks}} ({{DSN}})},
  author = {Skarin, Daniel and Barbosa, Raul and Karlsson, Johan},
  date = {2010-06},
  pages = {557--562},
  publisher = {IEEE},
  location = {Chicago, IL},
  doi = {10.1109/DSN.2010.5544265},
  url = {http://ieeexplore.ieee.org/document/5544265/},
  urldate = {2026-07-06},
  abstract = {This paper presentsGOOFI-2, a comprehensive fault in jection tool for experimental dependability assessment of embedded systems. The tool includes a large number of ex tensions and improvements over its predecessor, GOOF!. These include support for three widely used fault injection techniques, two target processors, and a variety of new features for storing, disseminating and analyzing experi mental data. We report on our experiences and lessons learned from the use and development ofGOOFI-2. In par ticular, we compare and discuss properties of three fault injection techniques: Nexus-based, exception-based and instrumentation-based injection. The comparison relies on several sets of experiments with two target processors, Freescale's MPC565 and MPC5554.},
  eventtitle = {2010 {{IEEE}}/{{IFIP International Conference}} on {{Dependable Systems}} \& {{Networks}} ({{DSN}})},
  isbn = {978-1-4244-7500-1 978-1-4244-7501-8},
  langid = {english},
  file = {/home/christoph/Notes/Zotero/storage/2HMSUPZM/Skarin et al. - 2010 - GOOFI-2 A tool for experimental dependability assessment.pdf}
 }
@book{slettenWebAssemblyDefinitiveGuide2021,
  title = {{{WebAssembly}}: The Definitive Guide: Safe, Fast, and Portable Code},
  shorttitle = {{{WebAssembly}}},
Author	SHA1	Message	Date
christoph	9549ae774c	Update zotero.bib	2026-07-07 16:12:02 +02:00
christoph	087b82af96	Small improvements after feedback (citing, footnotes, methodology)	2026-07-07 16:04:59 +02:00
christoph	112159f893	Update zotero.bib	2026-07-06 22:55:33 +02:00
christoph	67929c39f4	Update chapter title style	2026-07-05 23:46:00 +02:00
christoph	3ba5be8c86	WIP: background section	2026-07-05 23:45:52 +02:00
christoph	af400ab8d4	Ignore converted SVGs	2026-07-03 20:17:45 +02:00
christoph	549a05fbf7	Fix incorrect resetting of \sloppy	2026-07-03 11:47:30 +02:00
christoph	6dbcdc05d3	Fix justfile .latexmkrc path for subfiles	2026-07-03 11:43:24 +02:00