Paper (PDF) - STS - TUHH

Bachelorarbeit
Marcel Heing-Becker
Bitfehlerinjektionen in Register
auf der Basis von FITIn
24. Juni 2013
betreut durch:
Prof. Dr. Sibylle Schupp
Hamburg University of Technology (TUHH)
Technische Universität Hamburg-Harburg
Institute for Software Systems
21073 Hamburg

Eidesstattliche Erklärung
Ich, Marcel Heing genannt Becker, versichere an Eides statt, dass ich die vorliegende Bachelorarbeit
mit dem Titel Bitfehlerinjektionen in Register auf der Basis von FITIn selbstständig
verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet
habe. Diese Arbeit wurde in dieser oder ähnlicher Form bisher keiner anderen Prüfungskommission
vorgelegt.
Hamburg, den 24. Juni 2013
(Unterschrift)
Marcel Heing genannt Becker
Matrikelnummer: 21046393
Studiengang: Computational Informatics B. Sc.
iii

Inhaltsangabe
Mit FITIn wurde ein Valgrind-basiertes Werkzeug geschaen, das in einem Zielprogramm
einen Bitfehler vornimmt. Zu diesem Zweck wurden bisher Ladeoperationen aus dem Prozessspeicher
überwacht. Vor einer vom Anwender gewählten Ladeoperation führte FITIn
an der Ladeadresse einen Bit-Flip durch. Dieses Prinzip verhinderte jedoch, dass der Benutzer
vor Lesezugrien auf Registern etwa wenn ein Wert für mehrere Operationen in
einem Register gehalten wird einen Fehler in diese injizieren konnte.
Im Rahmen dieser Arbeit wird FITIn auf die Erweiterbarkeit für diesen Anwendungsfall
untersucht. Dazu wird das Feld der Fehlerinjektion von einem höheren Standpunkt aus
betrachtet, um FITIn in seinen theoretischen Fähigkeiten einordnen zu können. Es wird
eine Implementierung vorgestellt, die einen Bitfehler nicht mehr vor der Ladeoperation
sondern vor der Verwendung eines relevanten Werts vornimmt. Auf diese Weise kann der
Benutzer von einer gröÿeren Transparenz bei der Verwendung von FITIn protieren.
Die erweiterte FITIn-Version wird etlichen Analysen zur Anwendbarkeit und Performance
unterzogen, die die Stärken und Schwächen demonstrieren. Insbesondere die Verwendung
von Valgrind verdient zusätzliche Aufmerksamkeit, da das Framework etliche Vor-,
aber auch Nachteile mit sich führt. Auÿerdem werden andere Konzepte zur Fehlerinjektion
in Register vorgestellt und mit FITIn verglichen.
Abstract
FITIn is a Valgrind-based tool created for performing a bit error in a target application. So
far, loading operations from the memory have been monitored to schedule error injections.
Given a user-selected load operation, FITIn ipped a single bit on the memory at runtime.
Doing it this way, the user faced a limitation if a value was not reloaded from the memory
but remained inside a register. This potentially reduced the granularity for choosing a
time when to perform a bit ip.
This work focuses on extending FITIn to allow such a use case. By a more comprehensive
look at the domain of fault injection, the position of FITIn will be highlighted.
An implementation will be presented that moves the bit error injection from pre-load to
pre-use time. This makes the user gain transparency when working with FITIn.
The new version of FITIn is subject to multiple analyses regarding usability and performance.
These analyses reveal strengths and weaknesses of FITIn. Valgrind deserves
some attention in particular as this framework implies both benets and diculties for
tools on top of it. Other approaches for injecting bit errors into registers will be presented
and compared to FITIn.
v

Inhaltsverzeichnis
1 Einführung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Fehlerinjektion 3
2.1 Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Injektionsebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Virtuelle Maschine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.4 Kompilierungszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.5 Programm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Erweiterung von FITIn 9
3.1 Dynamische Binärinstrumentierung . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Instrumentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3 VEX IR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 FITIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Registerbehandlung in Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Evaluierung von Ansätzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6 Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1 Betrachtete Operationen . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6.2 Instrumentierungszeit . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.3 Ausführungszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.4 float, double und weitere Datentypen . . . . . . . . . . . . . . . . . 26
3.6.5 Systemaufrufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Evaluierung von FITIn 31
4.1 Analyse von Testfällen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 FlipSafe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Performance-Strafe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Speicherbedarf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Zwischenfazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 Konkurrierende Ansätze 47
5.1 Programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 DBI-Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Vergleichsfazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
vii

6 Abschluss 51
6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Literaturverzeichnis 53
Akronyme 55
Abbildungsverzeichnis 57
Anhang A Ergänzendes Material 59
A.1 VEX IR-Spezikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2 Instrumentierungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Anhang B FITIn 65
B.1 Benutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.2 Problembehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
viii

1 Einführung
1.1 Motivation
Es existieren Einüsse auf die Ausführung von Software, die nicht durch diese selbst, nicht
durch eine ausführende virtuelle Maschine und nicht durch die Spezikation der darunterliegenden
Hardware bedingt sind: Sowohl ein Defekt der Hardware als auch Ionenstrahlung
oder elektromagnetische Interferenzen, die in Wechselwirkung mit einer Bitrepräsentation
treten, gehören zu diesen Faktoren. Ein mögliches Resultat ist die Umkehrung eines Bits
[1, S.3f]. In einem günstigen Fall wird ein sogenannter Bit-Flip unbemerkt bleiben, im
unglücklichsten Fall einen Systemabsturz herbeiführen.
Gegenmaÿnahmen, einen solchen Bit-Flip im Datenbereich zu erkennen und auch zu
korrigieren, nden sich sowohl in Hardware, etwa bei Arbeitsspeicher mit ECC-Fähigkeit,
als auch in Software, etwa durch redundante Speicherung von Daten. Softwareverfahren zur
Behandlung dieser Fälle werden Softwareimplementierte Hardwarefehlertoleranz (SIHFT)-
Techniken genannt [2, S.841].
Seitens eines Entwicklers mag die Motivation bestehen, Analyse- und Testverfahren zu
verwenden, die Bitfehler in der zu untersuchenden Software verursachen: zum systematischen
Analysieren der Auswirkung auf die Ausführung, zum Testen von SIHFT-Techniken
oder zur Beobachtung der Stabilität von numerischen Algorithmen.
Ein derartiges Testverfahren setzt sich insofern von bekannten Techniken wie Blackund
Whitebox-Tests oder Fuzzing ab, dass der Entwickler einen anderen Weg zur Beein-
ussung der Ausführung einschlagen muss: Etwa durch manuelles Nachstellen eines solchen
Falls im Quell- oder Binärcode, oder durch eine äuÿere Komponente, die auf das Programm
Einuss nehmen kann. Weiterhin mag der Auftritt eines Bit-Flips deterministisch oder stochastisch
gewünscht sein. Andere Anforderungen ergeben sich aus dem Ort, zum Beispiel
ob im Arbeitsspeicher oder in einem CPU-Register, und der Zeit der Manipulation, um
beispielsweise eine bestimmte Iteration oder Rekursionstiefe abzuwarten.
FITIn ist in seiner Ursprungsform ein für das Ausführungs- und Instrumentierungs-
Framework Valgrind entworfenes Plug-In, das dem Benutzer bei Vorlage des Quellcodes
in C/C++ ermöglicht, einen Bit-Flip auf einem gewählten Bit zur Ausführungszeit vor
einem gewählten Lesevorgang auf dem Speicher herbeizuführen. Im Vergleich zum manuellen
Vorgehen macht es FITIn dem Benutzer einfacher, ein anderes Bit und einen anderen
Zeitpunkt zu wählen.
1.2 Problembeschreibung
Die ursprüngliche Fassung von FITIn beschränkt sich darauf, einzig Lesezugrie auf den
Prozessspeicher zu erkennen und zum Abwarten des Flip-Zeitpunkts zu verwenden. Das
grundsätzliche Vorgehen bei der Benutzung sieht dabei wie folgt aus:
Bei Einsicht des Quellcodes entscheidet sich der Benutzer für eine oder mehrere Variablen,
die er für einen Bit-Flip in Betracht ziehen möchte. Dazu setzt er ein vorgegebenes
C-Makro nach der Deklarierung der Variablen. Nach einer erneuten Kompilierung
1

1 Einführung
des Quellcodeabschnitts lässt sich das Programm sowohl wie gewohnt als auch für FITIn
benutzen.
Valgrind erkennt anhand des durch das Makro erweiterten Stacks, dass eine Client-
Anfrage an FITIn gerichtet ist. FITIn erhält von einer Variablen die Startadresse sowie
deren Gröÿe in Bytes und fügt diese Daten der eigenen Erkennungsliste hinzu. Weiterhin
erhält FITIn von Valgrind eine Zwischenrepräsentation des auszuführenden Binärcodes,
aus der sich Zugrie auf den Speicher erkennen lassen und die sich zur Erzeugung von
Bit-Flips manipulieren lässt. Durch Maÿnahmen wird jeder relevante Lesezugri gezählt
und zum gewählten Zeitpunkt das gewählte Bit im Prozessspeicher invertiert, bevor die
Variable im Rahmen des ursprünglichen Programmusses aus dem Prozessspeicher gelesen
wird.
Auf vielen Prozessorarchitekturen werden Daten jedoch nicht vor jeder Benutzung
erneut aus dem Speicher in ein CPU-Register geladen: In Abhängigkeit der Zielplattform
führt der Compiler eine Analyse zur Registerallokation durch. Schlieÿlich verlangen gewisse
CPU-Instruktionen, dass sich die Operanden in einem Register benden. Durch geschickte
Anordnung der Instruktionen lassen sich Daten so lange wie möglich im Register halten,
bevor diese in den Arbeitsspeicher ausgelagert oder zurückgeschrieben werden [3, S.101f].
Dadurch werden nicht nur Lade- und Speicherinstruktionen eingespart, sondern auch der
tatsächliche Transfervorgang in ein deutlich langsameres Speichermedium und der aus diesem
hinaus.
Stellt man FITIn dieser Tatsache entgegen, erkennt man die Lücke, die sich durch
fehlendes Beobachten von Registerallokationen und -zugrien auftut. Im Rahmen dieses
Dokuments wird untersucht, inwieweit das bestehende FITIn für diese Aufgabe erweitert
werden kann. Dabei werden nicht nur verschiedene Ansätze verfolgt und eine Implementierung
vorgestellt (Kapitel 3), sondern auch die Fehlerinjektion im weiteren Sinne betrachtet
(Kapitel 2). Es wird darüber hinaus auf konkurrierende Ansätze eingegangen (Kapitel 5)
um die Vorteile und Grenzen von FITIn und Valgrind auszuloten. In der Evaluierung wird
FITIn verschiedenen Anwendungstests unterzogen und auf Fähigkeiten und Einschränkungen
untersucht. Im Sinne der ursprünglichen Entwicklung wird FITIn erneut dazu benutzt,
eine SIHFT-Bibliothek auf die Probe zu stellen. Auch über die Performance und
über den Speicherverbrauch von FITIn werden Einschätzungen gegeben (Kapitel 4).
2

2 Fehlerinjektion
Das Injizieren von Fehlern in ein Programm ist auf verschiedene Art und Weise möglich und
auf verschiedenen Ebenen der Hard- und Software realisierbar. In diesem Kapitel werden
potentielle Möglichkeiten aufgezeigt und kurz erörtert.
2.1 Methoden
Den Spezialfall der Fehlerinjektion in Register vorerst auÿer Acht gelassen, erönen sich
unterschiedliche Herangehensweisen, Einuss auf die Ausführung eines Programms zu erlangen.
Grundsätzlich sind diese in hard- und softwarebasierte Methoden aufzuteilen. Die
Abbildung 2.1 erlaubt einen Überblick über die Einordnung von Fehlerinjektionsmethoden
[4, S.76].
Hardwarebasiert
Kontaktbasiert
Tastkopf
Sockel
Fehlerinjektion
Kontaktlos
Vor Ausführung
Softwarebasiert
Zeitnehmer
Zur Ausführungszeit
Ausnahme
Abbildung 2.1: Taxonomie der Fehlerinjektion
Instrumentierung
Hardwarebasierte Fehlerinjektion
Die Manipulation von Hardware erfordert zusätzliche Hardware sowie die Fähigkeit, in
ausreichend kurzer Zeit herbeigeführte Fehler und deren Folgen erkennen zu können. Die
hardwarebasierte Fehlerinjektion teilt sich in zwei Untergruppen auf:
• Kontaktbasierte Fehlerinjektion: Eine Möglichkeit besteht darin, einen Hardware-Pin
mit einem aktiven Tastkopf zu berühren. Für die Dauer wird die Spannung an diesem
verändert, sodass die Auösung des Signals auf den gewünschten Wert eingerastet
wird. Komplexere Manipulationen lassen sich durch Sockelung der Hardware vornehmen:
So können zusätzlich mittels integrierter Logikgatter oder Schaltwerke die
Eingangssignale den Manipulationsanforderungen entsprechend angepasst werden.
3

2 Fehlerinjektion
• Kontaktlose Fehlerinjektion: Durch den Beschuss der Hardware mittels Ionen [5] oder
durch elektromagnetische Interferenzen [6] können Bitrepräsentationen umgekehrt
werden. Dieses Vorgehen ist mit Einbuÿen in der Präzision in Bezug auf Zeit und
Ort sowie der Wiederholbarkeit verbunden, es erlaubt jedoch eine Beobachtung der
Funktionsfähigkeit der Hardware in realen Strahlungsverhältnissen und elektrischen
Kongurationen.
Softwarebasierte Fehlerinjektion
Im Vergleich zu hardwarebasierten Fehlerinjektionen stellen softwarebasierte Lösungen
einen geringeren Kostenfaktor dar, und auch die Implementierung einer Fehlerinjektionssemantik
ist exibler realisierbar. Natürliche Grenzen sind der Software im Rahmen dessen
gesetzt, wie diese im Besitz von Hardwarezugrien ist: Eine Manipulation des Arbeitsspeichers
vorbei an einem Paritätsbit, das Teil eines hardwarebasierten elektronischen Korrekturcodes
(ECC) ist, ist daher zum Beispiel unmöglich. Man unterscheidet zwischen zwei
Injektionsszenarien:
• Vor der Ausführungszeit: An einem Zeitpunkt, bevor das Programm zur Ausführung
in den Arbeitsspeicher geladen ist. In Frage kommen manuelle Anpassungen
des Quellcodes, eine Compiler-Direktive oder die Manipulation des generierten Binärcodes.
Letzteres ordnet sich in die statische Binärinstrumentierung ein [7, S.3].
• Zur Ausführungszeit: Ist das Programm bereits als Prozess aktiv, bieten sich andere
Methoden zur Fehlerinjektion an: Die des ablaufenden Zeitnehmers, die der Ausnahmebehandlung
und die der Code-Instrumentierung. Betrachtet man den Ausführungs-
Stack eines Programms, können diese Fehlerinjektoren ab der Betriebssystemebene
sinnvoll implementiert werden.
• Ablaufender Zeitnehmer: Ein hard- oder softwarebasierter Zeitnehmer erzeugt
bei Ablauf einen Interrupt 1 . Eine auf diesen Interrupt gesetzte Callback-Methode
ist daraufhin in der Lage, eine Fehlerinjektion im Programm vorzunehmen. Die
Präzision dieser Methode ist begrenzt, da der Zeitablauf zum Beispiel durch
variable E/A-Operationen, auf die die CPU wartet, unvorhersehbar eintreten
kann.
• Ausnahmebehandlung: Sowohl ein softwarebedingtes Ausnahmeereignis, das vom
Programm vor der Ausführung des nachfolgenden Codeabschnitts ausgelöst
wird, als auch ein Hardwareereignis können dazu verwendet werden, zu ausgewählten
Zeitpunkten eine Fehlerinjektion vorzunehmen, sofern zuvor eine entsprechende
Callback-Prozedur registriert wurde.
• Code-Instrumentierung: Zur Laufzeit des Programms verfügt die fehlerinjizierende
Softwarekomponente über das Wissen, welche Instruktion als nächstes
ausgeführt wird und kann gegebenenfalls Instruktionen hinzufügen, die der Fehlerinjektion
dienlich sind. Der wesentliche Vorteil liegt dabei darin, dass eine Injektionssemantik
ungleich komplexer als in anderen Softwareansätzen gewählt
werden kann. Die Schwierigkeit bei diesem Ansatz ist dagegen, dass das instrumentierende
Programm mit dem ausgeführten Zielprogramm nicht weiter
in Konikt treten darf, etwa durch Blockierung von Ressourcen oder durch
Veränderung der denotationellen Semantik [8, S.266]. Allgemein, also nicht auf
Fehlerinjektionen begrenzt, nennt man dieses Vorgehen dynamische Binärinstrumentierung
(DBI) [7, S.3].
1 Deutsch: Unterbrechung
4

2.2 Anwendungsfälle
2.2 Anwendungsfälle
Binärfehler lassen sich in mehreren Formen und Auftrittsmustern konstruieren. Betrachtet
man ein einzelnes Bit, so ergeben sich folgende Fehlfunktionsszenarien:
• Bit-Flip: Ein Hardwaredefekt oder ein Umwelteinuss kehrt die Bitrepräsentation
temporär um. Ist ein Bit-Flip strahlungsbedingt, so spricht man von einem Single
Event Upset (SEU) [5, S.1].
• Bit-Einrastung: Das Bit lässt sich nicht mehr aktualisieren, es verbleibt im Zustand
0 oder 1. Dies kann einem Hardwaredefekt entsprechen, etwa degeneriertem Arbeitsspeicher.
• Flüchtiges Bit: Ein Speichermedium verliert seine Integrität, sodass zeitlich versetzte
Lesezugrie einen anderen Zustand zurückliefern können, aber nicht müssen [9,
S.116]. Ein solches Verhalten lässt sich mittels einer Veränderungsfrequenz oder einer
Zustandswahrscheinlichkeit bei Lesezugrien beschreiben.
In diesem Dokument werden ausschlieÿlich Binärfehler betrachtet, die im Bezug zur
Zustandsspeicherung stehen, dazu zählen CPU-Register und -Caches, der Arbeitsspeicher
(RAM) und der Sekundärspeicher. Ausdrücklich ausgeschlossen seien Übertragungsfehler
jeglicher Art.
Möchte man die Auswirkung von Bitfehlern auf den Programmuss untersuchen, so
sind die nachfolgenden Fälle von Interesse (basierend auf [10, S.37f]):
• Operanden
• Daten: Verfälschte Operanden, die der numerischen Berechnung dienen, werden
das Berechnungsergebnis trüben.
• Adressen: Abweichungen in Speicheradressen sind vergleichbar mit den Auswirkungen
unbedachter Zeigerverwendung im Quellcode: Falsche Daten werden
geladen, Daten werden unbeabsichtigt überschrieben und Operationen auf ungültigen
Speicherbereichen führen zu Programmabstürzen.
• Sprungkonditionen und -ziele: Einem modizierten Operanden, der als Bedingung
für einen Sprung dient, kann das Einschlagen eines anderen Instruktionspfads
folgen. Bei Sprüngen, die einen relativen oder absoluten Zieloperator besitzen,
ist die möglicherweise drastischere Folge, dass die Ausführung in einem
entfernten Abschnitt fortfährt.
• Flags: Flags halten zusätzliche Informationen über den CPU-Zustand oder über
die zuletzt ausgeführte Instruktion. Auch wenn diese, wie auf der x86-Architektur,
nicht explizit les- und schreibbar sind, so ist der Einuss des manipulierten Flags
entscheidend, wenn die nächste, davon abhängige Instruktion dadurch eine andere
Operation ausführt. Ein Beispiel sei auf x86 die Instruktion JE (Jump If
Equal). Eine zuvor erfolgte CMP-Instruktion (für Compare) setzt das Zero-Flag
(ZF). JE interpretiert ein positives ZF als gleichwertige Operanden und wird in
diesem Fall den Sprung ausführen und andernfalls zur nächstfolgenden Instruktion
fortschreiten. Obwohl die Operanden unangetastet blieben, wird bei der
Bit-Umkehr des Flags dennoch ein anderer Sprungeekt einsetzen.
• Register: Sofern das Bitmuster einer Instruktion einen variablen Zugri auf Register
ermöglicht, müssen auch diese als Operanden betrachtet werden. Verursacht
der Zugri primär keine Zugrisverletzung, tritt sekundär einer der ersten
drei erwähnten Fälle ein, da mit Sicherheit ein falscher Operand herangezogen
wurde.
• Befehle: Die Bitmanipulation einer Instruktion auÿerhalb der Operandenbits kann
5

2 Fehlerinjektion
weitreichende Konsequenzen haben. Ein beinahe wünschenswerter Fall ist der Tausch
des Operatoren, wie es durch einen Programmierfehler plausibel wäre: Wird das Bit
der x86-Instruktion JNE 0xF an der Bitposition zum Zählen sei der Operand gestrichen
0 geippt, und geht dieser sinngemäÿ die Instruktion CMP 1, 1 voraus,
so ergibt sich die Instruktion JE 0xF. C-äquivalent stellt dieser Fall ein irrtümliches
if(1!=1) { } statt des korrekten if(1==1) { } dar. Je nach Position des Bit-Flips
kann aber auch die Operation einer ganz anderen Klasse hervortreten. Auf Plattformen
mit variabler Instruktionslänge kann es sogar dazu kommen, dass ein Bit-Flip
eine Instruktion in mehrere kürzere Instruktionen zerfallen lässt oder die Bytes mehrerer
kurzer Instruktionen nun als eine Instruktion gedeutet werden.
2.3 Injektionsebenen
In diesem Abschnitt wird untersucht, ob und wie ein Bit-Flip auf Registerinhalten grundsätzlich
auf verschiedenen Ebenen der Erstellung und Ausführung eines Programms umsetzbar
ist.
2.3.1 Hardware
Die in Abschnitt 2.1 vorgestellten Hardwareansätze lassen zwar eine theoretische Möglichkeit
oen, Einuss auf Registerbits zu nehmen, in der Umsetzung stellen sich jedoch etliche
Hürden in den Weg: Von der zu untersuchenden Hardware ist eine tiefgehende Kenntnis
über den physikalischen Aufbau notwendig. Bei einer Technologieknotengröÿe im zweistelligen
Nanometerbereich ist nicht nur eine ebenso präzise Positionierung der Werkzeuge
nötig, sondern es ist auch sicherzustellen, dass der Wirkungsgrad auf ein einzelne Registerbits
beschränkt werden kann. Für Benutzer ohne die entsprechende Hardware steht dieser
Weg also auÿer Frage.
Ein anderer Ansatz ermöglicht ein eektiveres Vorgehen bei deutlich weniger Aufwand:
JTAG-normiertes On-Chip Debugging (OCD). Verfügt die Hardware über ein JTAG-
Interface, lässt sich durch eine zusätzliche Steuerkomponente, die als JTAG-Controller fungiert,
OCD durchführen. Der Controller setzt auf der Zielhardware einen Unterbrechungspunkt
und kann bei Erreichen desselben eine Sequenz von JTAG-Instruktionen ausführen,
die auch Lese- und Schreibvorgänge auf Benutzerregistern ermöglichen [11, S.103f]. Für
unwillkürliche Bitmanipulationen sind Kenntnisse zum Adressraum und Binärcode des zu
unterbrechenden Programms nötig.
2.3.2 Betriebssystem
Wann immer ein Wechsel vom Benutzermodus in einen ausreichend privilegierten Kernel-
Modus stattndet seien es Systemaufrufe, Unterbrechungsbehandlungen oder ein Kontextwechsel
, verfügt das Betriebssystem über volle Zugrisrechte auf den Prozesszustand
einschlieÿlich der Registerinhalte. An dieser Stelle ist zum Beispiel in Abhängigkeit der
Prozessidentikation und des Instruktionszeigers ein Bit-Flip ausführbar, sei es durch eine
festgeschriebene Betriebssystemroutine oder ein Kernel-Modul.
2.3.3 Virtuelle Maschine
Der Kernvorteil einer Virtuellen Maschine (VM) liegt darin, dem auszuführenden Programm
eine von der Hardware unabhängige Ausführungsmaschine anzubieten. Eine Rea-
6

