Softwareverifikation Beweis

SOFTWAREVERIFIKATION
BEWEIS-TOOLS
Florian Hansel, Finja Michler
Agenda







Überblick
Deduktion
Modellprüfung
Abstrakte Interpretation
Anforderungen an Beweis-Tools
Beweis-Tools
Fazit
Überblick





Softwareverifikation: Ist das System richtig gebaut?
Softwarevalidierung: Ist es das richtige System?
Formale Verifikation im Bereich der statischen Tests
Geeignet für Hard- und Softwareverifikation
Hohe Kosten deswegen Anwendung nur bei
 Sehr
sicherheitskritischen
 Sehr teuren oder
 Sehr komplexen Systemen
Deduktion
Logikkalkül, bestehend aus verschiedenen
Beweisregeln, die zunächst in Form von Vor- und
Nachbedingungen formuliert werden.

1.
2.
3.
4.
5.
Aussagenlogik
Prädikatenlogik
Temporallogik
Höherwertige Logik
Hoare Kalkül
Vorbedingung
Wenn …
dann…
Nachbedingung
Deduktion - Aussagenlogik

Aussagen müssen mit wahr oder falsch beantwortet
werden können


Zweiwertige Logik
Mögliche Operatoren:
 Negation
 Konjunktion
 Disjunktion
 Implikation
 Äquivalenz
¬
Λ
V

↔
A
¬A
Wahr
Falsch
Falsch
Wahr
A
B
AΛB
Wahr
Wahr
Wahr
Wahr
Falsch
Falsch
Falsch
Wahr
Falsch
Falsch
Falsch
Falsch
Deduktion - Aussagenlogik



Durch geringe Ausdrucksstärke nicht komplex genug
für die Anforderungen der Verifikation
Findet im Hardwarebereich Anwendung zur
Abbildung von kombinatorischen
Hardwareschaltungen
Sonst Teilmenge der anderen Logiken
Deduktion - Prädikatenlogik

Prädikate sind Sätze mit Variablen. Die Variablen
werden mit Elementen einer gegebenen Menge
ersetzt und bilden so eine Aussage



Semi-entscheidbare Logik
Prädikatenlogik nullter Stufe (PL0): wahr, falsch
Quantoren: Allquantor ∀ und Existenzquantor ∃
∀
x: P(x,x) : Für alle x ist P(x,x) wahr.
 ∃ x: Q(x) : Es existiert ein x, so dass Q(x) wahr ist.
 ∀ x ∃ y: R(x,y) : Für alle x existiert ein y, so dass R(x,y)
wahr ist.
Deduktion – Beispiele Prädikatenlogik

… ist ein Mensch = Prädikat
 Durch
einsetzen von Eigennamen (z.B. Sokrates) wird
daraus eine Aussage : Sokrates ist ein Mensch

Quantoren ermöglichen folgende Aussagen:
 Alle
Menschen sind sterblich
 Es gibt mindestens einen rosa Elefanten

Anwendbarkeit nur auf Individuen: Menschen, Tiere,
Gegenstände…
Deduktion – Beispiele Prädikatenlogik
A
B
C
(Jemand) wird (von allen) gemocht.
 ∃x ∀y : R(x,y)
A
B
C
A
B
C
A
(Jeder) mag (jemanden).
 ∀ x ∃ y : R(x,y)
B
C
A
A
B
C
B
C
(Alle) mögen (sich selbst).
 ∀ x : R(x,x)
Deduktion - Prädikatenlogik


Entscheidbarkeit bereits ab PL1 nicht mehr erfüllt
Ausdrucksfähigkeit nicht ausreichend für
Softwareverifikation
Deduktion – Höherwertige Logik

Erweiterung zu PL1: Geltungsbereich der Quantoren
erstreckt sich nicht nur auf Variablen, sondern über
Prädikate hinweg
 Alle
Pferde sind Tiere; also sind alle Pferdeköpfe
Tierköpfe


Ermöglichen zum Beispiel Aussagen über natürliche
Zahlen
Geringes Automatisierungspotenzial
Deduktion – Verifikation nach Hoare