2.3 Injektionsebenen
lisierung, die etwa die Java Virtual Machine verfolgt, ist die Verwendung von Operandenstacks,
die für die Instruktionen der VM benutzt werden [12, S.17]. Ein anderer Ansatz ist
die Benutzung von virtuellen Registern, sodass dem Programm eine beliebige Anzahl von
Speicherstellen zur Verfügung steht und jede VM-Instruktion für die Operanden entsprechende
Registerbezeichnungen verlangt.
Aus diesem Grund ist es nicht möglich, innerhalb einer VM die Abbildung eines Programms
auf Register der ausführenden CPU zu betrachten. Viel mehr ist es der virtuellen
Maschine selbst überlassen, an welcher Stelle und unter welchen Bedingungen diese Bitmanipulationen
vornehmen mag. Verfügt die VM über einen Just-In-Time (JIT)-Compiler,
anstatt Bytecode bloÿ zu interpretieren, sollte es dieser jedoch ein Leichtes sein, Bitmanipulationen
auf Registern in entsprechende Plattforminstruktionen zu übersetzen.
2.3.4 Kompilierungszeit
Zum Zeitpunkt des Schreibens des Programmquellcodes weiÿ der Entwickler nicht mit
etwas Erfahrung wird sein Bauchgefühl ihm jedoch eine Vorstellung ermöglichen , zu
welchem Zeitpunkt welche Variable in welches Register geladen und anschlieÿend gehalten
wird. Diese Entscheidungen trit der Compiler in Abhängigkeit von Datentypen, dem
Ergebnis der Registerallokationsoptimierung und anderen Optimierungsstufen. Aggressive
Optimierungsstufen wie etwa -O3 des GNU C Compiler (GCC) können sogar dazu führen,
dass aufgrund von statischer Zwischencodeanalyse ganze Codepassagen zur Kompilierungszeit
auf einen Ausdruck reduziert werden und dadurch nicht die erwartete Übersetzung
erfahren.
Ein erster Ansatz ist der Blick in den vom Compiler erzeugten Assemblercode, wie er
beim GCC mit dem Flag -S ausgegeben werden kann. Ausgestattet mit neuen Erkenntnissen
lieÿe sich der Quellcode mit plattformspezischen asm-Direktiven ausstatten, um
dadurch Bedingungen für die Manipulation von Registerbelegungen im Bereich von Interesse
aufzusetzen. Diese Lösung ist aufgrund der Abhängigkeit von verschiedenen Compilern,
Compiler-Versionen, Kongurationsparametern und Codeanpassungen jedoch zu
fragil. Auÿerdem nimmt sie zusätzlich die Plattformunabhängigkeit, wenn diese ohne asm-
Anweisungen gegeben ist.
Eine denkbare Alternative lieÿe sich mittels eines Compilers umsetzen, der seitens
des Quellcodes mit Makros dazu aufgefordert wird, Registermanipulationen vorzunehmen.
Auf diese Weise lassen sich verschiedene Operationen einstreuen, beispielsweise Bit-Flip im
Register X und Position i oder Bit-Flip beim nächsten Laden der Variable v in ein Register.
Eine Verfeinerungen des Verfahrens erlaubt, dass zusätzlich auf die Rekursionstiefe oder
einen Aufrufzähler Rücksicht genommen wird. Im Umkehrschluss bedeutet das, dass ein
Compiler entweder auf die Optimierung bestimmter Bereiche verzichten muss, oder dass
eine solche Code-Annotation nur bis zu einer gewissen Optimierungsstufe funktionieren
wird.
2.3.5 Programm
Ist ein Programm kompiliert und zusammengelinkt, verbleibt vor der Ausführung die Möglichkeit
zur statischen Binärinstrumentierung. Mit der Hilfe von Werkzeugen für Reverse
Engineering, etwa einem Disassembler und Assembler, kann der Assemblercode manuell
mit zusätzlichen Instruktionen ausgestattet werden. Per Hand ist das Vorgehen jedoch
mühselig, da die Ausgabe hochgradig von der Compiler-Konguration und dem Quellcode
abhängt. Erschwerend kommt hinzu, dass die hinzuzufügenden Instruktionen die bestehende
Funktionalität, insbesondere relative Sprünge und CPU-Flags, berücksichtigen müssen.
7

2 Fehlerinjektion
Mit einem Framework zur Disassemblierung und statischen Binärinstrumentierung, wie in
[13] und [14] vorgestellt, ist jedoch auch ein automatisiertes Vorgehen zu diesem Zweck
denkbar: Bei einem registerorienterten Bit-Flip kann die Codeinjektion auf einfache Weise
durch Zählung oder Zufall vorgenommen werden, wann immer dieses Register als Operand
implizit oder explizit von einer Instruktion benutzt wird. Bei einem belegungsorientierten
Bit-Flip ist zusätzlicher Aufwand nötig: Durch das Suchen von Ladeoperationen, die
Daten von einer gewählten Speicheradresse in ein Register kopieren, und das Finden von
nachfolgenden Instruktionen, die mit dieser Belegung operieren, lassen sich verschiedene
Injektionsbedingungen aufstellen. Sind Daten erst zur Laufzeit auösbar, etwa Adressen
mit einem registerbasierten Versatz, muss die Instrumentierung Code injizieren, der die
Erkennung von Ladequellen und Bitmanipulationen zur Ausführungszeit vornimmt.
Im Gegensatz zur Statischen Binäranalyse (SBA) wird bei der Dynamischen Binäranalyse
(DBA) der Binärcode zur Programmlaufzeit und auch erst kurz vor der Ausführung
durch die CPU analysiert und instrumentiert. Die Voraussetzungen dazu sowie die damit
einhergehenden Vor- und Nachteile werden ausführlicher in Abschnitt 3.1 behandelt.
Das im folgenden Kapitel vorgestellte Programm FITIn macht sich verschiedene Ansätze
zu Nutze, die in diesem Abschnitt vorgestellt wurden: die Kompilierungszeit und
die Anwendung eines DBI-Frameworks, das FITIn Instruktionen einer virtuellen Maschine
bereitstellt.
8

3 Erweiterung von FITIn
Dieses Kapitel stellt die Ausführungsumgebung von FITIn, seine ursprüngliche Fassung,
Erweiterungsansätze sowie die realisierte Implementierung vor.
3.1 Dynamische Binärinstrumentierung
Die dynamische Binäranalyse stellt einzig die Anforderung an das zu untersuchende Programm,
dass dieses in einem unterstützen Binärformat vorliegt. Der wesentliche Unterschied
zur SBA besteht darin, dass ein Programm erst als Prozess initialisiert wird, bevor
die erste Binäranalyse vorgenommen wird, und nicht als Datei auf dem Sekundärspeicher
untersucht und behandelt wird. Die SBA ist nur begrenzt in der Lage, Instruktionen zu
erkennen, die dem Ergebnis von Selbstextraktion, Selbstmodikation oder dynamischem
Erzeugen und Nachladen von Code entspringen, insbesondere dann nicht, wenn die genannten
Vorgänge von externen Eingaben abhängen [7, S.3f].
Gängige Anwendungsfälle sind Programme, die aus Gründen des Platzes oder der Ladeperformance
zum Beispiel UPX-komprimiert ausgeliefert werden, Programme, die Schutzmechanismen
zur Durchsetzung von digitalem Rechtemanagement besitzen, Plug-In-fähige
Programme und Programme, die einen prozessinternen JIT-Compiler benutzen.
Ein DBI-Framework initialisiert das zu untersuchende Programm analog zu einem Betriebssystem
und beginnt mit der DBA an der ersten Instruktion des Programms. Abhängig
vom Framework wird jede nachfolgende Instruktion oder auch ganze Blöcke von Instruktionen
an die DBI-Komponente übergeben und anschlieÿend ausgeführt. Auf diese Weise
wird im Unterschied zur SBA einzig tatsächlich auszuführender Code betrachtet, da sich die
DBA ausschlieÿlich an erreichten Sprüngen und Abzweigungen des Codes entlangbewegt.
Die Konsequenz ist, dass der Sprung in dynamisch erzeugten Binärcode für das DBI-
Framework transparent bleibt. Die Kehrseite des Verfahrens ist verständlicherweise ein
Einbruch in der Ausführungsgeschwindigkeit des Zielprogramms.
Eine weitere Herausforderung, die ein DBI-Framework meistern muss, besteht darin,
mit dem ausgeführten Programm nicht in Konikt zu treten oder solche Fälle angemessen
zu behandeln, seien es Adressräume im virtuellen Speicher, die zwischen Framework und
Prozess kollidieren könnten oder Ressourcen, auf die nur einer von beiden zur Zeit zugreifen
kann. Das DBI-Framework darf weiterhin nicht die Ausführungsgewalt verlieren, wenn
zum Beispiel durch einen Systemaufruf aus dem Kernel-Modus zurück in das Programm
gesprungen wird. In den Kernel-Modus kann das DBI-Framework nicht eingreifen. Legt
das Programm zusätzliche Threads an, sollte das DBI-Framework diese ebenbürtig zum
Hauptthread behandeln können.
Die Verwendung von DBI erfolgt allerdings nicht einzig aus der Motivation, Hindernisse
in der Analyse zu überwinden. Viel mehr erlaubt DBI eine weitere Analyseklasse:
Speicherbeschattung. Speicherbeschattung ist die Fähigkeit, jedes vom untersuchten Programm
verwendete Byte durch zusätzlichen Speicher zu beschatten [15, S.89]. Die Schattenwerte
genannten Daten werden dazu verwendet, Aussagen über das beschattete Byte
zur Laufzeit zu treen. Beispielsweise lassen sich so Daten darüber erheben, wie oft ein
Byte gelesen oder ob und wann es allokiert wurde. Diese Fähigkeit ermöglicht mächtige
9

3 Erweiterung von FITIn
Softwarewerkzeuge zur Laufzeitanalyse von Programmen.
Ein DBI-Framework mit lückenloser Unterstützung zur Speicherbeschattung muss nach
[15, S.90f] folgende Fähigkeiten bieten:
1. Die Beschattung aller Register.
2. Die Beschattung des gesamten Prozessspeichers.
3. Die Instrumentierung von Lese- und Schreiboperationen auf den Prozessspeicher.
4. Die Instrumentierung von Systemaufrufen, die auf den Prozessspeicher lesend oder
schreibend zugreifen.
5. Die Beschattung der initialen Speicherbelegung.
6. Die Instrumentierung von speicherallokierenden und -freigebenden Systemaufrufen.
7. Die Instrumentierung von Veränderungen am Stack-Zeiger.
8. Die Instrumentierung von (De-)Allokationen auf dem Heap-Speicher.
9. Ausgabemechanismen.
Das DBI-Framework Valgrind erfüllt alle der genannten Punkte [15, S.96f].
3.2 Valgrind
3.2.1 Allgemeines
Valgrind wurde im Jahr 2002 in seiner ersten oziellen Version veröentlicht, es steht
unter der GNU Public License (GPL). Bekannt ist dieses DBI-Framework insbesondere
durch das enthaltene Werkzeug Memcheck, das dazu benutzt wird, um Speicherzugrisfehler
und Speicherlecks in einem Programm zu ermitteln. Zur Standarddistribution von
Valgrind [16] gehören jedoch noch weitere DBA-Werkzeuge, zum Beispiel Cachegrind, das
die Cachefreundlichkeit des Programms analysiert, oder Helgrind, das Race Conditions
bei Multithreading erkennt. Zu den unterstützten Umgebungen gehören unterschiedliche
Kombinationen aus den Architekturen x86, AMD64, PowerPC, ARM, S390 und MIPS und
den Betriebssystemen Linux, Darwin und Android.
Die Infrastruktur von Valgrind ist so aufgebaut, dass jedes der genannten Werkzeuge
ein Plug-In darstellt, welches mit dem Parameter -tool= gestartet wird. Jedes Plug-In
fügt sich in den Kompilierungsvorgang der Valgrind-Distribution ein, der Quellcode dabei
ist wie auch für Valgrind in C zu schreiben.
3.2.2 Instrumentierung
Wichtig zu beleuchten, ist das interne Vorgehen von Valgrind, das Verhältnis des Framework-
Kerns zum geladenen Plug-In und auch die Art und Weise, wie Valgrind nicht-triviale
Probleme in Bezug auf die Ausführung und Speicherbeschattung behandelt.
Mit dem Spezizieren des zu untersuchenden Programms als Kommandozeilenargument
initialisiert Valgrind das Programm selbstständig, sodass aus der Sicht des Betriebssystems
nur Valgrind als Prozess erkennbar ist. Beginnend am Einstiegspunkt des Programms
stellt Valgrind sogenannte Superblocks (SB) zusammen, die für das weitere Vorgehen
als isolierte Codeabschnitte behandelt werden. Ein SB ist zusammengestellt, sobald
eine der folgenden Bedingungen erfüllt ist [15, S.93]:
• Eine plattformspezische Anzahl von Instruktionen wurde erreicht.
• Eine Instruktion für eine bedingte Codeabzweigung wurde erreicht.
• Ein Sprung zu einem Bereich, für den noch kein SB existiert, wurde gefunden.
10

3.2 Valgrind
• Es wurden drei Sprünge zu Adressen gezählt, für die bereits SBs angelegt worden
sind.
Ist der aktuell gewählte Block noch nicht dem Plug-In übergeben worden, übersetzt
Valgrind die nativen Instruktionen in eine eigene Repräsentation, die VEX Intermediate
Representation (VEX IR). Im Plug-In wird ein Callback aufgerufen, dem die VEX IR
übergeben wird. Es ist nun die Aufgabe des Plug-Ins, die VEX IR entsprechend seiner
Aufgabe zu analysieren und zu instrumentieren und die instrumentierte VEX IR an Valgrind
zurückzugeben, das die modizierte Fassung in native Instruktionen übersetzen wird.
Der Vorgang, den Binärcode vollständig in eine Zwischenrepräsentation zu übersetzen und
anschlieÿend in nativen Code zurückzuführen, wird Disassemble-and-Resynthesize (D&R)
genannt.
Dieser Vorgang wird je SB nur einmal ausgeführt. Ein Ausnahmefall ist selbstmodi-
zierender Code: Valgrind erkennt Veränderungen am Code und setzt die SBs dafür neu
zusammen.
Beginn
Wähle SB
Weiterer
SB?
ja
SB behandelt,
aktuell?
nein
nein
Disassemblierung
Instrumentierung
ja
Kompilierung
SB Ausführung
Ende
Abbildung 3.1: Programmausführung in Valgrind
Mit der letzten Instruktion eines SB kehrt der Prozess zurück in einen Codebereich
von Valgrind, in welchem der Code für den nächsten auszuführenden Block nachgeschlagen,
zuvor gegebenenfalls instrumentiert, und dann ausgeführt wird. In Abbildung 3.1
11

3 Erweiterung von FITIn
ist die Ausführungsbehandlung von Valgrind zusammengefasst und als Kontrollussgraph
dargestellt, einzig der Vorgang Instrumentierung involviert hier das Plug-In.
In Valgrind wird die Ausführung verschiedener Threads serialisiert. Ein Blockierungsmechanismus
stellt sicher, dass nur ein Thread zur Zeit SBs ausführen kann. So bendet
sich zusätzlich zur Prozesszeiteinteilung des Betriebssystems innerhalb von Valgrind ein
Zeitverwalter, der vorgibt, zu welchem Zeitpunkt ein Thread die Blockierung zugunsten
eines anderen aufgeben muss. Die Entscheidung wird jeweils nach der Ausführung eines
SB getroen [15, S.95f].
Eine weitere erwähnenswerte Eigenschaft von Valgrind ist die Behandlung von Systemaufrufen.
Ein Systemaufruf wird stets als eigenständiger SB behandelt, sodass der Valgrind
den Benutzercode in einen SB davor und in einen danach zerteilt. Zur Instrumentierungszeit
wird der Systemaufruf von Valgrind durch einen Sprung zu einem eigenen, spezischen
Wrapper ersetzt. Für jede unterstützte Architektur und für jedes unterstütze Betriebssystem
verfügt Valgrind Wissen über jeden einzelnen Systemaufruf, einschlieÿlich der Seiteneekte
auf den Prozessspeicher und auf die Benutzerregister. Der spezische Wrapper ruft
nun entsprechende Callbacks vor und nach der tatsächlichen Ausführung auf. Ein Plug-In
kann für die Ereignisse, von denen es abhängt, Callbacks registrieren, beispielsweise auf
die Ereignisse Ein lesender Registerzugri wird stattnden oder Ein Schreibvorgang auf
den Prozessspeicher hat stattgefunden. Geeignete Übergabeparameter im Callback erlauben
dem Plug-In eine lückenlose Verfolgung von Vorgängen, die im Zusammenhang mit
Systemaufrufen stehen.
Weitere Callbacks können bei Valgrind angemeldet werden, um dem Plug-In zum Beispiel
die Veränderung des Stack-Zeigers oder das Verlassen des Benutzercodes zu signalisieren.
3.2.3 VEX IR
Die von Valgrind genutzte Zwischendarstellung ist unabhängig von der Architektur, auf
welcher Valgrind benutzt wird. VEX IR liegt in Static Single Assignment-Form vor, sodass
jede Codevariable nur ein einziges Mal eine Zuweisung erfahren kann.
Das Plug-In erhält mit dem Instrumentierungs-Callback einen Zeiger auf eine IRSB-
Struktur, die die VEX IR eines SB in Form einer Liste enthält. Die für die Beschreibung
der Implementierung von FITIn essentiellen Datentypen der VEX IR sind:
• IRTemp: Eine VEX IR-Variable. Angaben zu dieser bezüglich des Datentyps in Form
von IRType benden sich in der IRSB-Kontextstruktur IRTypeEnv.
• IRExpr: Ein VEX IR-Wrapper für alle Daten, die einen Ausdruck darstellen. Dazu
gehören als Unterstrukturen innerhalb eines union:
• Const: Ein konstanter, numerischer Wert.
• Get: Der Registerinhalt an der angegebenen Position der Registerschattentabelle.
Diese Tabelle dient dazu, dass Valgrind zur Ausführungszeit Speicherbereiche
bereitstellen kann, die ersatzweise dem Datenaustausch über Register dienen.
• Load: Der Inhalt an einer Speicheradresse.
• RdTmp: Der Wert eines IRTemp.
• {Un,Bin,Tri,Q}op: Ausdrücke, die bis zu vier Argumente erwarten, etwa logische
oder mathematische Operatoren.
• IRStmt: Der Typ einer VEX IR-Instruktion und Datentyp der Instruktionsliste von
IRSB. Wichtige Instruktionen sind:
• Dirty: Der Aufruf einer unreinen Hilfsmethode eine Methode, deren Operation
12

3.2 Valgrind
1 MOV EAX , [ EAX -8]
2 ADD EAX , 1
3 IMUL EAX , [ EAX -8]
1 ------ IMark (0 x8048400 , 3, 0) ----
2 t30 = Add32 (t23 ,0 xFFFFFFF8 : I32 )
3 t32 = LDle : I32 ( t30 )
4 ------ IMark (0 x8048403 , 3, 0) ----
5 t8 = Add32 (t32 ,0 x1 : I32 )
6 PUT (68) = 0 x8048406 : I32
7 ------ IMark (0 x8048406 , 4, 0) ----
8 t33 = Add32 (t23 ,0 xFFFFFFF8 : I32 )
9 t11 = LDle : I32 ( t33 )
10 t13 = Mul32 (t11 , t8 )
Abbildung 3.2: Disassemblierung in Valgrind: x86-Programm (li.), VEX IR (re.)
nicht einzig von den Parametern abhängt , der in einem IRDirty konguriert
wurde.
• Mark: Das Vorkommen eines solchen Markers trennt die Übersetzung zweier
nativer Instruktionen voneinander.
• Put: Das Schreiben eines IRExpr an eine angegebene Position in der Registerschattentabelle.
• Store: Das Schreiben eines IRExpr an eine Speicheradresse.
• WrTmp: Die Zuweisung eines IRExpr zu einem IRTemp.
Eine vollständige Spezikation der Sprache bendet sich im Anhang A.1. Nachdem etwa
das Plug-In die VEX IR eines SB instrumentiert hat, führt Valgrind die instrumentierte
VEX IR auf einer virtuellen CPU aus, die Instrumentierungsfehler der VEX IR ermittelt.
Im Fall eines Fehlers wird die Ausführung abgebrochen.
Ein Beispiel für die textuelle Darstellung der VEX IR und für die Übersetzung von
x86-Instruktionen nach VEX IR ist in Abbildung 3.2 gegeben. Die ersten beiden Parameter
eines jeden IMark geben Auskunft über die ursprüngliche Adresse der Instruktion
und über die Originalgröÿe in Bytes. Im Beispiel der VEX IR in Zeile 6 wird die Adresse
der nachfolgenden Instruktion in die Registerschattentabelle an den Index 68 geschrieben:
Auf der x86-Architektur bendet sich für Valgrind an dieser Stelle der Instruktionszeiger
EIP. Die Instruktion der Zeile 6 ist überüssig, jedoch kennt der Optimierungsalgorithmus
von Valgrind diesen Index nicht als Instruktionszeiger. Nicht einmal die Ursprungsplattform
ist ihm bekannt. In der nicht-optimierten Fassung existiert für jede Instruktion eine
vollständige Beschreibung aller für die VEX IR relevanten Prozessoreekte einschlieÿlich
der Adresse der nächstfolgenden Instruktion, auf x86-Computern gesehen als Zuweisung
der Adresse an EIP. Aus diesem Grund können Redundanzen in der VEX IR auftreten,
für deren Beibehaltung aus der Sicht des Optimierers jedoch im Kontext des nicht vollständig
aufgeführten IRSB eine Notwendigkeit besteht. Im Gegensatz dazu werden in
diesem Beispiel die Flag-Eekte komplett eliminiert, etwa das Aktualisieren des ZF nach
der Addition, da keine nachfolgende VEX IR-Operation auf diesen Flag-Zustand zugreift.
Die Abbildung 3.3 erlaubt einen detaillierten Blick auf die D&R-Technik von Valgrind.
Zu den VEX IR-Ausdrücken IRExpr sei angemerkt, dass einige Typen grundsätzlich eine
beliebige Schachtelungstiefe ermöglichen. Aus Gründen der besseren Optimierbarkeit und
einer einfachen Instrumentierung durch das Plug-In linearisiert Valgrind die VEX IR jedoch
so, dass die Ausdruckstiefe nicht gröÿer als 1 ist. Für tiefer gelegene Ausdrücke wird
für den Elternausdruck E i ein eigenes IRTemp t |env|+1 mittels einer WrTmp-Instruktion geschaen
und E i im Ursprungsknoten durch ein RdTmp auf t |env|+1 ersetzt, solange bis die
Ausdruckstiefe normalisiert ist. env sei dabei die Menge von bereits vergebenen IRTemp-
13

3 Erweiterung von FITIn
Indizes innerhalb des aktuellen IRSB.
Die nach der Instrumentierung stattndenden Schritte entsprechen dabei dem klassischen
Compiler-Konzept ab dem Punkt, ab dem der Code in einer Zwischenrepräsentation
vorliegt: Optimierung der Repräsentation, die Wahl der Instruktionen, die Registerallokation
und die Übersetzung in den letztendlichen Binärcode.
Beginn
Disassemblierung
Linearisierung,
Optimierung
Instrumentierung
Optimierung
Baumbildung
Instruktionswahl
Registerwahl Binärcode Ende
Abbildung 3.3: Disassemble-and-Resynthesize in Valgrind
Abschlieÿend zu diesem Unterpunkt seien die wesentlichen Vorteile, die Valgrind aus
der Sicht eines Plug-In-Entwicklers bietet, aufgeführt:
• Abstraktion der Architektur: Der Entwickler steht nicht unter dem Druck, jede einzelne
CPU-Instruktion detailliert kennen zu müssen, um überhaupt eine einzige Plattform
vollständig unterstützen zu können. Diese Arbeit wird komplett von Valgrind
übernommen und ermöglicht die Plattformunabhängigkeit des Plug-Ins.
• Abstraktion des Betriebssystems: Analog muss dem Entwickler nicht jeder einzelne
Systemaufruf aller unterstützten Betriebssysteme vollständig geläug sein. In Valgrind
wird dieses Problem elegant gelöst, da ausschlieÿlich das Framework dieses
Wissen besitzen muss, sodass der Entwickler sich einzig um bestimmte Ereignisklassen
zu kümmern hat.
• Serialisierung der Parallelität: Es ist nicht erforderlich, als Entwickler etwas über
das Multithreading-Verhalten des Programms zu kennen. Ebenso kann sich der Entwickler
der Tatsache sicher sein, dass zu jedem Zeitpunkt stets nur ein SB ausgeführt
wird und Unterbrechungen eektiv nur zum Zeitpunkt von SB-Übergängen stattnden.
Die Rechnung dafür hat der Anwender in der Form zu bezahlen, dass Valgrind
die Interaktivität des Programms einschränkt und Performancegewinne, die durch
echte Parallelausführung bedingt sind, einstreicht.
Umgekehrt betrachtet, zwingt der erstgenannte Punkt den Entwickler dazu, den Benutzercode
nicht weiter als die übergebene VEX IR betrachten zu dürfen. Die Prämisse,
mit der Hilfe von Valgrind ein plattformspezisches oder -optimiertes Werkzeug entwickeln
zu können, muss grundsätzlich verworfen werden. Dadurch ist ein Plug-In für Valgrind vergleichbar
mit einer Instrumentierungskomponente in einer virtuellen Maschine.
Weiterhin darf man nicht die Behauptung aufstellen, dass ein Plug-In von Valgrind
an sich ein reines DBI-Werkzeug sei: Schlieÿlich wird die von Valgrind übergebene Zwischenrepräsentation
lediglich einmal zu einem transparenten Zeitpunkt vor der erstmaligen
Ausführung instrumentiert, und sie zwingt dadurch den Entwickler dazu, streng zwischen
dem Zeitpunkt der Instrumentierung und dem Zeitpunkt der Ausführung zu unterscheiden.
14

3.3 FITIn
3.3 FITIn
FITIn ist ein von Clemens Terasa entwickeltes Plug-In für Valgrind, das dem Zweck dient,
einen Bit-Flip im Prozessspeicherraum zur Ausführungszeit des Programms vorzunehmen.
Die Motivation hinter diesem Programm ist die Evaluierung von SIHFT-Maÿnahmen [17,
S.21]. In diesem Abschnitt wird beschrieben, wie die ursprüngliche Fassung funktioniert.
An erster Stelle steht die Notwendigkeit, dass dem Benutzer der Programmquellcode,
geschrieben in C oder C++, vorliegt. Eine von FITIn erstellte C-Header-Datei
fitin.h, welche sich im Verzeichnis include der Valgrind-Distribution bendet, muss
mittels #include-Makro eingebunden werden. Dadurch stehen dem Entwickler die zur
Instrumentierung benötigten Makros zur Verfügung: FITIN_MONITOR_VARIABLE(var) und
FITIN_MONITOR_MEMORY(mem, size). Diese Makros stellen sogenannte Valgrind Client Requests
dar: Der Compiler erweitert den Stack um einen Identiziererwert und fünf weitere
Werte in Plattformadressbreite, die Ganzzahlen oder Adressen sein dürfen. Valgrind ist in
der Lage, den Identizierer dem Plug-In zuzuordnen und übergibt diesem mittels Callback
die bis zu fünf Argumente. Im Falle von FITIn werden zwei Argumente verwendet: Startadresse
und Gröÿe des Bereichs, nach dem das Plug-In Ausschau halten soll. Intern wird
jede Beobachtungsauorderung als Monitorable-Struktur in eine Liste aller zu beobachtenden
Bereiche abgelegt.
Im nächsten Schritt muss der Compiler eine Debug-Version des Programms erzeugen,
da eventuell Variablen beobachtet werden, die nicht unmittelbar im Stack-Speicher von
main verwendet oder referenziert werden. Selbst bei einem kleinen Programm durchläuft
Valgrind eine drei- bis vierstellige Anzahl von SBs. Aus Gründen der Performance und der
letztendlichen Benutzungsabsicht ist es nicht erforderlich, SBs, die nicht zum Benutzercode
gehören, etwa die der C-Standardbibliothek, zu analysieren. Um dieses Vorgehen zu
erlauben, muss es Valgrind jedoch möglich sein, die Prozedurzugehörigkeit des aktuellen
SB ermitteln zu können. In einer Debug-Version sind Informationen wie der aktuelle Prozedurname
in das Programm eingebettet. Der Benutzer ist in diesem Fall dazu aufgefordert,
bei Prozeduren, die nicht main sind, mit dem Kommandozeilenargument --fnname= die zu
analysierende Prozedur zu bestimmen oder durch --include= Valgrind mitzuteilen, welche
SBs in Angabe des Quellcodeverzeichnisses zum Benutzercode gehören.
Mit der Auorderung, dass Valgrind das Plug-In FITIn laden soll, kann das Programm
im Sinne von FITIn benutzt werden. Zusätzlich sind die Kommandozeilenargumente
--mod-bit= und --mod-load-time= anzugeben. --mod-load-time=n weist FITIn
an, vor dem n-ten Lesezugri auf den Speicher des zutreenden Monitorable am Bit m aus
--mod-bit=m einen Bit-Flip durchzuführen. Zutreend bezeichnet dabei das Monitorable,
das im Rahmen des für alle Monitorable geltenden Zählers getroen wurde. Mit dem Argument
--inst-limit= kann die Anzahl der insgesamt ausgeführten Instruktionen durch das
Programm ohne die der Instrumentierung, der Ausführungshilfsmethoden von FITIn und
des Valgrind-Kerns begrenzt werden, etwa um nach einem Bit-Flip eine Endlosschleife
zu verhindern.
Möchte der Benutzer lediglich einen Eindruck vom Lesezugrisverhalten des Programms
auf Variablen inner- und auÿerhalb eines Monitorable erlangen, kann er einen
Golden Run-Durchlauf ausführen (Kommandozeilenargument --golden-run=yes), der keinen
Bit-Flip vornehmen wird.
Der Instrumentierungsprozess lässt sich wie folgt beschreiben: Vor jedem IMark fügt
FITIn einen IRDirty-Aufruf namens incrInst ein, dessen Aufgabe es ist, die Anzahl
der originalen Instruktionen zu zählen und bei gesetztem Limit und der Überschreitung
dessen die Ausführung abzubrechen. Stöÿt FITIn in einem relevanten SB auf eine Load-
15