Grundprinzip aller deduktiven Verfahren
Aussagen in Form von Hoare-Tripeln notiert:
 {P}
S {Q}
 Unter der Annahme, dass {P} erfüllt ist, gilt nach
Ausführung des Programmfragmentes S die
Nachbedingung {Q}
 Mit Hilfe dieser Form und den Operatoren der
Aussagenlogik, können Zuweisungen (=),
Fallunterscheidungen (if), Iterationen (while) und
ähnliches abgebildet werden.
Modellprüfung

3-stufige Vorgehensweise:
1.
2.
3.

Überführung des zu verifizierenden Systems in ein
geeignetes Modell
Beschreiben der erwarteten Systemeigenschaften
Durchführen der Verifikation (Modellprüfung)
Wenn die Systemeigenschaften E in dem durch
endlich viele Zustände S beschriebenem Modell M(S)
gelten, ist das System korrekt: M(S)|= E
Modellprüfung - LTL


LTL: linear time logic
Baut auf Aussagenlogik auf und erweitert diese um
temporale Operatoren
○
f  im nächsten Zustand gilt f (temp. Schrittoperator)
 ◊ f  in mind. einem Zustand gilt f (temp.
Existenzquantor)
 □ f  in allen Zuständen gilt f (temp. Allquantor)
 gUf  g gilt, bis zu dem Zustand, bei dem f gilt
(bedingte Allquantifizierung)
Modellprüfung – Beispiele LTL
LTL Formel Bedeutung
M,2 |= ○ f
Im nächsten Zustand gilt f
M,0 |= □ f
In allen Folgezuständen gilt f
M,0 |= ◊ f
In irgendeinem Folgezustand gilt f
M,0 |= f U g
F gilt solang bis g gilt
M,3 |= ¬ g
G ist im Zustand 3 falsch
M,2 |= f
Variable f ist im Zustand 4 wahr
M,0|=○(f Λ g) Im Zustand 0 sind f und g gültig
0
1
2
3
f
f
f
f
f
f
f
g
f
f
f, g
Modellprüfung - CTL




CTL: computation tree logic
Aussagen über Zustandsbäume
Boolsche Verknüpfungen werden
um temporale Operatoren erweitert.
Die Operatoren werden mit einem Existenz- (E) bzw. Allquantor
(A) verknüpft
 ○ E , ○ A – Temporale Schrittoperatoren (next)
 ◊ E , ◊ A – Temporale Existenzquantoren (eventually)
 □ E , □ A – Temporale Allquantoren(always)
 E U, A U – Bedingte Allquantifizierungen (until)
Modellprüfung – Beispiele CTL







M, 0 |= f ∧ g: Im Zustand 0 sind f und g gültig.
M, 0 |= ￢f : f ist im Zustand 0 falsch.
M, 3 |= f → g: Ist f im Zustand 3 gültig, dann gilt
dort auch g.
M, 5 |= E ○ f: Im nächsten Zustand eines Pfades ab
5 gilt f.
M, 2 |= A ◊ f: Auf allen Pfaden ab 2 gilt
irgendwann f.
M, 1 |= E □ f: Auf einem Pfad ab 1 gilt stets f.
M, 3 |= f E U g: Auf einem Pfad ab 3 gilt f so lange
bis g gilt.
Modellprüfung

Einsatzgebiet funktionale Systemeigenschaften:
 Gefahrlosigkeitseigenschaften
 es tritt niemals ein
Absturz ein
 Sicherheitseigenschaften  Transaktionssicherheit
 Lebendigkeitseigeneschaften  es wird das
gewünschte Ergebnis irgendwann geliefert

Geringe Ausdrucksstärke ermöglicht
Automatisierung. Dadurch in sicherheitskritischen
Nischenprojekten Anwendung.
Abstrakte Interpretation



Generalisierung des Datenbereichs
Dadurch dynamische Eigenschaften nachweisbar
ohne konkrete Wertebelegung der
Eingangsvariablen
Jeder Programmbefehl wird als Gleichung
aufgefasst und ein Zustand ist die konkrete
Belegung aller vorhandenen Variablen