3 Erweiterung von FITIn
1 MOV EBX , [ EBP -8]
2 MOV EAX , EBX
3 ADD EAX , 1
4 IMUL EAX , EBX
1 ------ IMark (0 x8048400 , 3, 0) ----
2 t26 = Add32 (t19 ,0 xFFFFFFF8 : I32 )
3 t28 = LDle : I32 ( t26 )
4 PUT (20) = t28
5 ------ IMark (0 x8048403 , 2, 0) ----
6 ------ IMark (0 x8048405 , 3, 0) ----
7 t8 = Add32 (t28 ,0 x1 : I32 )
8 ------ IMark (0 x8048408 , 3, 0) ----
9 PUT (40) = 0 x27 : I32
10 PUT (44) = t28
11 PUT (48) = t8
12 PUT (52) = 0 x0 : I32
13 t13 = Mul32 (t28 , t8 )
14 PUT (68) = 0 x804840B : I32
Abbildung 3.4: Registerübersetzung in Valgrid: x86-Programm (li.), VEX IR (re.)
Instruktion, fügt es einen weiteren Aufruf vor diesem ein: preLoadHelper. Dieser Methode
wird zur Laufzeit die Ladeadresse der nachfolgenden Instruktion übergeben: Sie iteriert
über alle aktiven Monitorable und prüft dabei, ob die gespeicherten Angabe zur Startadresse
der der Ladeinstruktion entspricht. In diesem Fall wird der globale Zugriszähler
um 1 erhöht. Erreicht der Zähler den Wert von --mod-load-time=, führt die Methode auch
den Bit-Flip auf der Speicheradresse aus.
In jedem Programmdurchlauf kann maximal ein einzelner Bit-Flip vorgenommen werden.
3.4 Registerbehandlung in Valgrind
In Abschnitt 3.2.3 wurde bereits ein Einblick in das Übersetzungsverfahren von Instruktionen
in Valgrind gegeben. In Hinblick auf die Erweiterung von FITIn, Bit-Flips auch auf
Registern vornehmen zu können, muss die VEX IR jedoch noch etwas weiter betrachtet
werden.
Im Beispiel 3.4 nden die x86-Operationen nach dem Laden eines Werts vom Stack vollständig
auf den Registern EAX und EBX statt. Die gezeigten IMark-Abschnitte entsprechen
den Ursprungsinstruktionen, wie es sich durch den Vergleich verschiedener D&R-Schritte
von Valgrind ermitteln lässt (Benutzung des Parameters --trace-flags= auf den entsprechenden
SBs). Dieses Beispiel wird im Folgenden genauer erläutert:
• IMark(0x8048400): Die EBP-versetzte (t19) Ladeadresse wird von t26 referenziert,
der Ladewert anschlieÿend nach t28 geladen und an den Index 20 der Registerschattentabelle
geschrieben, welcher korrekt das Register EBX bezeichnet.
• IMark(0x8048403): Dieser Befehl wurde komplett eliminiert, es ist also nicht erkennbar,
dass ein Register in ein anderes kopiert wurde (EBX nach EAX).
• IMark(0x8048405): Die Addition des in t28 referenzierten Wertes um 1 ndet statt,
jedoch wird das Ergebnis t8 nicht zum Aktualisieren eines Registers benutzt.
• IMark(0x8048408): t28 wird mit t8 multipliziert. Es ndet jedoch erneut keine Registeraktualisierung
(durch t13) statt. Die Indizes 40, 44, 48 und 52 werden mit
Werten belegt, die Valgrind zur Behandlung der Flag-Eekte benutzt.
Anhand des Beispiels 3.4 wird deutlich, dass eine ursprungsgetreue Abbildung der
Registerbenutzung nicht gegeben ist. Es ist also nicht möglich, etwa vor Beginn oder am
Ende eines IMark Instruktionen einzufügen, die, in Erwartung eines konsistenten Zustands
16

3.5 Evaluierung von Ansätzen
1 MOV EBX , [ EAX -8]
2 MOV [ EBP +0 x14 ], EBX
3 LEA ECX , [ EBX +0 x1 ]
4 MOV [ EBP +0 x28 ], 0 x27
5 MOV [ EBP +0 x2C ], EBX
6 MOV [ EBP +0 x30 ], ECX
7 MOV [ EBP +0 x34 ], 0 x0
8 MOV [ EBP +0 x44 ], 0 x804840B
9 MUL EBX , ECX
Abbildung 3.5: Ergebnis der x86-Codesynthese
der Registerschattentabelle, einen Bit-Flip auf dem entsprechenden Eintrag vornehmen
können. Die Abbildung 3.5 verdeutlicht weiterhin, wie sehr die operationelle Semantik des
Ursprungscodes in Abbildung 3.4 verändert wird.
Der Optimierer von Valgrind ermittelt beim Disassemble-Vorgang nicht nur, welche
Operationen im aktuellen IRSB eliminiert werden können, sondern es werden darüber hinaus
alle Paare von PUT-GET-Instruktionen auf demselben Oset entfernt, wenn die Belegung
über den IRSB hinaus nicht relevant ist.
Weitere Konsequenzen auf die operationelle Semantik, die durch den Compiler von
Valgrind bedingt sind:
• Valgrind nimmt anhand des Datenussgraphen eine eigenständige Registerallokation
vor.
• Nicht alle CPU-Instruktionen werden für die Kompilierung unterstützt. So kann Valgrind
auf x86-Hosts lediglich SSE- und SSE2-Instruktionen erzeugen.
• PUT- und GET-Instruktionen werden nicht zwangsläug als Registeroperationen umgesetzt.
Wie in Abb. 3.5 zu erkennen ist, wird der Befehl PUT(20) = t28 zu MOV
[EBP+0x14], EBX übersetzt. Tatsächlich werden auf x86 PUT-Instruktionen bei einer
Quellgröÿe von 4 Byte als MOV-Operationen mit einer Zielspeicheradresse realisiert.
In Bezug auf die Registerbehandlung lässt sich zusammenfassend behaupten: Dem
Plug-In wird die ursprüngliche Registerbelegung vorenthalten, es ist für das Plug-In nicht
abzusehen, welche Register zur Ausführung benutzt werden und auch nicht, zu welchem
Zeitpunkt welche Daten überhaupt in Registern gehalten werden.
Im folgenden Abschnitt wird beleuchtet, wie diese und andere Gegebenheiten sich auf
die Wahl einer Strategie für die Erweiterung von FITIn auswirken.
3.5 Evaluierung von Ansätzen
Unabhängig von technischen Rahmenbedingungen, die etwa ein Framework wie Valgrind
vorgibt, kommt eine zentrale Frage dabei auf, wenn man ein Werkzeug zur Bitmanipulation
von Registern konzipieren möchte: Wie soll es benutzbar sein? Insbesondere vor dem Hintergrund,
dass ein Anwender lediglich eine Bedienungsanleitung durchlesen möchte, und
nicht den Quellcode des Instrumentierers, um dessen Anwendung hinreichend zu verstehen.
In diesem Abschnitt werden zwei mögliche Ansätze vorgestellt, die einem Benutzer
bei der Verwendung von FITIn zusätzlich zur bestehenden Funktionalität dazu dienen
könnten, gezielt Bit-Flips auf Registern vorzunehmen.
17

3 Erweiterung von FITIn
1 unsigned char result = 0 x42 ;
2 asm (" movl $7 , % eax ");
3 asm (" movl %% eax , %0 ":"=m"(
result ));
4 printf ("%d\n" , result );
1 MOV [ ESP +31] , 66
2 MOV EAX , 7
3 MOV BYTE PTR [ ESP +31] , EAX
4 MOVZX EAX , BYTE PTR [ ESP +31]
5 MOVZX EAX , AL
6 MOV DWORD PTR [ ESP +4] , EAX
7 MOV DWORD PTR [ ESP ],
OFFSET FLAT : .LC0
8 CALL printf
Abbildung 3.6: Beispiel für Ansatz I, C-Programm (li.), VEX IR (re.)
Ansatz I: Registerorientierter Bit-Flip
Dem Benutzer steht zusätzlich zu den vorhandenen FITIn-Makros das Makro namens
FITIN_FLIP_REG(reg) zur Verfügung. Das Argument ist eine Nummer, die abhängig von
der Ausführungsplattform speziziert ist und auf den Index der Registerschattentabelle
übersetzt wird. Der Benutzer fügt dieses Makro an der gewünschten Stelle im Quellcode seines
Programms ein und wählt die Nummer des Registers, auf welchem zu diesem Zeitpunkt
ein Bit-Flip vorgenommen werden soll. Zusätzlich wird per Kommandozeilenargument das
Bit gewählt, das zu invertieren ist.
Es sei in Abbildung 3.6 ein Minimalprogramm vorgestellt, das mittels Inline-Assembler
sicherstellt, dass die Konstante 7 zuerst in das Register EAX und anschlieÿend in die Variable
result kopiert wird. Die erwartete Ausgabe ist 7.
Es sei folgendes Szenario gegeben: Der Benutzer möchte vor dem Zurückschreiben im
Register EAX ein Bit umkehren. Dazu fügt er nun das Makro FITIN_FLIP_REG(0), wobei 0
für das Register EAX speziziert sei, zwischen die beiden asm-Instruktionen ein. Abbildung
3.7 zeigt den modizierten C-Code und die resultierenden x86-Instruktionen.
1 unsigned char result = 0 x42 ;
2 asm (" movl $7 , % eax ");
3 FITIN_FLIP_REG (0) ;
4 asm (" movl %% eax , %0 ":"=m"(
result ));
5 printf ("%d\n" , result );
1 MOV BYTE PTR [ ESP +19] , 66
2 MOV EAX , 7
3 MOV DWORD PTR [ ESP +24] ,
1179189257
4 MOV DWORD PTR [ ESP +28] , 0
5 MOV DWORD PTR [ ESP +32] , 0
6 MOV DWORD PTR [ ESP +36] , 0
7 MOV DWORD PTR [ ESP +40] , 0
8 MOV DWORD PTR [ ESP +44] , 0
9 LEA EAX , [ ESP +24]
10 [ ... ]
11 MOV EAX , DWORD PTR [ ESP
+20]
12 MOV BYTE PTR [ esp +19] , EAX
13 [ ... ]
Abbildung 3.7: Ansatz I: Zu x86-Programm (re.) kompilierter C-Code (li.)
Die Zeilen 1, 2 und 12 des Assemblercodes gehören zum bewusst erzeugten Code, die
Zeilen 3 bis 8 zeigen die Stack-Erweiterung, die durch den Valgrind Client Request erzeugt
wird. Das Debakel wird deutlich, wenn man die Zeile 9 betrachtet: Ohne eine Sicherung
von EAX wird der Wert 7 überschrieben, folglich wird ein anderer Wert ausgegeben.
18

3.6 Erweiterung
Ein derartiges Vorgehen erfordert, dass der Anwender ständig zu überprüfen hat, ob
das gewählte Register nicht durch ein Valgrind-Makro überschrieben wurde. Schlieÿlich
ist dem Compiler nicht bekannt, dass das Argument 0 des Makros den Registerinhalt von
EAX bewahren soll. Die ganze Anwendung würde damit schon von vornherein ad absurdum
geführt werden. Dieser Ansatz entpuppt sich als untauglich.
Ansatz II: Bit-Flip nach Schreibzugrien auf Register
Ein anderer Ansatz erfordert keine Modikation des Quellcodes. Stattdessen speziziert
der Benutzer mittels Kommandozeile Register, Bit und Zeitpunkt des Schreibens: Die Erweiterung
zählt die Vorkommen der PUT-Instruktionen in den zugelassenen SBs auf das
angegebene Register und führt bei Übereinstimmung des Zählers mit der Spezikation
nach dem Schreiben auf das Register einen Bit-Flip durch. Es sei in Abbildung 3.8 ein Beispiel
gegeben: Der Benutzer möchte ein beliebiges Bit an Register ECX invertieren, nachdem
die Konstante 15 hineingeschrieben wurde.
1 unsigned char result = 0 x42 ;
2 asm (" movl $15 , % ecx ");
3 asm (" movl %% ecx , %0 ":"=m"(
result ));
4 printf ("%u\n , result )
1 ------ IMark (0 x804846C , 5, 0) ----
2 PUT (12) = 0 xF : I32
3 PUT (68) = 0 x8048471 : I32
4 ------ IMark (0 x8048471 , 4, 0) ----
5 t8 = GET : I32 (24)
6 t7 = Add32 (t8 ,0 x1F : I32 )
7 STle ( t7 ) = 0 xF : I32
8 PUT (68) = 0 x8048475 : I32
Abbildung 3.8: Beispiel für Ansatz II, C-Programm (li.), VEX IR (re.)
Erneut fällt ein Problem ins Auge, dieses Mal durch die Optimierung seitens Valgrind:
Selbst wenn nach der Zeile 2 (in VEX IR) die Registerschattentabelle an Index 12 um ein
Bit korrumpiert wurde, ndet der nächste sinngemäÿe Zugri auf Register ECX in Zeile 7
statt, an welcher der Registerwert zurück an eine Speicheradresse geschrieben wird. Anstatt
des Zugris auf das Register durch einen GET-Ausdruck ist an dieser Stelle die propagierte
Konstante 0xF zu nden. Eine Manipulation der Registerschattentabelle bliebe hier somit
ohne Auswirkung und die Ausgabe würde keine Veränderung erkenntlich machen.
So existiert auch für diesen Ansatz ein Fall, der nicht das gewünschte Ergebnis liefert.
Berücksichtigt man die bisher gewonnenen Erkenntnisse und die Tatsache, dass in Valgrind
einzig der Datenussgraph der IRTemp zuverlässig die Programmsemantik abbildet, so muss
man einen anderen Weg einschlagen. Dieser wird im nächsten Abschnitt vorgestellt.
3.6 Erweiterung
Dieser Abschnitt stellt die Implementierung vor, die FITIn dahingehend verändert, dass
Bit-Flips nicht weiter vor dem Lesen des Arbeitsspeichers vorgenommen werden.
Die vorherigen Analysen haben gezeigt, dass registerfokussierte Ansätze in Valgrind
kein konsistentes Vorgehen für einen Bit-Flip auf einem Register ermöglichen. Die x86-
Plattform verfügt darüber hinaus über mathematische Instruktionen, die Operanden nicht
einmal in einem Register erwarten, sondern mittels Adresse direkt auf dem Prozessspeicher
arbeiten. Dadurch fällt zusätzlich die Annahme, dass jede Ladeoperation der VEX IR
ursprünglich die Kopie von Daten in ein Register darstelle.
Es sei in Abbildung 3.9 ein x86-Beispiel gegeben, das das ursprüngliche FITIn an seine
19

3 Erweiterung von FITIn
Grenzen führt: Es sind drei ganzzahlige Variablen auf dem Stack gegeben, seien sie a, b
und c genannt (für die Adressen EBP-12, EBP-8 und EBP-4). Die abgebildeten Operationen
entsprechen in C-Code b += a; und c *= a;.
1 MOV EAX , [ EBP -12]
2 MOV EDX , [ EBP -8]
3 ADD EDX , EAX
4 MOV [ EBP -8] , EDX
5 MOV EDX , [ EBP -4]
6 IMUL EDX , EAX
7 MOV [ EBP -4] , EDX
1 ------ IMark (0 x80483EC , 1, 0) ----
2 t0 = GET : I32 (28)
3 t24 = GET : I32 (24)
4 t23 = Sub32 (t24 ,0 x4 : I32 )
5 [...]
6 ------ IMark (0 x8048407 , 3, 0) ----
7 t32 = Add32 (t23 ,0 xFFFFFFF4 : I32 )
8 t34 = LDle : I32 ( t32 )
9 [...]
10 t10 = Add32 (t37 , t34 )
11 [...]
12 t17 = Mul32 (t34 , t43 )
Abbildung 3.9: Grenzbeispiel für FITIn, x86-Programm (li.), VEX IR (re.)
Zu erkennen ist, dass das Ergebnis des Ladevorgangs von a in das Register EAX mit dem
IRTemp t34 beschrieben ist. t34 wird in diesem IRSB zwei Mal verwendet: als Argument
der Anweisungen zur Addition Add32(t37,t34) und der Multiplikation Mul32(t34,t43)
(analog stehen t37,t43 für a,b).
Sei die Variable a vom Benutzer im Quellcode mit einem Makro versehen und sei der
Fehlerinjektionszeitpunkt zur Operation b += a; gewählt: preLoadHelper wird vor der
WrTmp-Instruktion von t34 eingefügt und nimmt zur Ausführungszeit den Bit-Flip auf dem
Prozessspeicher vor, sodass alle zukünftigen Ladeoperationen auf dieser Adresse ebenfalls
einen modizierten Wert lesen werden.
Diese Implementierung stellt den Benutzer allerdings vor ein Problem, wenn der Bit-
Flip erst vor Ausführung der Operation c *= a; stattnden soll. Auch wenn das Szenario
gegeben sein kann, dass der Compiler a vor der zweiten Operation tatsächlich neu laden
lässt, ist es wie hier bisher unmöglich, den im Register gehaltenen Wert erst bei erneuter
Verwendung zu manipulieren.
Betrachtet man jedoch die Tatsache, dass ein Plug-In in dieser VEX IR feststellen
kann, wo t34 verwendet wird, so erönet sich eine deutlich präzisere Betrachtung des Variablenzugris.
Zusätzlich verringert es die Notwendigkeit, dass der Benutzer zuerst durch
Betrachtung der Assemblerausgabe oder durch Variieren der Quellcode-Annotation und
des Manipulationszeitpunkts selbst ermitteln muss, ob Daten zu einem Zeitpunkt überhaupt
erneut aus dem Speicher ausgelesen werden. Hier wird die Erweiterung von FITIn
ansetzen.
3.6.1 Betrachtete Operationen
In diesem Unterabschnitt werden die technischen Gegebenheiten mit den Erkenntnissen
über die zukünftige Benutzung von FITIn zusammen betrachtet und es wird erläutert,
welche Arbeit notwendig ist, um eine möglichst allumfassende Lösung zu entwickeln.
Die im nachfolgenden genannten Fälle von VEX IR-Vorkommen und Valgrind-Ereignissen
sind für die Erweiterung von FITIn von Relevanz:
• WrTmp-Instruktionen, die ein neues IRTemp durch einen Load-Ausdruck einführen. Das
Plug-In hat zu erkennen, welche Ladeadresse verwendet wird und zu entscheiden, ob
diese zu einer überwachten Speicheradresse gehört.
20

3.6 Erweiterung
• IRTemp-Variablen, auf die in einem RdTmp-Ausdruck zugegrien wird. Es muss zur
Instrumentierung ermittelbar sein, ob ein verwendetes IRTemp einem Ladeausdruck
entstammt. Zur Ausführungszeit muss erkannt werden, ob dabei auf ein Monitorable
zugegrien wird. Im positiven Fall hat bei Erreichen des Zugriszählers der Bit-Flip
vor der Ausführung zu erfolgen.
• PUT-Instruktionen: Belegungen der Registerschattentabelle können über den SB hinaus
verwendet werden, etwa für Systemaufrufe, aber auch intern für Hilfsmethoden
von Valgrind. FITIn muss feststellen, ob eine solche Instruktion Daten, die von Interesse
sind, in der Tabelle ablegt.
• IRDirty-Aufrufe: Valgrind fügt selbstständig Hilfsaufrufe dieser Art ein, um Instruktionen
zu behandeln, die nicht allein durch VEX IR abbildbar sind. Zu ermitteln ist,
ob diese lesend auf die Registerschattentabelle oder den Prozessspeicher zugreifen.
In einem solchen Fall ist zu prüfen, ob es sich dabei um relevante Datenbereiche
handelt, um zuvor gegebenenfalls einen Bit-Flip auszuführen. Dieser Fall blieb von
FITIn bisher unberücksichtigt.
• Systemaufrufe: Systemaufrufe wurden von FITIn bisher ebenso ignoriert. Das Plug-
In muss bei Valgrind entsprechende Callbacks eintragen, die vor dem Lesen eines
Registers oder des Prozessspeichers den Zugri analysieren, um eventuell eine Fehlerinjektion
vorzunehmen.
3.6.2 Instrumentierungszeit
Die Datenstrukturen, die FITIn bereits enthält, können beibehalten werden: Monitorable
als Repräsentation einer Speicheradresse, die überwacht werden soll aber auch deaktiviert
werden kann und toolData, das die gesamte Konguration von FITIn sowie Datenstrukturen
zur Ausführungszeit enthält, beispielsweise eine Liste aller Monitorable, die vom
Typ XArray ist. Es existiert von dieser Struktur innerhalb von fi_main.c eine globale
Variable mit dem Namen tData. Da andere C-Dateien auf diese allerdings keinen Zugri
haben, wird tData vielen Funktionen der Erweiterung als Argument übergeben.
XArray ist eine Datenstruktur, die von Valgrind bereitgestellt und auch für die Erweiterung
von FITIn benutzt wird. Es handelt sich dabei um eine sortierbare Liste, an deren
Ende Elemente eingefügt werden können. Die Operationen addToXA(XArray*, void*) und
indexXA(XArray*, Word), zum Einfügen und indexbasierten Zugri, liegen in O(1). Eine
schlüsselbasierte Nutzung setzt voraus, dass das XArray nach jeder Veränderung sortiert
wird. Der Suchaufwand von lookupXA(XArray *array, void *key, Word *first, Word
*last) beträgt O(log n).
Die Instrumentierung ndet nach wie vor im Aufruf des Callbacks fi_instrument in
fi_main.c statt. Viele Prozeduren, die für die Erweiterung der Instrumentierung erschaen
wurden, benden sich in der Datei fi_reg.c, die Prototypen der öentlichen Methoden in
fi_reg.h.
Der erste Schritt zur Instrumentierung ist das Finden von WrTmp-Instruktionen, deren
IRExpr vom Typ Load ist. Da die Adresse des Ladevorgangs jedoch nicht zwangsläug zur
Instrumentierung ermittelbar ist und, viel wichtiger, die Menge der Monitorable erst zur
Laufzeit bekannt ist, muss die Untersuchung zur Ausführungszeit erfolgen. Dieses Suchmuster
ist von FITIn bereits gegeben und der eingefügte IRDirty-Aufruf preLoadHelper
bleibt beibehalten. Vor der Erweiterung war die Methode preLoadHelper das Herzstück des
Plug-Ins, da diese das Nachschlagen der Ladeadresse der folgenden Instruktion und auch
den Bit-Flip übernahm. Der Erweiterungsansatz sieht jedoch nicht weiter vor, dass zum
Zeitpunkt unmittelbar vor einem Speicherzugri ein Fehler injiziert wird. Die Fehlerinjek-
21

3 Erweiterung von FITIn
1 typedef struct {
2 IRTemp dest_temp ;
3 IRType ty ;
4 IRExpr * addr ;
5 IRTemp state_list_index ;
6 } LoadData ;
Abbildung 3.10: C-Struktur: LoadData
tion wurde daher entfernt. Eine Änderung betrit jedoch den Rückgabewert: preLoadHelper
liefert ein Ergebnis zurück, das einen Index zum Nachschlagen bestimmter Ladeinformationen
zur Ausführungszeit darstellt. Da Informationen des Ladevorgangs später zum Zeitpunkt
des potentiellen Bit-Flips benötigt werden, muss ein Zeiger auf diese erstellt und
durchgereicht werden. Zur Instrumentierung wird der Rückgabewert als neues IRTemp repräsentiert.
Für die Dauer der Instrumentierung eines IRSB verfügt FITIn nun über eine
XArray-Liste namens loads, welche LoadData-Strukturen beherbergt. LoadData ist in
Abb. 3.10 dargestellt. Die Methode instrument_load, die auch preLoadHelper einfügt,
speichert bei Ladeoperationen nun die Daten 2 bis 4 je LoadData:
1. dest_temp. Die Zielvariable, die gleichzeitig als Schlüssel für alle Einträge der loads-
Liste fungiert. Anhand dieser ist FITIn in der Lage, für jedes RdTmp nachzuschlagen,
ob für das assoziierte IRTemp Ladeinformationen existieren. So kann FITIn erkennen,
ob es sich bei dem verwendeten IRTemp um einen geladenen Wert handelt.
2. ty. Der Datentyp von dest_temp.
3. addr. Der Ausdruck der Ladeadresse von dest_temp.
4. state_list_index. Das IRTemp des Rückgabewerts von preLoadHelper, das für die
Fehlerinjektionsmethoden gebraucht wird.
dest_temp wird von der aufrufenden Methode fi_instrument gesetzt. Grundsätzlich
unterstützt FITIn Ladezugrie auf alle Arten von Datentypen, Ausnahmen betreen jedoch
einige plattformspezische Daten, die FITIn anhand des Typs des Ziel-IRTemp erkennen
kann:
• Ganzzahlen, die gröÿer sind als die Plattformadressbreite. Auf x86-Plattformen ist
dies bei CPU-Erweiterungen der Fall, die eigene, breitere Register verwenden, beispielsweise
SSE.
• IEEE754-Datentypen, üblicherweise float und double, sofern diese als Operanden
für FPU-Instruktionen geladen werden.
• Native SIMD-Datentypen.
Wird ein derartiger Datentyp festgestellt, wird LoadData verworfen. Im Unterabschnitt
3.6.4 werden die Gründe für diesen Umstand näher betrachtet.
Im Zuge der Iteration über alle IRStmt des SB wird nach RdTmp-Ausdrücken Ausschau
gehalten und für jedes Vorkommen die Liste loads nach einem LoadData-Eintrag des referenzierten
IRTemp abgesucht. Eine Ausnahme sind PUT-Instruktionen, da diese eine für
den Benutzer transparente Datenbewegung darstellen und die Registerschattentabelle von
FITIn an anderer Stelle behandelt wird. Valgrind stellt sicher, dass IRTemp nicht vor ihrer
Denition verwendet werden können. Dadurch ist es nicht nötig, mit jedem WrTmp die
Iteration über alle Instruktionen des IRSB von vorn zu beginnen. Ist ein Eintrag gefunden,
fügt FITIn vor dem Zugri auf das IRTemp eine Hilfsmethode ein: fi_reg_flip_or_leave.
fi_reg_flip_or_leave erhält als Argumente, neben einem Zeiger auf die FITIn-
22

3.6 Erweiterung
Konguration, die IRTemp des beobachteten Wertes und des Hilfsindex, der zuvor von
preLoadHelper zurückgegeben wurde. Die Rückgabe dieser Hilfsmethode ist ein neues
IRTemp, das möglicherweise um ein Bit manipuliert worden ist.
Vor Store-Instruktionen wird eine abgewandelte Methode eingefügt: fi_reg_flip_
or_leave_before_store, die zusätzlich die Zielspeicheradresse der Instruktion erhält und
zur Ausführungszeit prüft, ob ein IRTemp kopiert wird.
Der Instrumentierungs- und Ergänzungsalgorithmus von IRTemp lässt sich wie in Abbildung
3.11 ohne Berücksichtigung von Sonderfällen darstellen.
• Sei L = {t i | t i ein IRTemp} die Menge der für FITIn relevanten IRTemp, R =
L × L eine Menge von Ersetzungstupeln (t alt , t neu ).
• Für jedes IRStmt des IRSB:
• IRStmt enthält Load-Ausdruck, Ladeadresse: t a , Ladeergebnis t j :
• Füge zuvor t LD(a) ← preLoadHelper(t a ) ein.
• L ← t j
• IRStmt enthält RdTmp-Ausdruck, Zugri auf t i :
• Beginnend bei t i , wende alle r ∈ R zur Ersetzung an. t k wird hervorgebracht.
• Ersetze t i durch t k in diesem RdTmp-Ausdruck.
• Sei t max das IRTemp mit dem an diesem Punkt gröÿten Index max.
• Füge zuvor t max+1 ← fi_reg_flip_or_leave(t LD(k) , t k ) ein.
• L ← t max+1
• R ← (t k , t max+1 )
• Ersetze t k durch t max+1 in diesem RdTmp-Ausdruck.
Abbildung 3.11: Algorithmus zur Instrumentierung von IRTemp
Ein weiterer Punkt, der zur Instrumentierungszeit vorzunehmen ist, ist die Ermittlung
von PUT-Anweisungen. Dies dient dazu, zur Ausführungszeit Entscheidungen darüber
treen zu können, ob sich in der Registerschattentabelle bei Lesezugri Daten benden,
die unter Umständen zu manipulieren sind. toolData wurde um ein Array reg_temp_
occupancies von IRTemp ergänzt, das konstant die Elementanzahl der Gröÿe der Registerschattentabelle
in Bytes besitzt. Dieses Array dient einzig dazu, dass FITIn markieren
kann, ob zur Instrumentierung interessante Daten an einem Index vorhanden sind
(durch Setzen der Indizes mit den geladenen IRTemp) oder nicht (Wert IRTemp_INVALID).
Trit FITIn auf ein PUT, wird ermittelt, ob es sich bei dem zugewiesenen Wert um ein
IRTemp handelt und ob dieses in loads vorhanden ist. In dem Fall wird eine Hilfsmethode
fi_reg_set_occupancy_origin vor der Instruktion eingefügt, die die nötigen Daten erhält,
um zur Ausführungszeit eigene Schattentabellen bezüglich der Register zu pegen.
Wird keine spezische Herkunft festgestellt und war die Registerschattentabelle zuletzt mit
relevanten Daten belegt, wird ein Dirty-Aufruf namens fi_reg_set_occupancy_origin_
irrelevant eingefügt, der entsprechende Abschnitte der eigenen Tabellen als unbenutzt
markiert.
Damit ist es nun möglich, IRDirty-Aufrufe zu behandeln, die seitens Valgrind gesetzt
werden. Unter x86 ist ein Beispiel die Instruktion CPUID, die in Abhängigkeit des
23

3 Erweiterung von FITIn
1 typedef struct {
2 Bool relevant ;
3 Addr location ;
4 SizeT size ;
5 SizeT full_size ;
6 } LoadState ;
Abbildung 3.12: C-Struktur: LoadState
Registerwerts von EAX unterschiedliche Informationen zur ausführenden CPU in die Benutzerregister
schreibt. Verständlicherweise ist es nicht möglich, diesen höchst hardwareabhängigen
Befehl durch reine VEX IR zu modellieren. Eine Hilfsmethode übernimmt
stattdessen die Aufgabe, indem sie auf die Registerschattentabelle an der Stelle zugreift, auf
die das Register EAX abgebildet ist. Die Aufrufdetails einer Dirty-Hilfsmethode, zu denen
auch die Zugrismuster auf die Registerschattentabelle zählen, sind in IRDirty speziziert.
FITIn kann die Zugrie in Abhängigkeit von der Belegung von reg_temp_occupancies auf
IRTemp zuordnen. Für jedes IRTemp wird ein Aufruf auf die Methode fi_reg_flip_or_
leave_registers_wrap vor der eigentlichen Hilfsmethode eingefügt. Als Argument wird
der vorbereitenden Methode der Zugrisindex für jedes Register übergeben. Die Methode
verfügt über eigene Registerschattentabellen, in welchen weitere Informationen zur Datenbelegung
zu nden sind, um konsistent einen Bit-Flip durchzuführen. Gleichermaÿen wird
für lesende Zugrie auf den Prozessspeicher vorher fi_reg_flip_or_leave_mem_wrap eingefügt.
In Anhang A.2 bendet sich ein umfassenderes Beispiel für einen Vergleich zwischen
der ursprünglichen VEX IR und der VEX IR nach der Instrumentierung durch FITIn.
3.6.3 Ausführungszeit
Eine Unterscheidung zwischen Instrumentierungszeit und Ausführungszeit ermöglicht es,
einen Bit-Flip erst zu einem späteren Ausführungszeitpunkt oder zu einer bestimmten
Rekursionstiefe eines SB vorzunehmen.
Zum Austausch von Daten zwischen einigen Hilfsmethoden, die im Folgenden vorgestellt
werden, ist toolData um eine XArray-Liste namens load_states erweitert worden,
welche Daten vom Typ LoadState (siehe Abbildung 3.12) beheimatet.
Die Methode preLoadHelper veranlasst nach wie vor eine Suche der übergebenen
Adresse innerhalb der Liste von angelegten Monitorable. Bei jedem Aufruf, unabhängig
vom Suchergebnis, wird bereits ein LoadState erstellt und load_states hinzugefügt, um
mindestens zu vermerken, dass an dieser Stelle keine Daten geladen wurden, die einem
aktiven Monitorable entstammen. Liegt ein positives Suchergebnis vor je Startadresse
existiert nur noch maximal ein Monitorable, so führen zum Beispiel häuge Aufrufe einer
Funktion nicht zur Häufung von Listeneinträgen wird die LoadState-Struktur um weitere
Daten ergänzt. Zu den insgesamt erfassten Daten gehören:
ˆ relevant: Dieses Feld zeigt an, ob der geladene Wert einer Adresse entstammt, die
in einem aktiven Monitorable ermittelt wurde.
ˆ location: Die Herkunftsadresse des Werts, sodass dieser später zurückgeschrieben
werden kann.
ˆ size: Die Gröÿe in Bytes, die tatsächlich von der Ladeoperation gelesen wird.
ˆ full_size: Die ursprüngliche Gröÿe in Bytes, die im Monitorable abgelegt wurde.
24

3.6 Erweiterung
load_states ist keine sortierte Liste, Zugrie erfolgen einzig über den ganzzahligen
Index. preLoadHelper besitzt einen Rückgabewert, welcher der Index des eingefügten
LoadState in load_states ist. Durch die Instrumentierung ist bereits sichergestellt, dass
der Rückgabewert als Argument für die Fehlerinjektionsmethoden verwendet wird.
fi_reg_flip_or_leave ist eine dieser beiden Methoden: Neben dem tatsächlichen
Wert, der möglicherweise zu manipulieren ist, wird der Index für load_states mitgegeben,
an welchem sich die dazugehörigen Ladezustandsinformationen benden. Folgende
Bedingungen müssen erfüllt sein, damit ein Bit-Flip durchgeführt werden kann: a) Es ist
noch keine Injektion vorgenommen worden, b) der Datenursprung ist für den Benutzer
relevant, c) es handelt sich nicht um einen Golden Run und d) der Zähler hat mit dem anstehenden
Zugri den benutzerspezizierten Wert erreicht. In diesem Fall ist die Rückgabe
der bitmanipulierte Wert, andernfalls bleibt dieser unverändert. Die Instrumentierung hat
veranlasst, dass dieser Wert nun in jedem Fall von der nachfolgenden Instruktion verwendet
wird.
fi_reg_flip_or_leave_before_store prüft zusätzlich, ob die Adresse der anstehenden
Schreiboperation in den Prozessspeicher unterschiedlich zur Ursprungsadresse des
Werts ist, die in LoadState vermerkt wurde. So kann verhindert werden, dass Zuweisungen
von a, die in C der Anweisung a = a; entsprechen, nicht als Lesezugri auf a betrachtet
werden. Im Unterschied dazu steht das Kopieren des Wertes an eine andere Stelle, also
etwa b = a;, wobei b kein Alias von a ist.
Die Liste load_states wird im Callback auf das Ereignis track_stop_client_code
geleert. Dieses Ereignis ndet immer dann statt, wenn Valgrind die Ausführung eines SB
beendet hat. Auf diese Weise kann sichergestellt werden, dass load_states nicht stetig
wächst, da die eingefügten Hilfsfunktionen nicht über einen einzelnen SB hinaus miteinander
kommunizieren brauchen. Für Zugrie auf die Registerschattentabelle werden zwei
zusätzliche Arrays konstanter Gröÿe in toolData verwendet, sodass nötige Informationen
für einen Bit-Flip auch auÿerhalb eines Benutzer-SB vorgenommen werden können, etwa
im Falle eines Systemaufrufs, der Register ausliest. Diese beiden Arrays heiÿen Addr
*reg_origins und SizeT *reg_load_sizes. Die Speicherallokation für diese kann jedoch
erst mit dem ersten Aufruf von fi_instrument stattnden, da dem Plug-In erst zu diesem
Punkt erlaubt wird, die Gröÿe der Registerschattentabelle in Erfahrung zu bringen.
reg_origins hält für jedes Byte der Registerschattentabelle, sofern im Rahmen der
Instrumentierung erforderlich, die Herkunftsadresse aus dem Prozessspeicher, andernfalls
zeigt 0 an, dass die Belegung zur Zeit nicht relevant ist. reg_load_sizes enthält doppelt
so viele SizeT-Elemente wie die Registerschattentabelle Bytes hat. Dabei benden
sich paarweise nebeneinander für jeden Index der Registerschattentabelle die Ladegröÿe
und die Ursprungsgröÿe im Prozessspeicher. Das Setzen und Invalidieren beider Arrays an
den geforderten Stelle wird von den Hilfsfunktionen fi_reg_set_occupancy_origin und
fi_reg_set_occupancy_origin_irrelevant vorgenommen.
fi_reg_flip_or_leave_registers_wrap (siehe Abschnitt 3.6.2) greift ebenfalls auf
die Schattenwerttabellen von tData zu, da diese fi_reg_flip_or_leave_registers aufruft,
welche nicht von load_states abhängig sein darf.
Betrachtet man die vorgestellten Operationen, die in verschiedenen Anwendungsfällen
zum Einsatz kommen, um einen Bit-Flip durchzuführen, fällt auf, dass diese bisher lediglich
Zwischenwerte berühren. Diese Zwischenwerte werden sich entweder in der Registerschattentabelle,
in einem Register oder im Auslagerungsspeicher wie dem Stack benden. Bisher
scheint der Eekt des ursprünglichen FITIn verloren zu sein, dass Fehlerinjektionen in den
Speicher auch bei bloÿen Lesezugrien persistiert werden. Tatsächlich würde ein Bit-Flip in
einer Variable, die zur Manipulation aus dem Zwischenspeicher gelesen, in der Hilfsfunktion
25

3 Erweiterung von FITIn
behandelt und wieder zurückkopiert wird, nur solange dort verweilen, bis der temporäre
Speicherort überschrieben wird. Bei einem erneutem Laden aus dem Prozessspeicher ist
die Fehlerinjektion also nicht mehr erkennbar. Insbesondere bei Speicherbereichen, die für
die Programmlaufzeit einzig lesend verwendet werden, würde der Benutzer enttäuscht feststellen,
dass Bit-Flips ausschlieÿlich kurzlebig vorkommen können. Die Lösung ndet sich
in Form des Kommandozeilenarguments --persist-flip=yes. Wie bereits erläutert, speichert
FITIn nun stets die Herkunftsadressen geladener Werte, sowohl in load_states als
auch in reg_origins. Ist dieses Kommandozeilenargument gesetzt und ndet nun tatsächlich
ein Bit-Flip statt, kann FITIn ermitteln, woher der manipulierte Wert stammt und
kann dadurch das unangetastete Byte an der richtigen Stelle im Prozessspeicher durch den
manipulierten Temporärwert ersetzen. Ein SEU auf dem Arbeitsspeicher kann dadurch
nun zusätzlich simuliert werden.
Ein weiterer Punkt, der Aufmerksamkeit verdient, ist die Durchführung von Bit-Flips.
Die Spezikation von --mod-bit=n lässt Werte von 0 bis 255 zu. Das Bit der Position 0
ist das erste Bit der kleinsten Byte-Adresse des Werts, sodass der Anwender eine plattformspezische
Byte-Reihenfolge bei der Bit-Wahl berücksichtigen muss. In FITIn wird
zwischen zwei Formen von Bit-Flips unterschieden:
• Primärer Bit-Flip: Ist die Bitposition n innerhalb der Bytes des tatsächlich geladenen
Werts, welcher von der Ursprungsgröÿe im Monitorable abweichen darf, wird ein Bit-
Flip sofort vorgenommen und auf Wunsch auch persistiert. Eine abweichende Gröÿe
kann beispielsweise auftreten, wenn der Benutzer eine struct-Variable beobachtet,
im Programm jedoch nur die erste Komponente gelesen wird, die eine kleinere Gröÿe
als die Gesamtstruktur aufweist.
• Sekundärer Bit-Flip: Wird im vorherigen Fall festgestellt, dass die Bitposition n auÿerhalb
der Ladegröÿe liegt und ist zusätzlich das Zurückschreiben der Fehlerinjektion
in den Speicher aktiviert, wird untersucht, ob der Bit-Flip auf der vollen Variablenbreite
im Prozessspeicher durchgeführt werden kann. In diesem Fall ist von einem
sekundären Bit-Flip die Rede, der erst bei einem ausreichend groÿen Ladevorgang in
Erscheinung treten wird.
Wird eine zu hohe Bitposition gewählt, wird der Injektionsvorgang verworfen. In der
erweiterten Valgrind-Ausgabe (--verbose-Parameter in der Kommandozeile) wird dieser
Fall kenntlich gemacht. So ndet im Unterschied zum ursprünglichen FITIn bei der Bitposition
keine Modulo-Rotation mehr statt, wenn ein zu hoher Wert gewählt wurde.
Es kann der Fall eintreten, dass durch mehrfaches Laden von einer Speicheradresse
bedingt mehrere IRTemp innerhalb eines IRSB denselben Wert repräsentieren. Sollte einer
von diesen IRTemp zur Ausführungszeit manipuliert werden, ndet keine Synchronisation
mit den anderen Werten statt.
Nach wie vor werden Monitorable automatisch deaktiviert, sollte festgestellt werden,
dass die Bewegung des Stack-Zeigers Variablen an entsprechenden Stellen eliminiert hat.
Soll dies zu einem früheren Zeitpunkt geschehen oder möchte der Benutzer nach einem
free() oder aufgrund der Stack-Bewegung sichergehen, dass der Speicherbereich nicht
mehr überwacht wird, hat er manuell das Makro FITIN_UNMONITOR_VARIABLE(var) oder
FITIN_UNMONITOR_MEMORY(addr, size) im Quellcode entsprechend einzufügen.
3.6.4 float, double und weitere Datentypen
Das bereits vorgestellte Konzept der Instrumentierung ist in den unterstützten Datentypen
eingeschränkt: Lediglich Ganzzahlen, die nicht die Plattformadressbreite überschreiten,
können von FITIn behandelt werden. Nicht nur aus technischen, sondern auch aus
26

3.6 Erweiterung
konzeptionellen Gründen, die im Folgenden erläutert werden.
Dirty-Aufrufe können unter Valgrind nur mit ganzzahligen Argumenten aufgerufen
werden, die genau die Gröÿe der Plattformadressbreite haben. Rückgabewerte dürfen kleiner
oder gleich dieser Gröÿe sein. Die Methoden fi_reg_flip_or_leave*, die direkt in
die VEX IR eingebettet werden, können in ihrer implementierten Form also lediglich unter
diesen Bedingungen arbeiten.
Das erweiterte FITIn erkennt, ob es sich bei dem geladenen IRTemp um ein kleineres
Ganzzahlformat handelt, und fügt unmittelbar vor dem Aufruf von fi_reg_flip_or_
leave* eine native VEX IR-Operation ein, die das Ursprungsformat von 8, 16 und gegebenenfalls
32 Bit Breite auf 32 oder 64 Bit vergröÿert. Der Rückgabewert von fi_reg_
flip_or_leave* hat jedoch die Originalgröÿe, sodass keine weiteren Komplikationen mit
dem Ursprungscode auftreten werden, etwa mit Operationen, die exakte Operandengröÿen
erwarten. Beispielsweise würde die Operation t24 = Iop_I16Uto64(t12) t12 auf einer
AMD64-Plattform von 16 auf 64 Bit erweitern, der breitere Wert t24 wird anschlieÿend
als passendes Argument für die Flip-Funktion verwendet.
Für gröÿere und andere Typen ist ein anderer Ansatz nötig. In einem experimentellen
Zweig des Entwicklungscodes wurde ein solcher Ansatz untersucht: Anstatt des Übergebens
des verwendeten Wertes als Argument der Bit-Flip-Methode und der Rückgabe eines
neuen Werts, der in der folgenden Instruktion verwendet wird, wird lediglich der Index für
LoadState dargereicht. LoadState wurde um Felder erweitert, sodass sich der zu manipulierende
Wert im Falle von value != VAL_REGULAR im LoadState benden wird. Diese
Erweiterung ist in Abbildung 3.13 zu sehen.
1 typedef struct {
2 Bool relevant ;
3 Addr location ;
4 SizeT size ;
5 SizeT full_size ;
6 enum {
7 VAL_REGULAR ,
8 VAL_LONG ,
9 VAL_FLOAT ,
10 VAL_DOUBLE
11 } type ;
12 union {
13 ULong _long ;
14 Float _float ;
15 Double _double ;
16 } value ;
17 } LoadState ;
Abbildung 3.13: Erweitertes LoadState
Die Behandlung von Ganzzahlen gröÿer als die Plattformadressbreite, float und
double wurde hinzugefügt: Vor der Verwendung eines solchen Wertes wird statt eines
fi_reg_flip_or_leave* nun fi_reg_flip_or_leave_larger* eingefügt, das neben der
Adresse von tData lediglich einen Zeiger auf LoadState erhält. Die neue Hilfsmethode
extrahiert den Wert aus dem erweiterten LoadState und übergibt ihn den internen Bit-
Flip-Hilfsmethoden. Da der manipulierte Wert allerdings nicht als Rückgabewert in die
VEX IR zurückgeführt werden kann, muss dieser erneut aus dem Speicher geladen werden:
FITIn muss also zusätzlich eine LD-Instruktion einfügen und den neuen IRTemp in die
27

3 Erweiterung von FITIn
1 [...]
2 t24 = F64i {0 x7FF8000000000000 }
3 t204 = DIRTY 1: I1 ::: preLoadHelper {0
x38025b80 }(0 x382A9740 :I32 ,t18 ,0 x4 :I32 ,0
x11007 : I32 )
4 t26 = LDle : F32 ( t18 )
5 DIRTY 1: I1 ::: fi_reg_flip_or_leave_larger [ rp
=2]{0 x38027480 }(0 x382A9740 :I32 , t204 )
6 t205 = LDle : F32 ( t18 )
7 t25 = F32toF64 ( t205 )
8 t27 = GETI (136:8 xI8 )[t21 , -1]
9 t23 = Mux0X (t27 ,t25 , t24 )
10 DIRTY 1: I1 ::: incrInst {0 x38026370 }()
11 ------ IMark (0 x8048531 , 2, 0) ------
12 t35 = F64i {0 x3FF0000000000000 }
13 t36 = GETI (136:8 xI8 )[t21 , -2]
14 t33 = Mux0X (t36 ,t35 , t24 )
15 DIRTY 1: I1 ::: incrInst {0 x38026370 }()
16 ------ IMark (0 x8048533 , 2, 0) ------
17 t40 = AddF64 (0 x0 :I32 ,t23 , t33 )
18 [...]
Abbildung 3.14: Experimentelle Behandlung einer float-Addition
nachfolgende Operation einsetzen.
Dieser Ansatz wurde anhand einer float-Addition getestet. Das Instrumentierungsergebnis
auf einer x86-CPU eines 32 Bit-Programms ist in Abbildung 3.14 gegeben. Zu
erkennen ist die experimentelle Instrumentierung in den Zeilen 5 und 6. Die Instrumentierung
erfolgt allerdings vor einer Erweiterung des Werts auf doppelte Präzision (Zeile 7), die
tatsächliche Addition erst deutlich später (Zeile 17). Im Testszenario konnte der gewünschte
Eekt des Umkehrens des Vorzeichenbits auf diese Art und Weise nicht beobachtet werden,
die Instrumentierung ist also deplatziert. Es ist weiterer Aufwand nötig, einen zuverlässigen
Ansatz zu erarbeiten und zu implementieren, der bei x86-FPU-Instruktionen ein zum bisherigen
Konzept analoges Verhalten ermöglicht, sodass der Benutzer bei der Addition a +=
1.0f; für eine float-Variable a ebenfalls bloÿ einen Lesezugri zu zählen hat. Dieses Dokument
präsentiert lediglich eine Voruntersuchung dieses Falls, sodass die Erweiterung von
FITIn vorerst keine anderen Datentypen als hinreichend kleine Ganzzahlen unterstützt.
Erwähnt sei weiterhin, dass dasselbe Programm nicht einmal für die Nutzung von
x86-FPU-Instruktionen kompiliert werden muss: Eine einfache Addition zweier float wird
von einem GCC v4.7.3 mit dem Ziel -m64 -O0 zu Assemblercode aus SSE-Instruktionen
und -Registern kompiliert. Die resultierende VEX IR unterscheidet sich hier erneut grundlegend
von der in Abbildung 3.14. Dieser Fall ist bei einer Erweiterung von FITIn zu
berücksichtigen.
3.6.5 Systemaufrufe
FITIn benötigt Informationen zu zwei Systemaufrufereignissen: pre_reg_read und pre_
mem_read.
pre_mem_read wird vor dem Aufruf eines Systemaufrufs ausgelöst, der lesend auf den
Prozessspeicher zugreift. Ein Beispiel für so einen Systemaufruf unter Linux ist
settimeofday(2), welcher einen Zeitstempel aus dem Benutzerprozess ausliest. Aus na-
28