Jeder Programmzustand ist Element eines ndimensionalen Vektorraumes
Abstrakte Interpretation

Fixpunkt: Punkt im Definitionsbereich, der von der
Funktion auf sich selbst abbildet
 F(x)

= 5x  x=0
Fixpunktiteration:
Menge  Ergebnis A
 A  Ergebnis B
 B  Ergebnis B also Fixpunkt
 leere


Abgleich mit Fehlermenge. Wenn Schnittpunkt leer,
dann Fehlerfreiheit garantiert
Mathematisch gesehen unberechenbar
Abstrakte Interpretation

Zustandsmengen werden nicht exakt bestimmt,
sondern angenähert
 Bedarf
an Speicher und Rechenkapazität wird
verringert
 Ganze Zahlen ersetzen Fließkommazahlen
 Jedes Element des abstrahierten Bereichs repräsentiert
mehrere Elemente des Originalbereichs
 Falschheit kann bewiesen werden, Korrektheit nicht

Volle Automatisierung möglich
Anforderungen an Beweis-Tools

Funktionale Anforderung
 Verifikation

von Code
Nicht-funktionale Anforderungen
 Einfache
Installation
 Intuitive Oberfläche
 Gute Performance
 Korrektheit / Korrektes Verhalten
Anforderungen an Beweis-Tools:
Korrektes Verhalten






Einfache Anweisungen
Boolean-Werte
Schleifen
Exception-Handling
Überladene Methoden
Syntax
Beweis-Tools

KeY
 Ein
gemeinschaftliches Projekt der Universitäten
Karlsruhe, Chalmers, Gothenburg und Darmstadt

Krakatoa
 Ergebnis
eines Projekt-Teams des Inria
Forschungszentrums in Frankreich

ESC/Java2
 KindSoftware
Forschungsgruppe
Auswahl eines Beweis-Tools
KeY
Krakatoa
ESC/Java2
Installation
++
--
++
Intuitive Oberfläche
-
?
++
Performance
++
?
+
Ergebnis
3
-2
5
ESC/Java2

Extended Static Checking
 Static
Checking: Überprüfung anhand des Quellcodes
 Extended: Finden von mehr Fehlern als bei
herkömmlichen statischen Checks



Vorgänger entwickelt am System Research Center
von DEC
Integration von Java 1.4 Features
Annotationssprache: JML
Java Modeling Language



Behavioral Interface Specification Language (BISL)
Design by Contract
Spezielle Java-Annotation
 Einzeilig:
//*
 Mehrzeilig: Zwischen /*@ und @*/
 Weitere Zeilen beginnen mit einem @
 Mit Standard-Tools kompilierbar und auswertbar
durch JML-Tools
Schlüsselwörter der JML






Vorbedingung {P}: \requires
Nachbedingung {Q}: \ensures
Exceptions: \signals_only
Rückgabewert: \result
Initialwert: \old(E)
Quantoren: \forall, \exists, \no_of, \sum, \product
Funktionsweise von ESC/Java2
Verifikation mit ESC/Java2 (1)



Erstellen eines Java-Projektes
Wechseln in die „Verification“-Ansicht
Java-Projekt einen ESC/Java Builder hinzufügen
Verifikation mit ESC/Java2 (2)



Schreiben des Codes
Annotieren mittels JML
Speichern  Builder ausführen
Schwächen von ESC/Java2

Ist nicht „Complete“
 Vollständig
 Es
können Warnungen ausgegeben werden, wenn in der
gegeben Zeit kein Beweis gefunden wurde

Ist nicht „Sound“
 Logisch
korrekt
 Schleifen werden nicht bis zum Ende durchlaufen
Fazit



Einfache Überprüfung von Code mittels formaler
Methoden (Prädikatenlogik)
Schnelle Unterstützung des Softwareentwicklungsprozesses
Wünschenswert: Completeness und Soundness
Vielen Dank für Ihre Aufmerksamkeit!