3.6 Erweiterung
heliegenden Gründen wird ein Bit-Flip in so einem Fall immer und ausschlieÿlich im Prozessspeicher
vorgenommen. Für jedes einzelne Byte der angegeben Lesebereichsgröÿe wird
geprüft, ob ein Monitorable mit dieser Startadresse existiert, und gegebenenfalls eine Fehlerinjektion
vorgenommen.
Valgrind bietet zusätzlich das Ereignis pre_mem_read_asciiz an, das im Falle des
Lesens eines NULL-terminierten Strings verwendet wird. FITIn ermittelt hier zusätzlich die
String-Länge und übergibt ihn danach der Callback-Methode von pre_mem_read.
Bei Aufrufen, die auf ein Benutzerregister zugreifen, wird das Ereignis pre_reg_read
ausgerufen, so etwa unter Linux im Fall von sendfile(2). FITIn ermittelt alle Belegungen
anhand der Registerschattentabellen reg_origins und reg_load_sizes und prüft für
jede Belegung, ob eine Fehlerinjektion fällig ist. Bei Bedarf wird das geippte Byte auch
im Prozessspeicher an der Herkunftsadresse abgespeichert. Dieses Ereignis ist praktisch
gesehen jedoch mit Schwierigkeiten verbunden:
• Der Benutzer muss über die Implementierung eines solchen Systemaufrufs im Detail
Bescheid wissen, ob und welche Benutzerregister ausgelesen werden, um gegebenenfalls
den Grund des Bit-Flips an dieser Stelle zu verstehen.
• Jeder Systemaufruf wird zuvor von Valgrind in einem eigenen Wrapper behandelt, sodass
zwischen einem Benutzercode-SB und dem Aufruf ein weiterer SB von Valgrind
ausgeführt wird. Der Benutzer muss von diesem Umstand wissen, da die Belegung der
Registerschattentabelle im Wrapper mit Parametern durchgeführt wird, die nun dupliziert
im Stack-Fenster des Wrappers vorliegen. Es ist nötig, dass mittels --fnname=
gezielt dieser Systemaufruf-Wrapper der immer gleichnamig zum tatsächlichen Aufruf
ist angesprochen wird, sodass FITIn die Belegung der Registerschattentabelle
verfolgen kann.
• Weiterhin ist es unumgänglich, vor dem Wrapper-Aufruf die Adresse des Parameters
zu kennen, die dieser im Stack-Fenster des Wrappers einnimmt. Da die einzige Möglichkeit
darin besteht, einen Speicherbereich im Benutzercode mit Hilfe des Makros
FITIN_MONITOR_MEMORY(addr, size) zu spezizieren, muss diese Adresse hier bereits
relativ oder absolut ermittelt sein. Der nötige Aufwand dazu besteht darin, die
Adressendierenz entweder auszuprobieren oder mittels groÿangelegter Analyse des
spezischen SB des Wrappers und des kompilierten Programmcodes diese präzise zu
ermitteln.
Dieses Vorgehen ist mühselig und erfordert vom Benutzer tiefgehende Kenntnisse über
Valgrind. Andererseits dürfte dieser Anwendungsfall für systemunspezische Programme
nur eine schwindend kleine Bedeutung haben.
29

4 Evaluierung von FITIn
In diesem Kapitel wird anhand mehrerer Anwendungsbeispiele untersucht, inwieweit FITIn
in der Lage ist, mit diesen umzugehen. Weiterhin werden Aussagen bezüglich der Performance-
Einbuÿe und des zusätzlichen Speicherbedarfs durch das Plug-In getroen.
4.1 Analyse von Testfällen
Sofern nicht anders angegeben, sind alle Programme mit GCC v4.7.3 als 32 und 64 Bit-
Programm kompiliert (Option -O0) und unter Linux Kernel 3.8 und der GNU C Library
v2.17 getestet worden.
Nichtlineare Ganzzahloperationen
Im ersten Programm (Abb. 4.1) wird eine Variable sizeof(int) * 8 - 1 Mal mittels der
Bitschiebeoperation
2 # include " ../../ include / valgrind /
fi_client .h"
3
4 int main () {
5 unsigned int a = 1, i = 0,
6 until = sizeof (a) * 8 - 1;
7 FITIN_MONITOR_VARIABLE (a);
8
9 for (; i < until ; ++ i) {
10 a = a

4 Evaluierung von FITIn
Wird das Programm nun mit FITIn und den Parametern --mod-bit=0 und
--mod-load-time=15 ausgeführt, lautet der Programmteil der Ausgabe tatsächlich:
$ ../../ bin / valgrind -- tool = fitin --mod - bit =0 --mod - load - time =15 ./ bin / sample
==2941== FITIn , A simple fault injection tool
==2941== Copyright (C) 2013 , and GNU GPL 'd , by Clemens Terasa , Marcel Heing - Becker
==2941== Using Valgrind -3.8.1 and LibVEX ; rerun with -h for copyright info
==2941== Command : ./ bin / sample
==2941==
2147614720
==2941==
[ FITIn ] Totals ( of monitored code blocks ):
[ FITIn ] Overall variable accesses : 126
[ FITIn ] Monitored variable accesses : 15
[ FITIn ] Instructions executed : 99451
FITIn zählt nur so viele Zugrie auf die zu beobachtenden Variablen wie bis einschlieÿlich
zur Ausführung des Bit-Flips stattnden. Daher ergibt sich hier die Anzahl von
15 Zugrien auf a.
Ein Blick in den Ausschnitt der VEX IR des Schleifen-Superblocks des Programms
(Abb. 4.2) bestätigt die erwartete Instrukionswahl seitens des Compilers und die Zuverlässigkeit
des Zählens der Zugrie in diesem Beispiel. Die Variable a wird in Zeile 6 vom Stack
ausgelesen, in Zeile 9 wird die Bit-Flip-Hilfsmethode platziert und deren Rückgabewert für
die Schiebeoperation Shl32 in Zeile 10 benutzt.
1 [...]
2 ------ IMark (0 x804853E , 4, 0) ------
3 t15 = GET : I32 (24)
4 t14 = Add32 (t15 ,0 x18 : I32 )
5 t80 = DIRTY 1: I1 ::: preLoadHelper [ rp =3]{0
x38025b80 }(0 x382A9740 :I32 ,t14 ,0 x4 : I32 )
6 t16 = LDle : I32 ( t14 )
7 DIRTY 1: I1 ::: incrInst {0 x38026300 }()
8 ------ IMark (0 x8048542 , 2, 0) ------
9 t81 = DIRTY 1: I1 ::: fi_reg_flip_or_leave [ rp
=3]{0 x38026ff0 }(0 x382A9740 :I32 ,t16 , t80 )
10 t1 = Shl32 (t81 ,0 x1 : I8 )
11 PUT (68) = 0 x8048544 : I32
12 DIRTY 1: I1 ::: incrInst {0 x38026300 }()
13 [...]
Abbildung 4.2: Beispielprogramm I, VEX IR
Registergebundene Operationen I
Zum Untersuchen der Funktionalität von FITIn mit registergebundenen Operationen ist
das Schreiben plattformspezischen Codes nötig, sodass der generierte Binärcode im kritischen
Teil nicht der Willkür des Compiler-Programms, dessen Version oder dessen Kon-
gurationsparametern unterliegt.
In dem Beispiel in Abbildung 4.3 wird eine x86-spezische Schleifeninstruktion verwendet:
LOOP dest. Mit jedem Aufruf dieser Instruktion wird der Inhalt des Registers ECX
um 1 reduziert. Sollte der Registerinhalt dadurch ungleich Null sein, springt der Instruktionszeiger
zu dest, andernfalls wird mit der nachfolgenden Instruktion fortgefahren.
32

4.1 Analyse von Testfällen
Die Variable c wird mit dem Wert 21 initialisiert und anschlieÿend nach ECX geladen.
In jedem Schleifendurchlauf wird der Variablenwert von result um Eins erhöht.
1 # include < stdio .h >
2 # include " ../../ include / valgrind /
fi_client .h"
3
4 int main () {
5 int c = 21 , result = 0;
6 FITIN_MONITOR_VARIABLE (c);
7
8 asm (" movl %0 , %% ecx " :: "m"(c):" ecx ");
9 asm (" start :");
10 asm (" incl %0 ":"=m"( result ));
11 asm (" loop start ");
12
13 printf ("%d\n" , result );
14 return 0;
15 }
Abbildung 4.3: Beispielprogramm II
Der Benutzer möchte beim 10. Lesezugri auf c, der zwangsläug auf einem Register
stattnden wird, am Bit der Stelle 2 2 einen Bit-Flip durchführen. Bei diesem Zugri
wird c den Wert 11 haben, mit einem Flip unmittelbar zuvor jedoch 15 und nach der
Dekrementierung damit 14. Folglich kann in der Ausgabe von result nun 24 erwartet
werden.
Das Programm gibt entgegen der ersten Erwartung jedoch die Zahl 21 aus.
$ ../../ bin / valgrind -- tool = fitin --mod - load - time =10 --mod - bit =2 ./ bin / sample
==3011== FITIn , A simple fault injection tool
==3011== Copyright (C) 2013 , and GNU GPL 'd , by Clemens Terasa , Marcel Heing - Becker
==3011== Using Valgrind -3.8.1 and LibVEX ; rerun with -h for copyright info
==3011== Command : ./ bin / sample
==3011==
21
==3011==
[ FITIn ] Totals ( of monitored code blocks ):
[ FITIn ] Overall variable accesses : 23
[ FITIn ] Monitored variable accesses : 1
[ FITIn ] Instructions executed : 111327
Eine erster Blick verrät: Ein einziger nach FITIn gemessener Zugri auf c bedeutet,
dass ein 10. Lesezugri nie stattgefunden hat. Dieser Fall bedarf einer ausführlicheren
Analyse.
In Abbildung 4.4 sei die VEX IR des ersten relevanten main-SB nach der Instrumentierung
durch FITIn gegeben. In den Zeilen 3-5 ist erkennbar, dass c vom Stack eingelesen
wird. Der erste Zugri auf den Wert in t20 erfolgte in der Subtraktion in Zeile 9, FITIn hat
jedoch zuvor fi_reg_flip_or_leave eingefügt und ersetzte damit t20 durch t45. Auällig
ist jedoch, dass der dekrementierte Wert t28 in Zeile 10 in die Registerschattentabelle
an Oset 12 geschrieben wird, auf welches unter x86 das Register ECX abgebildet ist. Da
laut FITIn bloÿ ein einziger Zugri auf c erfolgte und Valgrind PUT(12) beibehielt, liegt es
nahe, dass die weitere Programmlogik in einem anderen SB ausgeführt wird. Tatsächlich
folgte auf der Testkonguration diesem SB mit der Nummer 1435 ein weiterer main-SB
33

4 Evaluierung von FITIn
1 [...]
2 ------ IMark (0 x8048534 , 4, 0) ------
3 t18 = Add32 (t13 ,0 x1C : I32 )
4 t42 = DIRTY 1: I1 ::: preLoadHelper [ rp
=3]{0 x38025b80 }(0 x382A9740 :I32 ,t18 ,0
x4 : I32 )
5 t20 = LDle : I32 ( t18 )
6 [...]
7 ------ IMark (0 x804853C , 2, 0) ------
8 t45 = DIRTY 1: I1 :::
fi_reg_flip_or_leave [ rp =3]{0 x38026ff0
}(0 x382A9740 : I32 , t20 , t42 )
9 t28 = Sub32 (t45 ,0 x1 : I32 )
10 PUT (12) = t28
11 [...]
Abbildung 4.4: Beispielprogramm II, VEX IR (main-SB 1)
mit Nummer 1436.
In der VEX IR des nachfolgenden SB (Abbildung 4.5) ndet sich tatsächlich jede
weitere Subtraktion des Registerinhalts um 1. Es liegt also ein Fall vor, in welchem Valgrind
Werte zwischen verschiedenen SBs über die Registerschattentabelle weitergibt.
1 [...]
2 ------ IMark (0 x804853C , 2, 0) ------
3 t17 = GET : I32 (12)
4 t16 = Sub32 (t17 ,0 x1 : I32 )
5 PUT (12) = t16
6 [...]
Abbildung 4.5: Beispielprogramm II, VEX IR (main-SB 2)
Grundsätzlich erkennt FITIn zur Instrumentierungszeit, ob ein geladener Wert für ein
PUT verwendet wird und kann im nächsten zu instrumentierenden SB anhand der Belegung
von reg_temp_occupancies erkennen, ob ein GET-Ausdruck einen potentiell beobachteten
Wert zurückliefern wird, um diesen gegebenenfalls der loads-Liste hinzuzufügen.
Durch die erste Subtraktion in Abb. 4.4, Zeile 9 entsteht jedoch ein neuer, für FITIn
anonymer Ausdruck, der beim Kopieren in die Registerschattentabelle nicht weiter beachtet
wird. An diesem Verfahren ist bei FITIn auch festzuhalten, da Valgrind einige Instruktionen
in mehrere elementare VEX IR-Instruktionen übersetzen wird (deutlich zu erkennen in
Abb. 3.14) und dieses Zerlegen für den Benutzer transparent bleiben soll.
In diesem Beispiel handelt es sich daher um einen von FITIn nicht behandelbaren Fall,
welchen der Benutzer hier allerdings noch an der zu niedrigen Zugriszahl erkennen kann.
Registergebundene Operationen II
In einem weiteren Beispiel (Abb. 4.6) wird die Registerfähigkeit von FITIn nun durch
explizite Registerverwendung der Instruktionen demonstriert. Innerhalb einer Schleife wird
eine Operation ausgeführt, deren reines C-Äquivalent b = (b + a) * a; ist. Die erwartete
34

4.1 Analyse von Testfällen
1 # include < stdio .h >
2 # include " ../../ include / valgrind /
fi_client .h"
3
4 int main () {
5 int a = 1, b = 0, i = 0;
6 FITIN_MONITOR_VARIABLE (a);
7
8 for (; i < 10; ++ i) {
9 asm (" movl %0 , %% eax " :: "m"(a):"
eax ");
10 asm (" movl %0 , %% ebx " :: "m"(b):"
ebx ");
11 asm (" addl %eax , % ebx ");
12 asm (" imull %eax , % ebx ");
13 asm (" movl %% ebx , %0 ":"=m"(b));
14 }
15 printf ("%d %d\n" , a , b);
16 return 0;
17 }
Abbildung 4.6: Beispielprogramm III
Ausgabe lautet: 1 10.
Es werden zwei Durchläufe in FITIn vorgenommen: Zuerst ist ein Bit-Flip an der
Stelle 2 1 vor dem 10. Zugri auf a auszuführen. Im zweiten Durchlauf wird der Bit-Flip in
a zusätzlich an die Ursprungsadresse zurückgeschrieben.
Zu erwarten ist, dass Zugrie mit geradem Zählerstand vor der Ausführung der Multiplikation
stattnden, der 10. Zugri wird also im 5. Schleifendurchlauf gezählt. Der Wert
von b beträgt zuvor 5, die Multiplikation wird nun jedoch nicht mit 1 erfolgen, sondern
nach dem Bit-Flip mit 3. Da b in jedem Durchlauf erneut geladen und auch zurückgeschrieben
wird, beträgt der Wert nun 15, der modizierte Wert von a geht aber in der
folgenden Iteration durch das erneute Laden verloren. Das erwartete Endergebnis nach
den verbleibenden fünf Iterationen ist also 1 20. Die Vorhersage bewahrheitet sich:
$ ../../ bin / valgrind -- tool = fitin --mod - load - time =10 --mod - bit =1 ./ bin / sample
==2048== FITIn , A simple fault injection tool
==2048== Copyright (C) 2013 , and GNU GPL 'd , by Clemens Terasa , Marcel Heing - Becker
==2048== Using Valgrind -3.8.1 and LibVEX ; rerun with -h for copyright info
==2048== Command : ./ bin / sample
==2048==
1 20
==2048==
[ FITIn ] Totals ( of monitored code blocks ):
[ FITIn ] Overall variable accesses : 53
[ FITIn ] Monitored variable accesses : 10
[ FITIn ] Instructions executed : 111711
Im zweiten Versuch wird der Bit-Flip nun dank --persist-flip=yes an die Ursprungsadresse
von a zurückgeschrieben, sodass auch in allen nachfolgenden Iterationen mit
3 addiert und multipliziert wird. Es ergibt sich folgende Rechnung für den Endwert von b: b
= ((((((((((15 + 3) * 3) + 3) * 3) + 3) * 3) + 3) * 3) + 3) * 3);. Die erwartete
Ausgabe ist also 3 4734. Auch diese Vermutung bestätigt sich:
35

4 Evaluierung von FITIn
$ ../../ bin / valgrind -- tool = fitin --mod - load - time =10 --mod - bit =1 -- persist - flip = yes
./ bin / sample
==2044== FITIn , A simple fault injection tool
==2044== Copyright (C) 2013 , and GNU GPL 'd , by Clemens Terasa , Marcel Heing - Becker
==2044== Using Valgrind -3.8.1 and LibVEX ; rerun with -h for copyright info
==2044== Command : ./ bin / sample
==2044==
3 4734
==2044==
[ FITIn ] Totals ( of monitored code blocks ):
[ FITIn ] Overall variable accesses : 53
[ FITIn ] Monitored variable accesses : 10
[ FITIn ] Instructions executed : 111745
Tatsächlich funktioniert die Instrumentierung (Abb. 4.7) wie erwünscht: Das geladene
IRTemp t22 wird nacheinander durch t88 und t90 ersetzt. In dieser Abbildung nicht zu
erkennen, jedoch beobachtet, ist die Duplikation der VEX IR eines ganzen SB innerhalb
seiner selbst, in welcher sich lediglich die vergebenen IRTemp voneinander unterscheiden.
Der Optimierer von Valgrind betreibt auf diese Weise ein partielles Aufrollen der Schleife.
1 [...]
2 ------ IMark (0 x8048547 , 2, 0) ------
3 t88 = DIRTY 1: I1 :::
fi_reg_flip_or_leave [ rp =3]{0 x38026ff0
}(0 x382A9740 : I32 , t22 , t87 )
4 t89 = DIRTY 1: I1 :::
fi_reg_flip_or_leave [ rp =3]{0 x38026ff0
}(0 x382A9740 : I32 , t19 , t86 )
5 t2 = Add32 ( t88 , t89 )
6 DIRTY 1: I1 ::: incrInst {0 x38026300 }()
7 ------ IMark (0 x8048549 , 3, 0) ------
8 t90 = DIRTY 1: I1 :::
fi_reg_flip_or_leave [ rp =3]{0 x38026ff0
}(0 x382A9740 : I32 , t89 , t86 )
9 t7 = Mul32 ( t90 , t2 )
10 [...]
Abbildung 4.7: Beispielprogramm III, VEX IR
Subroutinen
Dieses Beispiel (Abb. 4.8) untersucht die Fähigkeit von FITIn, mit Subroutinen umgehen
zu können. Eine Methode just_do_it erhöht eine Variable mit konstanter Initialisierung
um Eins und gibt diese zurück. Hier ist erneut der Grund hervorzuheben, der
eine Debug-Version des Programms nötig macht: FITIn muss darüber informiert werden,
dass abweichend von main nun die SBs der Methode just_do_it von Relevanz sind. Dazu
wird die Option --fnname=just_do_it gesetzt. So ist Valgrind dazu in der Lage, die
Debug-Informationen auszulesen und auf diese Weise dem SB seinen Ursprungsbezeichner
zuzuordnen, welchen FITIn zur Filterung benutzt. Ohne die Debug-Informationen könnte
dieses Beispiel nicht getestet werden.
In dem vorgestellten Fall möchte der Benutzer den 12. Lesezugri auf a in just_do_it
manipuliert sehen, um diesen nach der Rückgabe auch betrachten zu können.
Ohne Eingri ist die Ausgabe ganz oensichtlich 2. Eine Manipulation bei besagter
36

4.1 Analyse von Testfällen
1 # include < stdio .h >
2 # include " ../../ include / valgrind /
fi_client .h"
3
4 int just_do_it () {
5 int a = 1;
6 FITIN_MONITOR_VARIABLE (a);
7 a ++;
8 return a;
9 }
10 int main () {
11 int i = 0, result = 0;
12
13 for (; i < 12; ++ i)
14 result = just_do_it () ;
15 printf ("%d\n" , result );
16 return 0;
17 }
Abbildung 4.8: Beispielprogramm IV
Zugriszeit an Bit 2 2 hätte die Ausgabe 5 zur Folge. Auf einen Auszug der Ausgabe sei
in diesem Beispiel verzichtet. Wichtiger ist hier die Beobachtung, dass dieser Testfall auf
zwei Plattformen zwei verschiedene Ergebnisse hervorbrachte.
Auf der am Anfang des Abschnitts erwähnten Linux-Konguration erfolgte tatsächlich
die erwartete Ausgabe. Auf einem Mac-Computer mit Mac OS X v10.8.3 und dem GCC,
der Xcode v4.6.2 beiliegt, funktionierte dieses Beispiel jedoch nicht! Im Golden Run-Modus
wurden zudem deutlich mehr Lesezugrie gezählt als erwartet.
Zur Analyse des Scheiterns auf dem Mac sei in Abbildung 4.9 der Ausschnitt des
Assemblercodes gezeigt, der für die Methode just_do_it generiert wurde. In der Erwartung,
dass hinreichend kleine Rückgabewerte auf x86-Architekturen für gewöhnlich im
EAX-Register zurückgegeben werden, entsprechen die Zeilen 2 bis 5 den Instruktionen, die
man aus Sicht des Quellcodes annehmen kann. Die darauf folgenden Zeilen führen zu ober-
ächlich unergründlichem Kopieren des Rückgabewertes auf den verbleibenden Platz auf
dem Stack. Maÿgeblich für die Abweichung in der Zählung der Zugrie ist jedoch die Zeile
6: Das bloÿe Laden der Variablen a in Zeile 5 wird nicht als Zugri gezählt, es ist angesichts
des return a; auch zu erwarten. Das Kopieren eines geladenen Wertes an eine
andere Adresse jedoch wie in Zeile 6 zählt als vollzogener Lesezugri. So generiert der
Compiler Assemblercode, der dazu führt, dass nicht bloÿ ein, sondern zwei Lesezugrie je
just_do_it-Aufruf erfolgen. In diesem Wissen könnte der Benutzer die Zählung anpassen,
was für gewöhnlich jedoch voraussetzt, dass dieser den generierten Assemblercode vor der
Verwendung in Augenschein genommen hat.
Weitere Testfälle
Die Erweiterung von FITIn zieht weitere Testfälle nach sich: Aufrufe von register- oder
speicherlesenden Systemaufrufen, die Behandlung von Hilfsmethoden von Valgrind oder
den Umgang mit kleineren Datentypen.
An dieser Stelle wird jedoch nicht weiter auf diese eingegangen. FITIn wurde mit einer
Sammlung von Minimaltests vergleichbar mit den in diesem Abschnitt vorgestellten
37

4 Evaluierung von FITIn
1 [ ... ]
2 MOV EAX , [ EBP -16]
3 ADD EAX , 1
4 MOV [ EBP -16] , EAX
5 MOV EAX , [ EBP -16]
6 MOV [ EBP -8] , EAX
7 MOV EAX , [ EBP -8]
8 MOV [ EBP -4] , EAX
9 MOV EAX , [ EBP -4]
10 [ ... ]
11 RET
Abbildung 4.9: Beispielprogramm IV, x86-Assemblercode
erweitert, um die Sicherheit im Umgang mit solchen Fällen prinzipiell zu zeigen. Weiterhin
dienen diese auch als Regressionstests.
Diese Testsammlung ist der Distribution des Quellcodes von FITIn beigelegt [18]. Auf
einem x86-Computer mit Linux als Betriebssystem und einem modernen C-Compiler wird
das Bestehen aller Testfälle erwartet.
4.2 FlipSafe
FITIn wurde primär dazu konzipiert, SIHFT-Techniken zu evaluieren. In der Erstveröentlichung
von FITIn wurde dazu die SIHFT-Bibliothek FlipSafe [19] auf die Probe gestellt
[17, S.33]. Dieses Experiment wird nun mit der erweiterten Version von FITIn wiederholt.
FlipSafe ist eine in C++ geschriebene Template-Bibliothek, die verschiedene fehlertolerante
Implementierungen des Datentyps bool bereitstellt: BCBOOL, CSBOOL, EPBOOL, RMBOOL
und SHBOOL.
Betrachtet wird in diesem Experiment eine C-Portierung des Dhrystone-Tests [20].
Dhrystone zeichnet sich dadurch aus, dass auf Gleitkomma-Datentypen und, bis auf die
Standardausgabe, auf Ein- und Ausgabefunktionen verzichtet wird. Die von C. Terasa
verwendete Fassung von Dhrystone wurde jedoch einigen Modikationen unterworfen [18]:
• Es wird eine kongurierbare Anzahl (Standard: 50) von Ausführungsiterationen statt
einer zur Laufzeit dynamischen gewählt.
• Makro-Schalter wurden eingefügt, die die Verwendung der verschiedenen FlipSafe-
Datentypen ermöglichen.
• Die prozessinterne Zeitmessung der Ausführung wurde entfernt.
• Die Dhrystone-Prozedur Proc_4 wurde modiziert, um eine Fehlererkennung zu ermöglichen.
Mit dem ursprünglichen FITIn wurden zwei Experimente durchgeführt: Zum einen ein
Test, der zu zufällig gewählten Ladezeitpunkten zufällig gewählte Bits manipuliert. Zum
anderen ein Test, der für jeden einzelnen Ladezeitpunkt jedes einzelne Bit umkehrt.
Beide Experimente werden nun wiederholt, die Durchführungsprogramme wurden der
veränderten Ausgabe des erweiterten FITIn jedoch angepasst. 1 Zwischen beiden Versio-
1 Die Experimente mussten jedoch mit einer 32 Bit-Version des Benchmarks durchgeführt werden. Der
Grund dafür liegt in einem ungeklärten Fehler, der Valgrind dazu verleitet, während der Ausführung des
erweiterten FITIn für einen SB inmitten des Dhrystone-Programms fehlerhafte Plattform-Instruktionen
38

4.2 FlipSafe
nen nden unverändert 152 Lesezugrie beziehungsweise Ladeoperationen im Dhrystone-
Programm auf zu beobachtenden Speicherbereichen im Golden Run statt. Obwohl der
Fehlerinjektionszeitpunkt mit der neuen FITIn-Version abweichen wird, lässt sich erkennen,
dass der Compiler auf x86 Binärcode generiert hat, der betreende Speicherbereiche
vor jeder Verwendung erneut von dort ausliest.
Für beide Experimente sind zuerst verschiedene Versionen von Dhrystone zu kompilieren:
Eine Fassung für die ursprünglich verwendeten, anfälligen Datentypen, und jeweils
eine Fassung für jeden FlipSafe-Datentyp, die ausgewählte Variablen durch die eigene,
fehlertolerante Implementierung ersetzt.
Im zufallsgesteuerten Experiment wird zuerst ein Golden Run von FITIn ausgeführt,
der die Obergrenze der Zugrie auf Variablen ermittelt, die in einem Monitorable abgelegt
sind. Anschlieÿend werden 100 Durchläufe ausgeführt: In jedem einzelnen Durchlauf werden
Ladezeitpunkt innerhalb der Obergrenze und Bit zufällig gewählt, wobei nach wie vor
derselbe Seed-Wert verwendet wird. Als nächstes wird für jeden FlipSafe-Typen ein Golden
Run ausgeführt, der die Anzahl der Zugrie festhält. In jedem Durchlauf folgt auf die
Ausführung der ungeschützten Programmversion die Ausführung aller anderen, gesicherten
Programmfassungen. Hierbei werden die Zugriszeitpunkte versetzt, wenn die Implementierung
im Golden Run im Vergleich zum Original mehr Zugrie benötigt. Nachdem das
Experiment durchgeführt wurde, erlaubt ein weiteres Programm die Auswertung aller gespeicherten
Ausführungsausgaben: Dhrystone verfügt über eine Prüfung aller Endwerte der
Berechnung und eine Ausgabe, die belegt, ob ein Wert in Ordnung ist oder abweicht. Das
Auswertungsprogramm zählt die Anzahl der Abweichungen, gruppiert nach verwendeter
Version, zusammen.
Das zweite Experiment nimmt deutlich mehr Ausführungen vor, da FITIn für jeden
Lesezugri und jedes Bit gestartet wird. Auch hier werden am Ende die Ergebnisse aller
Programmversionen mit dem Golden Run der jeweiligen Version verglichen und die Anzahl
der aufgespürten Fehler zusammengezählt.
Der Vergleich beider FITIn-Versionen in Bezug auf das erste Experiment ist in Abbildung
4.10 zu sehen: Es gibt keinerlei Unterschiede zu verzeichnen. Trotz geänderter
Zeitpunkte der Fehlerinjektion ist EBPOOL nach wie vor nicht in der Lage, alle Fälle von
Bit-Flips abzufangen. Die Option --persist-flip=yes wirkt sich nicht auf die Zahl der
erkannten Fehler aus.
Für die vollständige Abdeckung aller möglichen Bitfehler ergibt sich ein etwas abweichendes
Bild (Abb. 4.11). Nach wie vor werden in 182 Fällen des Programms ohne SIHFT-
Techniken Fehler in der Ausgabe erkannt. Einzig die EPBOOL-Implementierung weist in
etwa doppelt so vielen Fällen Fehler auf. Es ist also anzunehmen, dass die neue FITIn-
Version diesem SIHFT-Datentyp noch deutlich mehr Schwierigkeiten bereitet. Erneut hat
die Option, manipulierte Temporärwerte an ihre Ursprungsadresse zu übernehmen, keine
Auswirkung auf die Anzahl von Fehlern. Eine qualitative Untersuchung der Fehler würde
möglicherweise jedoch einen Unterschied deutlich machen, wie in Abschnitt 4.1 gezeigt
werden konnte.
zu generieren, die zu einem Segmentation Fault führen. Dieser Fehler trat nur bei diesem 64 Bit-
Programm und der Verwendung des Parameters --include= auf, nicht
jedoch isoliert unter der Verwendung von --fnname=.
39

4 Evaluierung von FITIn
13 13
Entdeckte Fehler
10
5
2
2
0
0 0 0 0
0 0 0 0
Ungeschützt
BCBOOL
CSBOOL
EPBOOL
RMBOOL
SHBOOL
FITIn (ursprg.)
FITIn (mit/ohne --persist-flip)
Abbildung 4.10: Experiment I: FITIn-Vergleich
4.3 Performance-Strafe
Eine präzise Aussage über den Ausbremsungsfaktor von FITIn zu treen, gestaltet sich
schwierig, da verschiedene Faktoren bei der Ausführungsgeschwindigkeit zu berücksichtigen
sind:
• Der Vorgang der Disassemblierung.
• Die Zeit, die das Plug-In damit verbringt, einen IRSB zu analysieren und zu instrumentieren.
• Das Zurückkompilieren in Binärcode. Der Compiler von Valgrind hat unter Umständen
eine geringere Mächtigkeit bezüglich der Zielinstruktionswahl (siehe 3.4) und
wird Instruktionen, auch in Hinsicht auf die Instrumentierung, anders wählen und
anordnen. Eine Aussage über die Ezienzänderung des auszuführenden Binärcodes
ist aus der Sicht des Plug-Ins unmöglich, und ist trotzdem besonders wichtig, wenn
ein SB oft ausgeführt wird.
• Die Zeit, die aufgrund des zusätzlich instrumentierten Codes nötig ist.
• Der Verlust der Parallelität bei mehreren Threads auf Mehrkernprozessoren.
Aus den genannten Gründen wird in diesem Abschnitt anhand einiger Beispiele lediglich
eine Einschätzung darüber gegeben, wie sehr Valgrind mit FITIn die Ausführung eines
Programms ausbremst.
Für diese Untersuchung werden zwei Benchmarks herangezogen: Das bereits erwähnte
Dhrystone, dieses Mal jedoch in seiner originalen C-Portierung, und Linpack, ebenfalls in
einer C-Portierung [21]. Linpack ist ein Programm zur Lösung von linearen Gleichungssystemen,
das im Unterschied zu Dhrystone auch Gleitkomma-Datentypen verwendet. Beide
Benchmarks verfügen über ein eigenes Bewertungsschema: Dhrystone stellt das Ergebnis
in Form einer VAX MIPS-Einstufung aus, das Ergebnis von Linpack wird in MFLOPS
(Mega Floating Point Operations Per Second) ausgedrückt. In beiden Fällen werden dazu
prozessinterne Zeitmessungen vorgenommen und diese unter Umständen mit weiteren
Faktoren verrechnet. Ebenfalls besitzen beide Benchmarks nur eine geringe Abhängigkeit
40

4.3 Performance-Strafe
600
604
Entdeckte Fehler
400
200 182 182
300
0
0 0 0 0
0 0 0 0
Ungeschützt
BCBOOL
CSBOOL
EPBOOL
RMBOOL
SHBOOL
FITIn (ursprg.) FITIn (mit/ohne --persist-flip)
Abbildung 4.11: Experiment II: FITIn-Vergleich
von der Geschwindigkeit des Sekundärspeichers, da lediglich am Ende das Ergebnis in eine
Datei geschrieben wird.
Es ist also möglich, zwei verschiedene Messungen mit den beiden Programmen vorzunehmen:
Die Messung der tatsächlichen Ausführungszeit, wie sie von der Kommandozeile
aus gesehen wird, und die Untersuchung der jeweiligen Bewertungsschemata. Es gelten
dieselben Ausführungsbedingungen, die bereits in Abschnitt 4.1 vorgegeben wurden, die
Programme wurden jedoch zur Messung ausschlieÿlich als 32 Bit-Programm betrachtet.
Es werden für beide Untersuchungen drei Ausführungsprole verwendet: Die Ausführung
des jeweiligen Benchmarks ohne Valgrind, die Ausführung des Benchmarks mit Valgrind
und dem Plug-In Nulgrind oder none, das keine Instrumentierung vornimmt, und die
Ausführung mit Valgrind und FITIn unter voller Betrachtung aller Benutzercode-SBs, jedoch
ohne Durchführung einer Fehlerinjektion. Die Einbeziehung des none-Plug-Ins erlaubt
eine Einschätzung über die Einbuÿe, die allein durch Valgrind zustande kommt.
Die Messung der Ausführungszeit wird von einem Ruby-Programm vorgenommen, das
die verschiedenen Ausführungsprole durchführt. In jedem Ausführungsprol wird dieselbe
Anzahl von Benchmark-Durchläufen ausgeführt und die Gesamtausführungszeit durch
die Anzahl der Durchläufe geteilt. In jedem Fall ist ein kleiner zeitlicher Anteil des Ruby-
Prozesses enthalten, der angesichts der Gesamtausführungszeit die auf der Testkonguration
nie unterhalb etlicher Sekunden lag jedoch zu vernachlässigen ist.
Die Ergebnisse der Untersuchung sind in Abbildung 4.12 zu nden. Die in Sekunden
gemessenen Zeiten wurden auf das Ausführungsprol des nativen Durchlaufs normiert, da
die Betrachtung der Vervielfachung der Ausführungszeit und der Vergleich untereinander
hier im Vordergrund stehen.
Auällig in den Ergebnissen der Ausführungszeitmessung ist, dass Dhrystone durch
beide Plug-Ins etwa doppelt so stark ausgebremst wird wie Linpack. Doppelter Verwaltungsaufwand
durch Valgrind kann ausgeschlossen werden, da beide Programme in Valgrind
vergleichbar viele SBs hervorbringen. Eine mögliche Theorie ist, dass Dhrystone
deutlich stärker als Linpack unter der Aushebelung von Optimierungen seitens des Quell-
41

4 Evaluierung von FITIn
Bremsfaktor der Ausführungszeit
6
4
2
3,35
1,56
1 1
2,8
6,9
Linpack Dhrystone
ohne Valgrind none fitin
Abbildung 4.12: Vergleich der Ausführungszeiten
codes leidet. Für fundierte Aussagen ist jedoch eine tiefere Analyse beider Programme in
Valgrind nötig. In diesem Beispiel hat der Benutzer mit FITIn bis zu sieben Mal länger
auf die Ausführung zu warten als ohne.
In der nächsten Untersuchung werden erneut alle Ausführungsprole benutzt, anstatt
einer Zeitmessung werden jedoch nach einem Durchlauf die numerischen Benchmarkwerte
aus der Ergebnisdatei extrahiert und diese am Ende des Prols gemittelt. Die verschiedenen
Skalen werden auf die Werte normiert, die sich aus den Durchläufen ohne Valgrind ergeben,
sodass der Zeitverlust durch Valgrind besser zu erkennen ist. Die Beobachtungsergebnisse
sind in Abbildung 4.13 visualisiert.
normierte Benchmarkwerte
1
0,8
0,6
0,4
0,2
0
1 1
0,32
0,26
6 · 10 −3 7 · 10 −3
Linpack Dhrystone
ohne Valgrind none fitin
Abbildung 4.13: Vergleich der Benchmarkergebnisse
In der Untersuchung der prozessinternen Messungen ist nur ein geringfügiger Unterschied
zwischen Dhrystone und Linpack auszumachen. Viel erstaunlicher ist der Abstand
zwischen den Plug-Ins none und FITIn: Ein Durchlauf mit FITIn resultiert nur in einem
42

4.4 Speicherbedarf
Vierzig- bzw. Fünfzigstel des Benchmarkwerts im Vergleich zu none. Im Vergleich zum
Valgrind-freien Durchlauf betragen die Benchmarkwerte sogar nur rund 1
150
des Ursprungs.
Bei der ersten Betrachtung mögen die Untersuchungsergebnisse der beiden Experimente
widersprüchlich wirken. Die Zeitmessungen werden von den Benchmarks allerdings engmaschig
um tatsächliche Berechnungsabschnitte herumgelegt, sodass etliche Initialisierungs-,
Verwaltungs- und Abschlussvorgänge seitens des Programms sowie Valgrinds unberücksichtigt
bleiben.
Die Instrumentierung eines SB in FITIn involviert mehrere Fälle, in denen Daten den
beiden Instrumentierungslisten loads und replacements hinzugefügt und anschlieÿend
sortiert werden müssen. Für n IRTemp, die erfasst werden müssen, ist je SB ein Aufwand
von O(n log n) für das Hinzufügen notwendig. Für alle IRTemp eines SB, die insgesamt m
Mal auftreten, ist für die Auösung der Ersetzung und das Nachschlagen der Daten der
IRTemp im schlimmsten Fall mit einem Aufwand von O(m · n log n) zu rechnen.
Zur Ausführungszeit fallen die Hilfsmethoden von FITIn ins Gewicht. Nicht einzig
durch die Ausführungszeit, sondern auch weil zusätzliche Kopierinstruktionen nötig sind,
um diesen etwa Parameter gemäÿ der Aufrufkonvention zu übergeben. Jedoch steht einzig
die Methode preLoadHelper in nicht-konstanter Abhängigkeit von Daten, da diese für jede
Ladeadresse die Liste monitorables zu durchsuchen hat. Auÿerhalb des instrumentierten
Binärcodes wiegt zusätzlich das sortierende Einfügen von Monitorable, das beim Erkennen
eines FITIn-Makros vorgenommen wird. Für das Beispiel der beiden Benchmarks sind diese
Fälle jedoch nur im Rahmen des zusätzlichen Aufrufcodes zu betrachten, da unmodizierte
Programme verwendet wurden, die folglich keine Monitorable verzeichnen können.
Unbestritten ist die Tatsache, dass FITIn einen signikanten bis gravierenden Einbruch
in der Ausführungsperformance mit sich bringt. Welchen Bremsfaktor den der Gesamtausführungszeit
oder den eines bestimmten Rechenabschnitts man betrachten möchte,
hängt letztendlich vom Benutzerinteresse ab. Ein Benutzer, der wissen möchte, wie viel
langsamer ein Programm mit FITIn ausgeführt wird, ist sicherlich an der Gesamtausführungszeit
interessiert. Schlieÿlich besteht bereits durch Valgrind ein signikanter Geschwindigkeitsverlust,
vom Aufgeben der Parallelität ganz abgesehen. Möchte man hingegen eine
möglichst präzise Aussage über FITIn treen, ist ein einzelner SB in Instrumentierung
sowie Ausführung zu betrachten.
Allerdings sind die durchgeführten Untersuchungen bloÿ ein kleiner Ausschnitt dessen,
was für eine gestützte Aussage wirklich nötig ist: Die Wahl einer gröÿeren Programmstichprobe,
das Durchführen der Messungen auf verschiedenen Plattformen und verschiedenen
Compiler-Optimierungsstufen und die Berücksichtigung von Multithreading.
Optimierungspotential bietet FITIn etwa bei der Anordnung von case-Blöcken in
zwei switch-Anweisungen, die die statistische Häugkeit von VEX IR-Instruktionen und
-Ausdrücken berücksichtigen sollten. Weiterhin ist die Verwendung von XArray in Hinblick
auf das Einfügen von Elementen teurer als etwa ein AVL-Baum. Auch das Erschöpfen der
Ersetzung eines IRTemp mit Tupeln aus replacements lieÿe sich wahrscheinlich optimieren,
indem statt des Anlegens von Ketten von Tupeln bloÿ bestehende Tupel mit dem letzten
anzuwendenden IRTemp aktualisiert würden und das Ersetzen damit von O(n log n) auf
O(log n) reduziert werden könnte.
4.4 Speicherbedarf
FITIn hält für die gesamte Ausführungszeit drei Arrays konstanter Gröÿe bereit, die über
dieselbe Anzahl von Indizes für den jeweiligen Datentyp verfügen wie die Registerschatten-
43

4 Evaluierung von FITIn
tabelle von Valgrind Bytes einnimmt. Für die Tabellen der Typen IRTemp, Addr (doppelte
Anzahl von Indizes) und SizeT ergibt sich auf einem x86-Computer ein konstanter Gebrauch
von etwa 5,3kB. Auf einem AMD64-Computer beträgt die Gesamtgröÿe der eigenen
Schattentabellen etwa 23kB.
Für die Instrumentierung kann jeder SB für sich betrachtet werden: Ist n die Anzahl
von Ladeoperationen, die FITIn mit preLoadHelper instrumentiert, so wächst der
Speicherbedarf für den Datentyp LoadData linear zu n. Ist m die Anzahl der Verwendungen
eines geladenen IRTemp, so ist zu erwarten, dass die Ersetzungsliste vom Typ ReplaceData
auf O(n·m) anwächst. Weiterhin wird eine Kopie des originalen IRSB erzeugt, deren Gröÿe
durch die Instrumentierung linear zur ursprünglichen Anzahl von Instruktionen wächst.
Zur Ausführungszeit eines jeden einzelnen SB wird die XArray-Liste load_states mit
jedem Aufruf von preLoadHelper gefüllt. Sind also n dieser Aufrufe platziert worden,
wächst diese Liste vom Datentyp LoadState linear zu n. Über alle SB hinweg wird die Liste
von Monitorable geführt. Da sichergestellt ist, dass je Startadresse nur ein Monitorable
existieren kann allenfalls der Wert der Ladegröÿe kann erhöht werden wächst die Liste
monitorables nur linear in Abhängigkeit aller paarweise unterschiedlichen Startadressen,
die im Benutzercode speziziert werden.
Bei der Benutzung von FITIn ist demnach keine Warnung vor ausartendem Speicherverbrauch
auszusprechen. Anzumerken ist jedoch, dass diese Untersuchung interne Gegebenheiten
von Valgrind auÿer Acht lässt.
4.5 Zwischenfazit
Die Betrachtung der fehlgeschlagenen Tests aus Abschnitt 4.1 oenbart, mit welchen Schwierigkeiten
die Benutzung von FITIn verbunden ist: dem Weg vom Quellcode zum Binärcode
und in Valgrind von der Segmentierung und Disassemblierung des Binärcodes zum Plug-In.
Der erste kritische Punkt ist die Übersetzung des Quellcodes und die damit verbundene
Wahl von Instruktionen. Selbst bei deaktivierten Optimierungsstufen kann sich der Benutzer
nicht in der Sicherheit wiegen, dass der Compiler Binärcode generiert, der sich auf die
Operationen des Quellcodes beschränkt. Zu den transparenten Operationen gehören beispielsweise
zusätzliche Kopiervorgänge von Werten oder auch Gröÿenkonvertierungen. Um
einer Diskrepanz zwischen den im Quellcode gezählten und den tatsächlich vorgenommenen
Variablenzugrien vorzubeugen, darf sich der Benutzer nur auf die generierten Instruktionen
verlassen. Bei gröÿerem Quellcode und anspruchsvolleren Mastering-Prozessen ist das
Generieren der Assemblerausgabe des Compilers jedoch mühselig und fordert den Benutzer
zusätzlich dazu auf, das Zwischenergebnis so zu begutachten, dass er die kritischen
Abschnitte vollständig erkennen und auch die Zugrie zuverlässig zählen kann.
Bei der Verwendung von beobachteten Variablen als Abbruchkondition einer Schleife
ist ebenso Vorsicht geboten, allerdings ist der Benutzer hier weitestgehend machtlos: Valgrind
kann die Instruktionen so auf verschiedene SBs aufteilen, dass etwa die erste oder
die letzte Evaluierung der Sprungkondition abseits des Schleifenkörpers stattndet. Wird
die Kondition für die Benutzung zwischen verschiedenen SBs in der Registerschattentabelle
abgelegt und wird diese zwischenzeitlich modiziert, ist es für FITIn unmöglich, diese
Zugrie zu erfassen.
Weiterhin ist die Übersetzung von Binärcode nach VEX IR ein Minenfeld von Fehleranfälligkeiten:
So konnte auf AMD64 beobachtet werden, dass nach Lade-Instruktionen, auf
die ein PUT folgt, 32 Bit-Datentypen wie int zuvor auf 64 Bit erweitert werden. Ein solcher
Fall ist beispielsweise eine registerbasierte Prozedurrückgabe. Die Konvertierungsoperati-
44

4.5 Zwischenfazit
on als Unop-Instruktion der VEX IR stellt jedoch im allgemeinen Fall einen Lesezugri
dar, der im Unterschied zu einer 32 Bit-Plattform die Anzahl der Verwendungen zusätzlich
erhöht. FITIn verfolgt daher auf 64 Bit-Plattformen die IRTemp über diese Konvertierungsoperationen
hinaus. Dieser Fall stellt die einzige Spezialbehandlung von FITIn dar, da das
Plug-In auf AMD64 für Standard-Datentypen sonst faktisch unbenutzbar ist. Es ist jedoch
unklar, ob auf weiteren Plattformen oder bei anderen Instruktionen ähnlich gelagerte Fälle
ans Tageslicht gelangen werden. Insbesondere bei bisher nicht untersuchten, semantisch
komplexen Instruktionen auf CISC-CPUs ist davon auszugehen.
Auf die Behandlung von Spezialfällen, die die Zählung abweichen lassen, etwa auf
heuristische Art und Weise, sollte in einem Werkzeug wie FITIn jedoch generell verzichtet
werden. Schlieÿlich könnte eine Konstellation von VEX IR-Instruktionen nicht einzig
der Modellierung einer komplexeren Instruktionen herrühren, sondern tatsächlich durch
den Benutzer beabsichtigt sein, etwa eine Hin- und Herkonvertierung von Daten. Mit dem
im vorherigen Paragraphen genannten Beispiel einer Spezialbehandlung wird dieser Benutzercode
nun möglicherweise interferieren. Ebenso ist die Ausführungsplattform für ein
Valgrind-Plug-In transparent, sodass Sonderbehandlungen nicht zuverlässig an- und abgeschaltet
werden können. Auch der Quellcode von FITIn würde dabei stark an Wartbarkeit
und Erweiterbarkeit einbüÿen.
Die Performance-Strafe durch FITIn sollte mit Blick auf die Gesamtausführungszeit
in einem akzeptablen Rahmen liegen. Für die Reduzierung der theoretischen Kosten der
Instrumentierung eines einzelnen Superblocks dürfte jedoch noch ein signikantes Potential
existieren.
45

5 Konkurrierende Ansätze
In diesem Kapitel werden einige ähnliche Projekte vorgestellt, die eine Bitfehlerinjektion
in Register von Benutzerprogrammen ermöglichen. Zusätzlich werden zwei weitere DBI-
Frameworks vorgestellt und in Hinblick auf FITIn mit Valgrind verglichen.
5.1 Programme
FERRARI
Mit FERRARI wurde bereits 1992 ein wissenschaftliches Projekt zur Fehlerinjektion implementiert
[22]. FERRARI macht sich unter Unix die Fähigkeiten von Systemaufrufen
zu Nutze, um in einem Zielprozess während der Ausführung Eingrie vorzunehmen. Dazu
wird ein Manager-Prozess gestartet, der einen Kindprozess mittels fork(2) erstellt und
durch den ptrace(2)-Systemaufruf die Manipulierbarkeit durch einen externen Prozess
erlaubt. Schlieÿlich ersetzt der Kindprozess sich mit dem Aufruf von execv(3) durch den
Zielprozess, der nun unter einer gewissen Kontrolle des Managers steht. Das Programm
bietet drei Möglichkeiten zur Fehlerinjektion und zwei verschiedene Fehlerklassen an. Angebotene
Fehlerinjektionsmethoden sind:
• Eine Fehlerinjektion in den Prozessspeicher des Zielprogramms vor der Ausführung
der ersten Instruktion.
• Das Zählen von Vorkommen von gewählten Speicheradressen, wobei beim n-ten Vorkommen
eine Softwareunterbrechnung stattndet und der Fehler injiziert werden
kann.
• Ein Zeitnehmer, der nach Ablauf das Zielprogramm unterbricht und eine Hardwareunterbrechung
signalisiert. Diese Methode ist jedoch, wie bereits in Abschnitt 2.1
erwähnt, für reproduzierbare Ergebnisse ungeeignet.
FERRARI erlaubt vorübergehende Fehler, die auf eine einzelne Instruktion begrenzt
sind, und permanente Fehler, die unbeschränkt lange leben können. Eine Bitfehlerinjektion
in ein Register wird als vorübergehende Fehlerinjektion angeboten.
Der modulare Aufbau soll Portierungen auf verschiedene Architekturen und Betriebssysteme
ermöglichen können, als unterstütze Plattformen werden SPARC/SunOS, RS/
6000/AIX und VAX/VMS aufgeführt. Über den aktuellen Stand von FERRARI ist jedoch
nichts bekannt.
FITgrind
Bei FITgrind handelt es sich wie bei FITIn ebenfalls um ein Werkzeug, das auf Valgrind
aufsetzt. FITgrind wird vorgestellt als Werkzeug, das es dem Benutzer ermöglicht, zur Fehlerinjektion
fault probabilities, fault types, and target applications 1 [10, S.38] wählen zu
können. Obwohl keine Implementierungsdetails erwähnt werden, ist anzunehmen, dass die
Kernidee bei FITgrind die Verwendung einer Fehlerwahrscheinlichkeit ist. Die Verwendung
eines Seed-Wertes erlaubt die Reproduzierbarkeit von Fehlerinjektionsszenarien.
1 Deutsch: Fehlerwahrscheinlichkeiten, Fehlerklassen und Zielanwendungen
47

5 Konkurrierende Ansätze
Zwar wird im Gegensatz zu FITIn keine Bearbeitung des Quellcodes vorausgesetzt,
ein Werkzeug wie FITgrind erlaubt im Gegenzug jedoch keine gezielte Analyse des Fehlerverhaltens
in bestimmten Programmabschnitten oder eine bewusste Evaluierung von
SIHFT-Techniken.
Auch bei FITgrind liegen keine weiteren Informationen zur Entwicklungsaktivität vor.
In der von 2006 vorgestellten Form kann dieses Plug-In unter Valgrind aktuell nicht mehr
verwendet werden, da Valgrind die Zwischenrepräsentation UCode mittlerweile durch VEX
IR ersetzt hat.
Xception
Xception ist als Fehlerinjektionswerkzeug für PowerPC-Prozessoren konzipiert worden [23].
Es bedient sich dabei etlicher Analyse- und Debug-Fähigkeiten dieser Prozessorarchitektur,
um auf das Zielprogramm mittels Hardwareunterbrechungen Einuss nehmen zu können.
Der Quellcode des Zielprogramms ist nicht erforderlich, kann jedoch zur Vermeidung eines
zusätzlichen Steuerungsprozesses herangezogen werden.
Unter Xception können Fehler in etliche Komponenten injiziert werden:
• In Benutzerregister.
• In den Adress- oder Datenbus.
• In verschiedene Funktionseinheiten der CPU, z.B. die MMU oder FPU.
• In den Arbeitsspeicher.
Ähnlich wie bei FERRARI können Fehler bei der Verwendung gewählter Speicheradressen
oder nach Ablauf eines Zeitnehmers in eines der aufgeführten Ziele injiziert werden.
Für Register und Arbeitsspeicherzellen unterstützt Xception nicht nur Bit-Flips sondern
auch eingerastete Bits.
Dem Benutzer stehen auf einem Host-Computer von Xception Programme zum Verwalten
und Auswerten der Fehlerinjektion zur Verfügung. Die Ausführung und die Auswertung
des Zielprogramms können so auf separaten Computern vorgenommen werden.
Das Ursprungsprogramm wurde mutmaÿlich kommerzialisiert: Die Firma Critical Software
mit Sitz in Coimbra, Portugal am selben Ort, an dem die Forschungseinrichtung
1995 die Erstversion von Xception vorstellte vertreibt mittlerweile eine industrielle Version
unter demselben Namen. Nach eigenen Angaben verfügt die Software nun auch über
Unterstützung von x86-CPUs [24, S.1].
5.2 DBI-Frameworks
Intel Pin
Pin ist kein Fehlerinjektionswerkzeug, sondern ein weiteres DBI-Framework [25]. Es steht
für x86 und AMD64-Prozessoren zur Verfügung und unterstützt im Unterschied zu Valgrind
auch Windows.
Pin kann das zu untersuchende Programm von sich aus starten oder auch an einen bestehenden
Prozess angefügt werden. Ebenso ist immer ein Plug-In, ein Pintool, anzugeben,
welches die tatsächliche Analyse und Instrumentierung vornehmen wird.
Anders als Valgrind, das dem Plug-In ausschlieÿlich ganze Superblocks bereitstellt,
erlaubt Pin auf Verlangen des Pintools weitere Behandlungsmöglichkeiten:
• Trace-Instrumentierung: Ein Trace besteht aus mehreren Basic Blocks (BB) von
Instruktionen. BBs können im Unterschied zu SBs, wie in Valgrind, nur an einer
48

5.2 DBI-Frameworks
Stelle, nämlich am Ende, verlassen werden. Pin stellt Traces und BBs anhand des
Abzweigungsverhaltens einzelner Instruktionen zusammen.
• Instruktionsweise: Dem Pintool wird jede Instruktion einzeln übergeben.
• Abbildungs-Instrumentierung: Ein ganzes Programmabbild kann mittels Iteration
über Sektionen, Prozeduren oder Instruktionen analysiert und instrumentiert werden.
• Prozedur-Instrumentierung: Eine gewählte Prozedur wird vollständig zur Instrumentierung
übergeben.
Die Zwischenrepräsentation von Pin wird in Form eines Abbilds auf ein eigenes API
betrachtet, das dem Pintool-Entwickler Eigenschaften in Bezug auf Register- und Speicherverhalten
der Instruktionen abstrahiert. Dieses API erlaubt jedoch stärker als VEX IR
Rückschlüsse auf die tatsächlich verwendeten Speicherorte und -operationen. Dadurch ist
es Pin möglich, die abgebildeten Instruktionen beinahe identisch in Binärcode zurückzukompilieren.
Anders als bei Valgrind sind jedoch nicht alle Aufrufe von Pintool-Callbacks threadsicher,
der Pintool-Entwickler hat also eventuell Blockierungsmaÿnahmen für sein Plug-In
zu benutzen. Mit Rücksicht auf Blockierungen seitens des Programms und seitens Pin ist
auch in Bezug auf Dead-Locks Aufmerksamkeit gefordert.
Ein Pintool kann ebenfalls Callbacks für Zeitpunkte vor und nach einem Systemaufruf
registrieren. Im Gegensatz zu Valgrind signalisiert Pin jedoch nicht, ob dabei eine Registeroder
Speicheroperation ansteht oder durchgeführt wurde. Diese Fälle hat ein Pintool selbst
zu erkennen und zu behandeln.
Eine besondere Fähigkeit in Hinsicht auf FITIn fehlt Pin jedoch: Es gibt keine vorhandene
Möglichkeit, dass das auszuführende Programm mit Pin oder mit dem Pintool
kommunizieren kann. Ein Mechanismus einschlieÿlich einer C-Header-Datei für das Zielprogramm
wie bei Valgrind, der zu diesem Zweck zusätzliche Daten auf dem Stack-
Speicher ablegt, müsste manuell für ein Pintool implementiert werden.
DynamoRIO
Das quelloene DBI-Framework DynamoRIO ist unter Windows und Linux auf x86 und
AMD64-Prozessoren lauähig [26]. Werkzeuge, die auf der Basis von DynamoRIO entwickelt
werden, heiÿen Clients. DynamoRIO stellt den Benutzercode in zwei Einheiten zur
Verfügung: Basic Blocks und Traces. BBs, die mehrfach in einer bestimmtem Reihenfolge
hintereinander ausgeführt werden, werden von DynamoRIO zu Traces zusammengestellt,
sodass zwischen den einzelnen BBs kein Rücksprung mehr in DynamoRIO-Code erfolgen
muss. Dieser Mechanismus wird benutzt, um besonders häug verwendete Codeabschnitte
zu beschleunigen.
Eine Zwischenrepräsentation als solche existiert nicht. Soll der Client über die Behandlung
allgemeiner Ereignisse hinaus arbeiten oder instruktionsgenaue Analysen oder Modi-
kationen vornehmen, muss dieser den Instruktionsblock explizit in eine API-Darstellung
decodieren lassen. Das API von DynamoRIO erlaubt dabei die Repräsentation und Verwendung
jeder einzelnen x86- und AMD64-Instruktion. Allerdings stehen dem Client-
Entwickler ebenso Methoden zur Verfügung, die Abfragen über verwendete Speicherstellen
und -operationen einer Instruktion zulassen.
DynamoRIO stellt dem Client eine ganze Reihe von Events bereit, zu welchen dieser
Callbacks hinterlegen kann: etwa bei dynamischem Nachladen von Bibliotheken, vor und
nach Systemaufrufen und zu Beginn und Ende von weiteren Threads. Ähnlich Pin erfordert
DynamoRIO vom Client-Entwickler gröÿere Selbstverantwortung in Bezug auf Multithreading
oder dem Erkennen bestimmter Operationen, die Valgrind in eigenen Ereignissen
49

5 Konkurrierende Ansätze
zusammenfasst.
Client-Entwickler werden eindringlich dazu aufgefordert, dass ihr Werkzeug bei der
Ausführung eines Zielprogramms transparent für dieses zu funktionieren hat. Vor diesem
Hintergrund existiert auch in DynamoRIO kein vorgesehener Weg zur Kommunikation
zwischen Zielprogramm und Client.
5.3 Vergleichsfazit
Es scheint, dass der Ansatz von FITIn, Möglichkeiten zur Fehlerinjektion im Quellcode
abzustecken und diese unter Zuhilfenahme eines DBI-Frameworks zu nutzen, für ein Fehlerinjektionswerkzeug
eher ungewöhnlich ist. Ungeachtet der Schwierigkeiten in Verbindung
mit Valgrind, die in Abschnitt 4.1 erläutert wurden, erlaubt das Vorgehen von FITIn dem
Benutzer jedoch eine gröÿere Kontrolle über den Zeitpunkt der Fehlerinjektion. Weiterhin
ist es aufgrund der Bindung an Speicheradressen nicht erforderlich, dass der Benutzer
sich mit dem Speicherort auseinandersetzen muss, an dem ein Bit-Flip stattnden soll. Es
ist überwiegend nicht einmal notwendig, zur Kompilierungs- oder Ausführungszeit einen
relativen oder absoluten Adresswert zu kennen. So ist im Vergleich zu den vorgestellten
Lösungen nicht prinzipiell eine Vor- oder Nachanalyse im Assembler- oder Binärcode des
Programms durchzuführen, um die Bedeutung einer gewählten Speicheradresse zu ermitteln.
Auch ein Vergleich von Alternativen zu Valgrind erlaubt einige interessante Gedanken:
Valgrind bietet dem Plug-In-Entwickler durch die Abschirmung von Prozessorarchitektur,
Betriebssystem, Multithreading und besonderer Vorkommnisse einen besonders hohen
Grad an Komfort, da sich dieser damit grundsätzlich nicht auseinandersetzen braucht.
Die Vorteile liegen eindeutig in der Übersichtlichkeit der VEX IR-Spezikation und dem
Registrieren von Callbacks für weitere Ereignisse, die es erlauben, ein Plug-In für eine
DBA-Anwendung zügig zu entwickeln. Als Nachteile sind der aufwendige Prozess von Disassemblierung
und Rekompilierung und der Verlust der Parallelität zu erwähnen. Die Übersetzung
nach VEX IR zieht weitere Konsequenzen für ein Werkzeug wie FITIn nach sich,
das über die reine Binäranalyse hinausgeht und dabei eine transparente Benutzung ermöglichen
möchte.
Ein Framework wie Pin oder DynamoRIO könnte möglicherweise einige Probleme,
die der Übersetzung des Binärcodes nach VEX IR geschuldet sind (siehe Abschnitt 4.1),
hinfällig machen: Eine ursprungsgetreue Abbildung der Binärinstruktionen verhindert ein
weiteres Verzerren der gewünschten Anwendungsmethode. So wäre es für den Benutzer ein
deutlich transparenterer Prozess, Abweichungen des Zugriszählers alleine im von ihm verwendeten
Kompilierungsvorgang zu suchen. Umgekehrt beschränkt die Verwendung dieser
alternativen Frameworks die Plattformen auf x86 und AMD64 mit geringer Aussicht auf
zukünftige Portabilität. Ebenfalls nicht zu vernachlässigen ist der wohl deutlich gröÿere
Entwicklungsaufwand, ein Programm wie FITIn in Bezug auf alle denkbaren Spezialfälle
von Systemaufrufen, Multithreading und Kommunikation mit dem Zielprogramm auf einer
dieser Plattformen zu realisieren.
50

6 Abschluss
6.1 Zusammenfassung
In dieser Arbeit wurde das Programm FITIn maÿgeblich erweitert. FITIn als Valgrindbasiertes
Fehlerinjektionswerkzeug besaÿ zu Beginn der Entwicklung nur die Fähigkeit,
auf das Auslesen von Speicherinhalten an Adressen zu gewählten Variablen zu achten.
Vor einem vom Benutzer gewählten Ladezeitpunkt führte FITIn einen Bit-Flip auf dem
Prozessspeicher an einem gewählten Bit durch. Wie in Abschnitt 3.6 gezeigt werden konnte,
ist dieses Verfahren unpraktikabel, wenn der Benutzer zu einem späteren Zeitpunkt einen
Fehler injiziert wünscht, der Wert aber durch das Halten in einem Register nicht erneut
aus dem Prozessspeicher geladen wird. FITIn dahingehend zu erweitern, diesen Fall auf
eine möglichst transparente Art und Weise für den Benutzer zugänglich zu machen, stand
im Mittelpunkt dieser Arbeit.
Zur Einordnung von FITIn in Hinsicht auf Typen von Bitfehlern, Injektionsebenen
und zu manipulierenden Daten wurde die Fehlerinjektion in Kapitel 2 von einem globalen
Stand aus betrachtet. Grundsätzlich erönen sich einem Benutzer die Möglichkeiten zur
hardware- oder softwarebasierten Fehlerinjektion. Bitfehler durch Hardwareprobleme oder
ein SEU in Software zu simulieren, stellt sich in gewissen Anwendungsrahmen als deutlich
ökonomischer und kontrollierbarer heraus. Für die softwarebasierte Fehlerinjektion bieten
sich etliche Ebenen an, die auf unterschiedliche Weise Bitfehler in eine Zielanwendung
einschleusen können.
Im Fall von FITIn wird das DBI-Framework Valgrind dazu verwendet, Kontrolle über
das Zielprogramm für eine Fehlerinjektion auszuüben. Der Benutzer fügt C-Makros im
Quellcode der Zielanwendung ein, die das Beobachten bestimmter Ladeadressen zulassen.
Der Benutzer steuert mit Hilfe der Kommandozeile den Fehlerinjektionszeitpunkt und das
zu manipulierende Bit. In Kapitel 3 wurde zunächst das Konzept der dynamischen Binärinstrumentierung
vorgestellt und auf die Besonderheiten von Valgrind eingegangen. Mit
Blick auf das Ziel dieser Arbeit wurden verschiedene Ansätze der Erweiterung untersucht.
Die gewählte Implementierung wurde in Abschnitt 3.6 ausführlich vorgestellt. In diesem
Kapitel wurden ebenso erste Beschränkungen beleuchtet: Insbesondere die fehlende Unterstützung
von Gleitkomma-Datentypen el dabei ins Auge, die nur schwer zu verschmerzen
sein dürfte.
Anschlieÿend wurde FITIn in Kapitel 4 etlichen Untersuchungen für die Evaluierung
verschiedener Aspekte unterzogen. Mehrere Testfälle demonstrierten den Erfolg oder auch
Misserfolg von Fehlerinjektionsszenarien unter der Verwendung von FITIn. Die Auswertung
der Fehlschläge erlaubte eine Aussage über grundsätzliche Schwierigkeiten, die durch
den Compiler oder Valgrind bedingt sind. Ebenso wurde die SIHFT-Bibliothek FlipSafe
erneut auf die Probe gestellt: Mit Ausnahme eines einzelnen Datentyps kommt die Bibliothek
weiterhin mit den vorgenommenen Bitfehlern zurecht. Für eine Einschätzung über
den Performance-Verlust eines Programms unter der Verwendung von FITIn wurden die
Benchmarks Dhrystone und Linpack betrachtet. Obgleich ein sehr starkes Ausbremsen
durch FITIn beobachtet wurde, wurde auch auf Verbesserungspotential eingegangen.
In der erlangten Erkenntnis über Stärken und Schwächen von Valgrind und FITIn wur-
51

6 Abschluss
den abschlieÿend (Kap. 5) Ansätze anderer Programme betrachtet, die ebenfalls Bitfehler
auf Registern vornehmen können. Auÿerdem wurde ein kurzer Vergleich zwischen Valgrind
und weiteren DBI-Frameworks gezogen.
6.2 Ausblick
Der Stand von FITIn, der mit dem Abschluss dieser Arbeit erreicht wurde, markiert keinesfalls
die letzte Station. An mehreren Stellen konnte gezeigt werden, dass FITIn nach wie vor
nicht nur von technischen, sondern auch von konzeptionellen Gegebenheiten eingeschränkt
wird.
Zur Erweiterung der Anwendungsmöglichkeiten von FITIn sollte das Hinzufügen der
Unterstützung der C-Datentypen float und double und möglicherweise auch der verbleibenden
SIMD-Datentypen eine hohe Priorität genieÿen. Allerdings oenbart dieser
Punkt auch, dass das Konzept von FITIn möglicherweise noch nicht hinreichend ist. Oder
andernfalls, dass es eventuell unumgänglich ist, FITIn um die Erkennung von VEX IR-
Mustern zu erweitern, da ein Belang wie dieser stark plattformabhängig ist. Zum Umgang
von FITIn mit bisher fehlgeschlagenen Testfällen in Abschnitt 4.1 ist ebenfalls eine weitere
Untersuchung sinnvoll.
In einem weniger oenen Rahmen sollte FITIn hinsichtlich des Instrumentierungsaufwands
etwas Optimierung genieÿen. Insbesondere die verwendete Listenstruktur und das
Verfahren zur Ersetzung von IRTemp sollten dabei ins Auge gefasst werden.
Da FITIn ausschlieÿlich auf den verwandten CISC-Prozessorarchitekturen x86 und
AMD64 entwickelt und getestet wurde, sind Testläufe von FITIn auf anderen Plattformen
ebenfalls interessant. Vor allem in Hinsicht auf RISC-Prozessoren, deren Instruktionen oft
semantisch ärmer sind als die von CISC-CPUs, könnten Testläufe zeigen, ob FITIn auf
diesen möglicherweise zuverlässiger zu benutzen ist.
Bisher ist FITIn darauf beschränkt, einen einzigen Bit-Flip je Programmdurchlauf
vornehmen zu können. Die Fehlersimulation lieÿe sich erweitern, indem der Benutzer bei
FITIn eine beliebige Anzahl von Fehlern in beliebig vielen Bits spezizieren kann.
52

Literaturverzeichnis
[1] Ziegler, J.F. ; Curtis, H. W. u. a.: IBM experiments in soft fails in computer
electronics (19781994). In: IBM Journal of Research and Development 40 (1996), Nr.
1, S. 318. http://dx.doi.org/10.1147/rd.401.0003. DOI 10.1147/rd.401.0003.
[2] Piotrowski, A. ; Makowski, D. u. a.: The automatic implementation of Software
Implemented Hardware Fault Tolerance algorithms as a radiation-induced soft errors
mitigation technique. In: Proceedings of IEEE Nuclear Science Symposium Conference
Record, 2008. NSS '08., 2008, S. 841846.
[3] Manteuffel, Henning: High-Level FPGA-Programmierung mit automatisch generierten
Netzwerken von Automaten, TU Hamburg-Harburg, Dissertation, 2012.
http://doku.b.tu-harburg.de/volltexte/2012/1174/.
[4] Hsueh, Mei-Chen ; Tsai, Timothy K. ; Iyer, Ravishankar K.: Fault Injection
Techniques and Tools. In: Computer 30 (1997), April, Nr. 4, S. 7582. http:
//dx.doi.org/10.1109/2.585157. DOI 10.1109/2.585157.
[5] Alme, J. ; Fehlker, D. u. a.: Radiation tolerance studies using fault injection on the
Readout Control FPGA design of the ALICE TPC detector. In: Journal of Instrumentation
8 (2013), Nr. 01, S. C01053. http://dx.doi.org/10.1088/1748-0221/8/
01/C01053. DOI 10.1088/17480221/8/01/C01053.
[6] Hayashi, Yu-ichi ; Homma, Naofumi u. a.: Non-invasive Trigger-free Fault Injection
Method Based on Intentional Electromagnetic Interference. In: The Non-Invasive
Attack Testing Workshop (NIAT 2011), 2011, S. 1519.
[7] Nethercote, Nicholas: Dynamic Binary Analysis and Instrumentation, University of
Cambridge, A Dissertation, November 2004. http://valgrind.org/docs/phd2004.
pdf.
[8] Schmidt, David A.: Programming language semantics. In: ACM Comput. Surv.
28 (1996), März, Nr. 1, S. 265267. http://dx.doi.org/10.1145/234313.234419.
DOI 10.1145/234313.234419.
[9] Seong, Nak H. ; Woo, Dong H. u. a.: SAFER: Stuck-At-Fault Error Recovery for
Memories. In: Proceedings of the 2010 43rd Annual IEEE/ACM International Symposium
on Microarchitecture (MICRO), 2010, S. 115124.
[10] Wappler, Ute ; Fetzer, Christof: Hardware Fault Injection Using Dynamic Binary
Instrumentation: FITgrind. In: Proceedings of the Sixth European Dependable
Computing Conference (EDCC 2006), 2006, S. 3738.
[11] Portela-Garcia, M. ; Lopez-Ongil, C. u. a.: A Rapid Fault Injection Approach
for Measuring SEU Sensitivity in Complex Processors. In: Proceedings of 13th IEEE
International On-Line Testing Symposium, 2007 (IOLTS 07), 2007, S. 101106.
[12] Lindholm, Tim ; Yellin, Frank u. a.: The Java® Virtual Machine Specication.
Java SE 7. Oracle America, Inc., 2013.
53

LITERATURVERZEICHNIS
[13] Nanda, Susanta ; Li, Wei u. a.: BIRD: Binary Interpretation using Runtime Disassembly.
In: Proceedings of the International Symposium on Code Generation and
Optimization, IEEE Computer Society, 2006 (CGO '06), S. 358370.
[14] Laurenzano, M.A. ; Tikir, M.M. u. a.: PEBIL: Ecient static binary instrumentation
for Linux. In: Proceedings of the IEEE International Symposium on Performance
Analysis of Systems Software (ISPASS), 2010, S. 175183.
[15] Nethercote, Nicholas ; Seward, Julian: Valgrind: a framework for heavyweight
dynamic binary instrumentation. In: SIGPLAN Not. 42 (2007), Juni, Nr. 6, S. 89100.
http://dx.doi.org/10.1145/1273442.1250746. DOI 10.1145/1273442.1250746.
[16] Die Valgrind-Entwickler: Valgrind v3.8.1. http://valgrind.org/, 2012. [Online;
letzter Abruf 27. Mai 2013]
[17] Terasa, C.: A Valgrind-based Soft Error Injection Tool for SIHFT Evaluations, TU
Hamburg-Harburg, Master Thesis, März 2013
[18] Terasa, C. ; Heing-Becker, M.: FITIn. https://github.com/MarcelHB/
valgrind-fitin/fitin/, 2013. [Online; letzter Abruf 11. Juni 2013]
[19] Munkby, G.: FlipSafe. http://www.sts.tu-harburg.de/research/flipsafe.
html, 2011. [Online; letzter Abruf 09. Juni 2013]
[20] Longbottom, R.: Dhrystone Benchmark v2.1. http://www.roylongbottom.org.
uk/linux%20benchmarks.htm, 1996. [Online; letzter Abruf 02. Juni 2013]
[21] Longbottom, R.: Linpack Benchmark. http://www.roylongbottom.org.uk/
linux%20benchmarks.htm, 2010. [Online; letzter Abruf 02. Juni 2013]
[22] Kanawati, Ghani A. ; Kanawati, Nasser A. u. a.: FERRARI: A Flexible Software-
Based Fault and Error Injection System. In: IEEE Trans. Comput. 44 (1995),
Februar, Nr. 2, S. 248260. http://dx.doi.org/10.1109/12.364536. DOI
10.1109/12.364536.
[23] Carreira, Joao ; Madeira, Henrique u. a.: Xception: Software Fault Injection and
Monitoring in Processor Functional Units. In: Processor Functional Units, DCCA-5,
Conference on Dependable Computing for Critical Applications, 1995, S. 135149.
[24] Critical Software Ltd.: Xception. http://asd.criticalsoftware.com/upload_
case/csXCEPTION-flyer.pdf, 2005. [PDF; Online; letzter Abruf 07. Juni 2013]
[25] Intel Corporation: Pin 2.12 User Guide. http://software.intel.com/sites/
landingpage/pintool/docs/58423/Pin/html/, 2013. [Online; letzter Abruf 09.
Juni 2013]
[26] Die DynamoRIO-Entwickler: DynamoRIO API. http://dynamorio.org/docs/,
2013. [Online; letzter Abruf 08. Juni 2013]
54

Akronyme
BB Basic Block. 48, 49
D&R Disassemble-and-Resynthesize. 11, 13, 16
DBA Dynamische Binäranalyse. 810, 50
DBI Dynamische Binärinstrumentierung. 4, 810, 14, 4752
GCC GNU C Compiler. 7, 28, 31, 67, 68
JIT Just-In-Time. 7, 9
SB Superblock. 1016, 19, 21, 22, 24, 25, 29, 33, 34, 36, 3841, 43, 44, 48, 6568
SBA Statische Binäranalyse. 8, 9
SEU Single Event Upset. 5, 26, 51
SIHFT Softwareimplementierte Hardwarefehlertoleranz. 1, 15, 38, 39, 48, 51
VEX IR VEX Intermediate Representation. 1114, 16, 1821, 24, 27, 28, 3234, 36, 4345,
4850, 52, 57, 59, 60, 68
VM Virtuelle Maschine. 6, 7
55

Abbildungsverzeichnis
2.1 Taxonomie der Fehlerinjektion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Programmausführung in Valgrind . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Disassemblierung in Valgrind: x86-Programm (li.), VEX IR (re.) . . . . . . 13
3.3 Disassemble-and-Resynthesize in Valgrind . . . . . . . . . . . . . . . . . . . 14
3.4 Registerübersetzung in Valgrid: x86-Programm (li.), VEX IR (re.) . . . . . 16
3.5 Ergebnis der x86-Codesynthese . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6 Beispiel für Ansatz I, C-Programm (li.), VEX IR (re.) . . . . . . . . . . . . 18
3.7 Ansatz I: Zu x86-Programm (re.) kompilierter C-Code (li.) . . . . . . . . . . 18
3.8 Beispiel für Ansatz II, C-Programm (li.), VEX IR (re.) . . . . . . . . . . . 19
3.9 Grenzbeispiel für FITIn, x86-Programm (li.), VEX IR (re.) . . . . . . . . . 20
3.10 C-Struktur: LoadData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.11 Algorithmus zur Instrumentierung von IRTemp . . . . . . . . . . . . . . . . . 23
3.12 C-Struktur: LoadState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.13 Erweitertes LoadState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.14 Experimentelle Behandlung einer float-Addition . . . . . . . . . . . . . . . 28
4.1 Beispielprogramm I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Beispielprogramm I, VEX IR . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Beispielprogramm II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Beispielprogramm II, VEX IR (main-SB 1) . . . . . . . . . . . . . . . . . . . 34
4.5 Beispielprogramm II, VEX IR (main-SB 2) . . . . . . . . . . . . . . . . . . . 34
4.6 Beispielprogramm III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 Beispielprogramm III, VEX IR . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8 Beispielprogramm IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.9 Beispielprogramm IV, x86-Assemblercode . . . . . . . . . . . . . . . . . . . 38
4.10 Experiment I: FITIn-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.11 Experiment II: FITIn-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.12 Vergleich der Ausführungszeiten . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.13 Vergleich der Benchmarkergebnisse . . . . . . . . . . . . . . . . . . . . . . . 42
57

A Ergänzendes Material
A.1 VEX IR-Spezikation
Im Nachfolgenden ist der Aufbau von VEX IR dargestellt. Diese Spezikation wurde gemäÿ
der Datei VEX/pub/libvex_ir.h aus der Standarddistribution von Valgrind v3.8.1
aufgestellt [16].
Die Spezikation orientiert sich an der Backus-Naur-Form. Präxbehaftete Symbole
stellen Terminale dar. Nichtterminale, die in dieser Spezikation nicht abgeleitet werden
können, werden von Valgrind mit Rücksicht auf die ausführende Plattform an anderer Stelle
deniert. IROp wurde aufgrund des Umfangs weitestgehend ausgelassen. Nichtterminale, die
als Datenstruktur ein- oder zweifach dereferenziert werden müssen, werden nicht gesondert
hervorgehoben. Die Alternativen von Nichtterminalen in Iex und Ist führen zusätzlich die
Bezeichner, die im Hauptteil des Dokuments verwendet werden.
IRType ::= Ity_INVALID | Ity_I1 | Ity_I8 | Ity_I16 | Ity_I32 | Ity_I64 | Ity_I128 |
Ity_F32 | Ity_F64 | Ity_D32 | Ity_D64 | Ity_D128 | Ity_F128 | Ity_V128 |
Ity_V256
IREndness ::= Iend_LE | Iend_BE
IRConstTag ::= Ico_U1 | Ico_U8 | Ico_U16 | Ico_U32 | Ico_U64 | Ico_F32 | Ico_F32i |
Ico_F64 | Ico_F64i | Ico_F64i | Ico_V128 | Ico_V256
Ico ::= Bool | UChar | UShort | UInt | ULong | Float | Double
IRConst ::= IRConstTag Ico
IRCallee ::= Int HChar void UInt
IRRegArray ::= Int IRType Int
IRTemp ::= UInt
IROp ::= Iop_INVALID | ... | Iop_Min64Fx4
IRExprTag ::= Iex_Binder | Iex_Get | Iex_GetI | Iex_RdTmp | Iex_Qop | Iex_Triop |
Iex_Binop | Iex_Unop | Iex_Load | Iex_Const | Iex_Mux0X | Iex_CCall
IRTriop ::= IROp IRExpr IRExpr IRExpr
IRQop ::= IROp IRExpr IRExpr IRExpr IRExpr
Iex ::= Binder : Int
| Get : Int IRType
| GetI : IRRegArray IRExpr Int
| RdTmp : IRTemp
| Qop : IRQop
| Triop : IRTriop
| Binop : IROp IRExpr IRExpr
| Unop : IROp IRExpr
| Load : IREndness IRType IRExpr
| Const : IRConst
| CCall : IRCallee IRType IRExpr
| Mux0X : IRExpr IRExpr IRExpr
59

A Ergänzendes Material
IRExpr ::= IRExprTag Iex
IRJumpKind ::= Ijk_INVALID | Ijk_Boring | Ijk_Call | Ijk_Ret | Ijk_ClientReq |
Ijk_Yield | Ijk_EmWarn | Ijk_EmFail | Ijk_NoDecode | Ijk_MapFail | Ijk_TInval |
Ijk_NoRedir | Ijk_SigTRAP | Ijk_SigSEGV | Ijk_SigBUS | Ijk_Sys_syscall |
Ijk_Sys_int32 | Ijk_Sys_int128 | Ijk_Sys_int129 | Ijk_Sys_int130 |
Ijk_Sys_sysenter
IREffect ::= Ifx_None | Ifx_Read | Ifx_Write | Ifx_modify
IRDirtyFxState ::= IREffect UShort UShort UChar UChar
IRDirtyFxStates (n) ::= IRDirtyFxState IRDirtyFxStates (n -1)
IRDirtyFxStates (0) ::=
IRDirty ::= IRCallee IRExpr IRExpr IRTemp IREffect IRExpr Int Bool Int
IRDirtyFxStates (N)
IRCAS ::= IRTemp IRTemp IREndness IRExpr IRExpr IRExpr IRExpr IRExpr
IRMBusEvent ::= Imbe_Fence | Imbe_CancelReservation
IRPutI ::= IRRegArray IRExpr Int IRExpr
IRStmtTag ::= Ist_NoOp | Ist_IMark | Ist_AbiHint | Ist_Put | Ist_PutI | Ist_WrTmp |
Ist_Store | Ist_CAS | Ist_LLSC | Ist_Dirty | Ist_MBE | Ist_Exit
Ist ::= NoOp :
| IMark : Addr64 Int UChar
| AbiHint : IRExpr Int IRExpr
| Put : Int IRExpr
| PutI : IRPutI
| WrTmp : IRTemp IRExpr
| Store : IREndness IRExpr IRExpr
| CAS : IRCAS
| LLSC : IREndness IRTemp IRExpr IRExpr
| Dirty : IRDirty
| MBE : IRMBusEvent
| Exit : IRExpr IRConst IRJumpKind Int
IRStmt ::= IRStmtTag Ist
IRTypeEnv ::= IRType Int Int
IRSB ::= IRTypeEnv IRStmt Int Int IRExpr IRJumpKind Int
A.2 Instrumentierungsbeispiel
Dieser Abschnitt enthält ein umfangreicheres Beispiel für die Instrumentierung eines Programms.
Gewählt wurde tests/sample4.c aus dem FITIn-Codeverzeichnis [18]. In der
linken Spalte ist die VEX IR des IRSB von main vor der Instrumentierung zu sehen, in der
rechten Spalte nach der Instrumentierung durch FITIn (sichtbar durch --trace-flags=
01000000 bzw. --trace-flags=00100000).
Zu sehen ist, wie FITIn die Load-Operationen im Original erkennt und unmittelbar
zuvor preLoadHelper einfügt. In diesem Beispiel werden Daten geladen, die mit 8 Bit kleiner
sind als die Plattformadressbreite von 32 Bit. Um diese den fi_reg_flip_or_leave-
Aufrufen übergeben zu können, werden davor 8Uto32-Instruktionen hinzugefügt. Die Rückgabe
der Flip-Methode wird zurück in die VEX IR geführt und ersetzt das ursprüngliche
Argument der nachfolgenden Instruktion.
60

A.2 Instrumentierungsbeispiel
------ IMark (0 x804852B , 4, 0) ------ DIRTY 1: I1 ::: incrInst {0 x38026300 }()
t16 = GET : I32 (24) ------ IMark (0 x804852B , 4, 0) ------
t15 = Add32 ( t16 ,0 x14 : I32 ) t16 = GET : I32 (24)
t17 = GET : I32 (16) t15 = Add32 (t16 ,0 x14 : I32 )
STle ( t15 ) = t17 t17 = GET : I32 (16)
PUT (68) = 0 x804852F : I32 STle ( t15 ) = t17
------ IMark (0 x804852F , 4, 0) ------ PUT (68) = 0 x804852F : I32
IR - NoOp DIRTY 1: I1 ::: incrInst {0 x38026300 }()
IR - NoOp ------ IMark (0 x804852F , 4, 0) ------
PUT (68) = 0 x8048533 : I32 PUT (68) = 0 x8048533 : I32
------ IMark (0 x8048533 , 5, 0) ------ DIRTY 1: I1 ::: incrInst {0 x38026300 }()
t21 = Add32 ( t16 ,0 x11 : I32 ) ------ IMark (0 x8048533 , 5, 0) ------
t24 = LDle : I8 ( t21 ) t21 = Add32 ( t16 ,0 x11 : I32 )
t23 = 8 Uto32 ( t24 ) t58 = DIRTY 1: I1 ::: preLoadHelper [ rp =3]{0
------ IMark (0 x8048538 , 1, 0) ------ x38025b80 }(0 x382A9740 : I32 , t21 ,0 x1 : I32 )
t25 = Add32 ( t23 ,0 x1 : I32 ) t24 = LDle : I8 ( t21 )
IR - NoOp t59 = 8 Uto32 ( t24 )
IR - NoOp t60 = DIRTY 1: I1 ::: fi_reg_flip_or_leave [ rp
IR - NoOp =3]{0 x38026ff0 }(0 x382A9740 : I32 , t59 , t58 )
IR - NoOp t23 = 8 Uto32 ( t60 )
IR - NoOp DIRTY 1: I1 ::: incrInst {0 x38026300 }()
PUT (68) = 0 x8048539 : I32 ------ IMark (0 x8048538 , 1, 0) ------
------ IMark (0 x8048539 , 4, 0) ------ t25 = Add32 ( t23 ,0 x1 : I32 )
t32 = Add32 ( t16 ,0 x12 : I32 ) PUT (68) = 0 x8048539 : I32
STle ( t32 ) = t25 DIRTY 1: I1 ::: incrInst {0 x38026300 }()
PUT (68) = 0 x804853D : I32 ------ IMark (0 x8048539 , 4, 0) ------
------ IMark (0 x804853D , 5, 0) ------ t32 = Add32 ( t16 ,0 x12 : I32 )
t35 = Add32 ( t16 ,0 x13 : I32 ) STle ( t32 ) = t25
t38 = LDle : I8 ( t35 ) PUT (68) = 0 x804853D : I32
t37 = 8 Uto32 ( t38 ) DIRTY 1: I1 ::: incrInst {0 x38026300 }()
PUT (16) = t37 ------ IMark (0 x804853D , 5, 0) ------
PUT (68) = 0 x8048542 : I32 t35 = Add32 (t16 ,0 x13 : I32 )
------ IMark (0 x8048542 , 5, 0) ------ t61 = DIRTY 1: I1 ::: preLoadHelper [ rp =3]{0
t39 = Add32 ( t16 ,0 x12 : I32 ) x38025b80 }(0 x382A9740 : I32 , t35 ,0 x1 : I32 )
t42 = LDle : I8 ( t39 ) t38 = LDle : I8 ( t35 )
t41 = 8 Uto32 ( t42 ) t62 = 8 Uto32 ( t38 )
------ IMark (0 x8048547 , 2, 0) ------ t63 = DIRTY 1: I1 ::: fi_reg_flip_or_leave [ rp
t7 = Add32 ( t41 , t37 ) =3]{0 x38026ff0 }(0 x382A9740 : I32 , t62 , t61 )
PUT (40) = 0 x3 : I32 t37 = 8 Uto32 ( t63 )
PUT (44) = t41 PUT (16) = t37
PUT (48) = t37 PUT (68) = 0 x8048542 : I32
PUT (52) = 0 x0 : I32 DIRTY 1: I1 ::: incrInst {0 x38026300 }()
PUT (8) = t7 ------ IMark (0 x8048542 , 5, 0) ------
PUT (68) = 0 x8048549 : I32 t39 = Add32 (t16 ,0 x12 : I32 )
------ IMark (0 x8048549 , 4, 0) ------ t64 = DIRTY 1: I1 ::: preLoadHelper [ rp =3]{0
t43 = Add32 ( t16 ,0 x13 : I32 ) x38025b80 }(0 x382A9740 : I32 , t39 ,0 x1 : I32 )
t45 = GET : I8 (8) t42 = LDle : I8 ( t39 )
61

A Ergänzendes Material
STle ( t43 ) = t45 t65 = 8 Uto32 ( t42 )
PUT (68) = 0 x804854D : I32 t66 = DIRTY 1: I1 ::: fi_reg_flip_or_leave [ rp
------ IMark (0 x804854D , 5, 0) ------ =3]{0 x38026ff0 }(0 x382A9740 :I32 , t65 , t64 )
t46 = Add32 ( t16 ,0 x12 : I32 ) t41 = 8 Uto32 ( t66 )
t49 = LDle : I8 ( t46 ) DIRTY 1: I1 ::: incrInst {0 x38026300 }()
t48 = 8 Uto32 ( t49 ) ------ IMark (0 x8048547 , 2, 0) ------
PUT (8) = t48 t7 = Add32 ( t41 , t37 )
------ IMark (0 x8048552 , 3, 0) ------ PUT (40) = 0 x3 : I32
t51 = GET : I8 (8) PUT (44) = t41
t50 = 8 Sto32 ( t51 ) PUT (48) = t37
PUT (8) = t50 PUT (52) = 0 x0 : I32
PUT (68) = 0 x8048555 : I32 PUT (8) = t7
------ IMark (0 x8048555 , 4, 0) ------ PUT (68) = 0 x8048549 : I32
t52 = Add32 ( t16 ,0 x4 : I32 ) DIRTY 1: I1 ::: incrInst {0 x38026300 }()
STle ( t52 ) = t50 ------ IMark (0 x8048549 , 4, 0) ------
PUT (68) = 0 x8048559 : I32 t43 = Add32 (t16 ,0 x13 : I32 )
------ IMark (0 x8048559 , 7, 0) ------ t45 = GET : I8 (8)
STle ( t16 ) = 0 x8048600 : I32 STle ( t43 ) = t45
PUT (68) = 0 x8048560 : I32 PUT (68) = 0 x804854D : I32
------ IMark (0 x8048560 , 5, 0) ------ DIRTY 1: I1 ::: incrInst {0 x38026300 }()
t55 = Sub32 ( t16 ,0 x4 : I32 ) ------ IMark (0 x804854D , 5, 0) ------
PUT (24) = t55 t46 = Add32 ( t16 ,0 x12 : I32 )
STle ( t55 ) = 0 x8048565 : I32 t67 = DIRTY 1: I1 ::: preLoadHelper [ rp =3]{0
PUT (68) = 0 x80482F0 : I32 ; exit - Call x38025b80 }(0 x382A9740 : I32 , t46 ,0 x1 : I32 )
t49 = LDle : I8 ( t46 )
t68 = 8 Uto32 ( t49 )
t69 = DIRTY 1: I1 ::: fi_reg_flip_or_leave [ rp
=3]{0 x38026ff0 }(0 x382A9740 : I32 , t68 , t67 )
t48 = 8 Uto32 ( t69 )
PUT (8) = t48
DIRTY 1: I1 ::: incrInst {0 x38026300 }()
------ IMark (0 x8048552 , 3, 0) ------
t51 = GET : I8 (8)
t50 = 8 Sto32 ( t51 )
PUT (8) = t50
PUT (68) = 0 x8048555 : I32
DIRTY 1: I1 ::: incrInst {0 x38026300 }()
------ IMark (0 x8048555 , 4, 0) ------
t52 = Add32 ( t16 ,0 x4 : I32 )
STle ( t52 ) = t50
PUT (68) = 0 x8048559 : I32
DIRTY 1: I1 ::: incrInst {0 x38026300 }()
------ IMark (0 x8048559 , 7, 0) ------
STle ( t16 ) = 0 x8048600 : I32
PUT (68) = 0 x8048560 : I32
DIRTY 1: I1 ::: incrInst {0 x38026300 }()
------ IMark (0 x8048560 , 5, 0) ------
t55 = Sub32 ( t16 ,0 x4 : I32 )
t70 = GET : I32 (24)
62

A.2 Instrumentierungsbeispiel
DIRTY 1: I1 ::: VG_ ( unknown_SP_update )[ rp
=3]{0 x3803dc20 }( t70 , t55 ,0 xE18 : I32 )
PUT (24) = t55
STle ( t55 ) = 0 x8048565 : I32
PUT (68) = 0 x80482F0 : I32 ; exit - Call
63

B FITIn
In diesem Anhangskapitel wird auf die Verwendung von FITIn aus Benutzersicht eingegangen.
B.1 Benutzung
Der erste Schritt zur Verwendung von FITIn besteht im Heranziehen des Programmquellcodes
des zu untersuchenden Programms. Der Quellcode muss in C oder C++ vorliegen.
Ist Valgrind mit FITIn vollständig installiert, so ist an geeigneter Stelle die Header-Datei
valgrind/fi_client.h aus dem Installationsverzeichnis des include-Ordners von Valgrind
einzubinden. Mit dieser Header-Datei stehen nun folgende, unterstützte C-Makros
bereit:
• FITIN_MONITOR_VARIABLE(var): FITIn wird dazu aufgefordert, die Verwendungen
der Variablen var zu zählen und auf dieser gegebenenfalls einen Bit-Flip durchzuführen.
Schweigend ignoriert werden Variablen vom Typ float und double. Nicht
akzeptiert werden konstante Werte.
• FITIN_MONITOR_MEMORY(mem, size): Anstatt einer Variablen kann FITIn die Startadresse
mem und die Bereichsgröÿe size auch direkt mitgeteilt werden. Dies kann
beispielsweise bei wachsenden Arrays sinnvoll sein, die zum Zeitpunkt des Makros
noch nicht vollständig benannt werden können, jedoch nur sofern die Startadresse
des Heap-Speicherblocks nicht verändert wird.
• FITIN_UNMONITOR_VARIABLE(var): Dieses Makro fordert FITIn dazu auf, die bezeichnete
Variable var nicht länger zu betrachten.
• FITIN_UNMONITOR_MEMORY(mem, size): Analog hat FITIn mit diesem Makro aufzuhören,
für die Startadresse mem zu zählen, die zuvor mit der Gröÿe size angegeben
war.
Weitere wichtige Verwendungshinweise zu den Makros:
• Für die Erkennung aller Zugrie einer Variablen sollte das Makro immer unmittelbar
auf die Deklaration derselben folgen.
• Mehrere Makro-Verwendungen auf dieselbe Variable oder dieselbe Kombination von
Startadresse und Gröÿe verhalten sich idempotent. Nur wenn festgestellt wird, dass
die angegebene Ursprungsgröÿe gröÿer als die zuvor notierte ist, wird diese Information
intern aktualisiert.
• Soll FITIn weitere als die SBs einer einzigen Unterprozedur beobachten, sollten mit
Rücksicht auf das Stack-Verhalten auf MONITOR-Makros innerhalb einer Prozedur
stets UNMONITOR-Anweisungen erfolgen.
• Der Benutzer hat sicherzustellen, dass das Programm an der Adresse der zu zählenden
Variablen über Schreibrechte verfügt.
Im Anschluss an die Ergänzung der Makros kann der Code kompiliert werden. Für eine
möglichst einwandfreie Benutzung unter FITIn wird empfohlen, auf Optimierungsstufen zu
verzichten, Code-Inlining zu deaktivieren und Debug-Symbole hinzuzufügen.
Das Programm kann nun von Valgrind für FITIn gestartet werden:
65

B FITIn
$ valgrind -- tool = fitin < Optionen > < Programmpfad >
Zur Steuerung von FITIn ist aus folgenden Kommandozeilenoptionen zu wählen:
Option Werte Standard Beschreibung
--fnname= Funktionsname main Der Name der Prozedur, die von
FITIn beobachtet werden soll,
falls Valgrind die SBs dieser korrekt
zuordnen kann.
--include= Pfadname - Der Ordner des Quellcodes, welcher
(in Teilen) zur Erzeugung
von Debug-Symbolen im Zielprogramm
benutzt wurde. Alle
aundbaren SBs dieses Ordners
werden von FITIn beobachtet.
--mod-load-time= unsigned long 1 Der Zeitpunkt des Zugris auf
eine beobachtete Variable, zu
dem ein Bit-Flip durchgeführt
wird.
--mod-bit= unsigned char 0 Das Bit, beginnend bei 0 als niederwertigstes
Bit, das invertiert
wird.
--inst-limit= unsigned long 0 Die Anzahl von Programminstruktionen,
die höchstens auszuführen
ist, bevor das Programm
abgebrochen wird. 0 bedeutet
unbegrenzt.
--golden-run= yes, no no Ist ein Golden Run gewählt,
wird keine Fehlerinjektion vorgenommen.
--persist-flip= yes, no no Wird diese Option aktiviert,
wird ein Bit-Flip nicht nur auf
dem potentiell üchtigen Wert
vorgenommen, sondern auch an
seiner Herkunftsadresse.
--verbose - (nicht gesetzt) Diese Option erhöht die Ausgabe
von hilfreichen Informationen
zur Ausführung durch Valgrind
und FITIn. Eine mehrfache
Verwendung erhöht das
Ausgabelevel.
Weitere wichtige Verwendungshinweise zu den Kommandozeilenoptionen:
• --fnname= und --include= können nur exklusiv verwendet werden.
• Wird bei --mod-bit= ein Bit gewählt, das auÿerhalb des geladenen Speicherbereichs
liegt, wird die Injektion verworfen. Ist --persist-flip=yes gesetzt, wird ermittelt,
ob ein Bit-Flip im Prozessspeicher vorgenommen werden kann. Die Benutzung von
--verbose erlaubt einen Hinweis auf den Erfolg dieses Verhaltens.
66

B.2 Problembehandlung
• Valgrind stellt weitere Optionen zur Verfügung. Diese können über --help eingesehen
werden.
Für die Wahl des Fehlerzeitpunkts kann der Benutzer ausgehend vom Programmquellcode
eine eingeschränkt präzise Zählweise anwenden. Zu beachten ist, dass der Zählung
für alle mit einem Makro behafteten Variablen für die gesamte Ausführungszeit gilt. Die
Faustregel lautet, unter Berücksichtigung des Kontrollusses im Quellcode die Anzahl von
lesenden Verwendungen der Variablen zu zählen. Dazu einige Hinweise:
• Bedeutet in einer Prozedur die Rückgabe einer beobachteten Variablen mittels return,
dass diese in ein Register abgelegt wird (z.B. EAX auf x86), zählt dies nicht als Zugri.
• Das Kopieren an eine andere Adresse zählt als einfacher Zugri. Die Verwendung der
Kopie im folgenden Programmablauf wird von FITIn jedoch nicht berücksichtigt.
• Das Zurückschreiben eines Wertes an seine Herkunftsadresse zählt nicht als Zugri.
Dieser Fall sollte nur durch Unachtsamkeit in handgeschriebenem Inline-Assemblercode
vorkommen.
• In anonymen Ausdrücken zählt nur die tatsächliche Anzahl von Lesezugrien auf
eine Variable.
• Wird auf eine Variable abweichend von der Startadresse zugegrien, etwa über eine
frühere oder spätere Adresse (z.B. int a, b; ... ; ((char*)&a) + b;), kann
FITIn diesen Zugri nicht erkennen.
Beispiele für Quellcode, Aufrufparameter und die Zählweise können dem Abschnitt 4.1
entnommen werden.
B.2 Problembehandlung
Als Problem wird in diesem Abschnitt ein ausbleibendes oder ein anderes als das erwartete
Verhalten bezüglich der Fehlerinjektion verstanden. So sei im Folgenden eine Liste von
Punkten gegeben, die der Benutzer durchgehen sollte, wenn FITIn nicht das gewünschte
Ergebnis liefert:
1. Sind alle Hinweise aus Abschnitt B.1 berücksichtigt worden?
2. Gibt die Verwendung von --verbose weitere Hinweise auf Besonderheiten?
3. Ist das Programm ohne aggressive Optimierungen kompiliert worden? Unter GCC
können Optimierungen mit der Option -O0 deaktiviert werden.
4. Es sollte geprüft werden, ob der Compiler möglicherweise zusätzliche Instruktionen
generiert hat oder ob eine komplexere Instruktion als erwartet verwendet worden ist.
Die GCC-Option zur Ausgabe des Assemblercodes einer C-Datei lautet -S. Daraufhin
wird eine Datei mit der Endung .s erstellt, die den Assemblercode enthält. So
können neue Erkenntnisse über die tatsächliche Anzahl von Zugrien gewonnen und
die Zählweise korrigiert werden.
5. Valgrind kann mit der Kommandozeilenoption --trace-flags=00100000 gestartet
werden, um zusätzliche Einblicke in die durchlaufenen SBs eines Programms zu ermöglichen.
6. Erscheinen die Prozeduren, die mittels --fnname= oder --include= von FITIn zu
beobachten sind, in der SB-Liste von --trace-flags=00100000 in der zweiten Spalte
von rechts? Ist dies nicht der Fall und werden viele UNKNOWN_FUNCTION für das
Benutzerprogramm angezeigt, so sollte sichergestellt werden, dass das Programm
Debug-Symbole enthält. Für den GCC sollten dabei die Optionen -g oder sogar -g3
gewählt sein.
67

B FITIn
7. Erscheinen die Prozeduren, die mittels --fnname= oder --include= von FITIn zu
beobachten sind, in der SB-Liste von --trace-flags=00100000 in der zweiten Spalte
von rechts? Ist dies nicht vollständig der Fall oder werden überwiegend main für das
Benutzerprogramm angezeigt, so sollte sichergestellt werden, dass der Compiler kein
Code-Inlining durchführt. Die GCC-Option dazu lautet -fno-inline.
8. Erscheinen die Prozedureinträge, die mittels --fnname= von FITIn zu beobachten
sind, in der SB-Liste von --trace-flags=00100000 in der zweiten Spalte von rechts?
Ist dies der Fall, sollte bei der Verwendung geprüft werden, ob sich die SB-Bezeichung
und die Angabe von --fnname= decken: Möglicherweise ist ebenfalls die Aufrufsignatur
anzugeben. Bei C++-Quellcode können Namen von Instanz- und Klassenmethoden
zusätzlich dekoriert sein, was bei der Angabe ebenfalls zu berücksichtigen ist.
Zu ignorieren ist jedoch das nummerische Sux, das dem Prozedurnamen eines SB
angehängt werden kann.
9. Wie verändert sich das Verhalten von FITIn, wenn das Programm für eine andere
Plattform kompiliert wird? Auf AMD64 können in der Regel auch x86-Programme
ausgeführt werden. Für den GCC kann das Ziel durch die Angabe von -m32 zu einem
32 Bit-Programm kompiliert werden.
10. Wie weicht die statistische Ausgabe von FITIn am Ende der Ausführung von der
Erwartung ab?
11. Kann durch eine Reduzierung der beobachteten Variablen und Prozeduren ein besseres
Ergebnis erzielt werden?
Für einen Benutzer mit Kenntnissen über VEX IR erlaubt Valgrind weitere Wege zur
Analyse: Durch die Kombination der Angaben --trace-notbelow=, --trace-notabove=
(jeweils mit Angaben der Nummern zu den zu untersuchenden SBs) und den --trace
-flags=-Bitmustern 10000000 (Binärcode zu VEX IR), 01000000 (VEX IR, die FITIn
erhält) und 00100000 (VEX IR nach der Instrumentierung) kann der Anwender die Übersetzung
der ursprünglichen Instruktionen bis zur Instrumentierung der VEX IR durch
FITIn verfolgen. Dieser kann sich nun mit den nachfolgenden Fragen auseinandersetzen:
12. Lädt die Ladeoperation, die auf einen preLoadHelper einer beobachteten Variablen
folgt, einen Datentypen, der von FITIn noch nicht unterstützt wird oder gröÿer als
die Plattformadressbreite ist?
13. Folgen nach dem Ladevorgang von beobachteten Variablen bei Zugrien auf diese
Platzierungen von fi_reg_flip_or_leave und fi_reg_flip_or_leave_before_
store semantisch eventuell zu früh, zu oft oder gar nicht?
14. Folgt dem Ladevorgang einer beobachteten Variablen eine Typenkonvertierung vor
der anschlieÿenden Verwendung?
15. Wird ein beobachteter Wert in die Registerschattentabelle abgelegt und ist dieser Vorgang
mit fi_reg_set_occupancy_origin instrumentiert worden? Wird das Auslesen
des Registers an nachfolgender Stelle mit demselben Datentyp durchgeführt, der zum
Beschreiben benutzt wurde?
16. Verwendet Valgrind eigene Hilfsmethoden, die möglicherweise versetzt von der Startadresse
auf eine Variable zugreifen oder undurchsichtige Zugrie auf die Registerschattentabelle
tätigen?
Ist nach wie vor nicht zu erkennen, warum ein konkretes Problem besteht, sollte sich
der Benutzer mit allen gewonnenen Erkenntnissen an den zuständigen Entwickler wenden
oder den Quellcode von FITIn studieren.
68