Formal Verification
3 likes2,136 views
Formal verification involves proving the correctness of algorithms or systems with respect to a formal specification using mathematical techniques. It can be done by formally modeling a system and using theorem proving or model checking to verify that the model satisfies given properties. Theorem proving uses logical deduction to prove properties, while model checking automatically checks all possible states of a finite model against temporal logic properties. Both approaches have advantages and limitations, but formal verification can help find bugs and prove correctness of systems.
![Code to Model Example
#include <stdio.h>
#include <stdlib.h>
!
int main(int argc, const char* argv[])
{
FILE* f;
int c, n = 0, w = 0;
!
if (argc < 2)
{
printf("Filename?n");
return 1;
}
!
f = fopen(argv[1], "r");
if (f == NULL)
{
printf("open error:%sn", argv[1]);
return 1;
}
!
!
!
!
!
while ((c = fgetc(f)) != -1)
{
if (!isspace(c))
{
if (!w)
++n, w = 1;
else
w = 0;
}
}
printf("Word count: %dn", n);
!
fclose(f);
return 0;
}](https://image.slidesharecdn.com/fvintro-140623064117-phpapp01/85/Formal-Verification-8-320.jpg)
![Code to Model Example
#include <stdio.h>
#include <stdlib.h>
!
int main(int argc, const char* argv[])
{
FILE* f;
int c, n = 0, w = 0;
!
if (argc < 2)
{
printf("Filename?n");
return 1;
}
!
f = fopen(argv[1], "r");
if (f == NULL)
{
printf("open error:%sn", argv[1]);
return 1;
}
!
!
!
!
!
while ((c = fgetc(f)) != -1)
{
if (!isspace(c))
{
if (!w)
++n, w = 1;
else
w = 0;
}
}
printf("Word count: %dn", n);
!
fclose(f);
return 0;
}](https://image.slidesharecdn.com/fvintro-140623064117-phpapp01/85/Formal-Verification-9-320.jpg)
![Code to Model Example
#include <stdio.h>
#include <stdlib.h>
!
int main(int argc, const char* argv[])
{
FILE* f;
int c, n = 0, w = 0;
!
if (argc < 2)
{
printf("Filename?n");
return 1;
}
!
f = fopen(argv[1], "r");
if (f == NULL)
{
printf("open error:%sn", argv[1]);
return 1;
}
!
!
!
!
!
while ((c = fgetc(f)) != -1)
{
if (!isspace(c))
{
if (!w)
++n, w = 1;
else
w = 0;
}
}
printf("Word count: %dn", n);
!
fclose(f);
return 0;
}](https://image.slidesharecdn.com/fvintro-140623064117-phpapp01/85/Formal-Verification-10-320.jpg)
![Model Checking: Older Approaches
• Construct a model of a system in terms of a
finite state machine
• Choose a property, express it in some sort of
temporal logic and use a tool to explore the
state space and to check if the property holds
• Explicit-state checker enumerates all possible states
[SPIN]
• Symbolic checker uses binary decision diagram (BDD) to
encode the state transition function [NuSMV etc.]](https://image.slidesharecdn.com/fvintro-140623064117-phpapp01/85/Formal-Verification-31-320.jpg)
Formal Verification
- 2. Formal Verification… “…is the act of proving or disproving the correctness of intended algorithms underlying a system in respect to a certain formal specification or property, using formal methods of mathematics” – Wikipedia
- 3. ☺ System S → Model M, where M ∋ [finite state machine, labeled transition system, timed automata, Petri net,…) ! (M ∈ ⊨) ∧ ((S ⩰ M) ∈ ⊨) ⇒ S ∈ ⊨
- 4. Why • find more bugs in design and implementation • prove correctness • cut down testing and maintenance cost • Common Criteria (ISO 15408), FIPS-140-2 Level 4,… • build high-assurance systems
- 5. Formal Verification of Design • Make a formal design by using a specification language etc. • Define and formalize desired properties • Verify that the chosen formal property holds for the formal design ! describe → design → formalise → verify
- 6. Formal Verification of Design • Making formal design is (mostly) not fun • May not be enough details for interesting properties • Far away from actual implementation
- 7. Formal Verification of Program • Use code as formal design document • Easier to combine with debugging and testing • Closer to actual implementation • Can benefit from additional methods like static program analysis etc.
- 8. Code to Model Example #include <stdio.h> #include <stdlib.h> ! int main(int argc, const char* argv[]) { FILE* f; int c, n = 0, w = 0; ! if (argc < 2) { printf("Filename?n"); return 1; } ! f = fopen(argv[1], "r"); if (f == NULL) { printf("open error:%sn", argv[1]); return 1; } ! ! ! ! ! while ((c = fgetc(f)) != -1) { if (!isspace(c)) { if (!w) ++n, w = 1; else w = 0; } } printf("Word count: %dn", n); ! fclose(f); return 0; }
- 9. Code to Model Example #include <stdio.h> #include <stdlib.h> ! int main(int argc, const char* argv[]) { FILE* f; int c, n = 0, w = 0; ! if (argc < 2) { printf("Filename?n"); return 1; } ! f = fopen(argv[1], "r"); if (f == NULL) { printf("open error:%sn", argv[1]); return 1; } ! ! ! ! ! while ((c = fgetc(f)) != -1) { if (!isspace(c)) { if (!w) ++n, w = 1; else w = 0; } } printf("Word count: %dn", n); ! fclose(f); return 0; }
- 10. Code to Model Example #include <stdio.h> #include <stdlib.h> ! int main(int argc, const char* argv[]) { FILE* f; int c, n = 0, w = 0; ! if (argc < 2) { printf("Filename?n"); return 1; } ! f = fopen(argv[1], "r"); if (f == NULL) { printf("open error:%sn", argv[1]); return 1; } ! ! ! ! ! while ((c = fgetc(f)) != -1) { if (!isspace(c)) { if (!w) ++n, w = 1; else w = 0; } } printf("Word count: %dn", n); ! fclose(f); return 0; }
- 11. Code to Model Example #include <stdio.h> #include <stdlib.h> ! int main() { FILE* f; int c, n = 0, w = 0; enum {FALSE,TRUE} B1; ! if (B1 = any()) { return 1; } ! f = fopen(“sample”, "r"); if (f == NULL) { return 1; } ! ! ! ! ! while ((c = fgetc(f)) != -1) { if (!isspace(c)) { if (!w) ++n, w = 1; else w = 0; } } fclose(f); return 0; }
- 12. Code to Model Example #include <stdio.h> #include <stdlib.h> ! int main() { FILE* f; int w = 0; enum {FALSE,TRUE} B1, B2, B3; ! if (B1 = any()) { return 1; } ! f = fopen(“sample”, "r"); if (f == NULL) { return 1; } ! ! ! ! ! while (B2 = any()) { if (B3 = any()) { if (!w) w = 1; else w = 0; } } fclose(f); return 0; }
- 13. Code to Model Example int main() { enum {FALSE,TRUE} B1, B2, B3; enum {FCLOSED, FOPEN, FERROR} fileState; enum {V0, V1} W = V0; fileState = FCLOSED; ! if (B1 = any()) { return 1; } if (any()) { fileState = FOPEN; } else { fileState = FERROR; } if (fileState == FERROR) { return 1; } ! ! ! ! ! while (B2 = any()) { if (B3 = any()) { if (!w) W = V1; else W = V0; } } fileState = FCLOSED; return 0; }
- 14. Code to Model Example int main() { enum {FCLOSED, FOPEN, FERROR} fileState; ! fileState = FCLOSED; ! if (any()) { fileState = FERROR; } else if (any()) { fileState = FOPEN; while (any()); fileState = FCLOSED; } return 0; } ! entry FCLOSED1 FERROR FOPEN FCLOSED2 exit
- 15. Formal Verification Techniques • Theorem Proving • Model Checking • Ad hoc voodoo magic ! ! ! ! ! Although these appear to be contradictory approaches, there has been considerable effort to incorporate theorem proving and model checking
- 16. Theorem Proving • Logical deduction at the intersection of mathematics and logics • Prove that implementation satisfies specification by mathematical reasoning • implementation and specification as formulae in a some formal logic • required relationship (equivalence/implication) as a theorem to prove by using a set of axioms and inference rules (simplification, induction, etc.)
- 17. Theorem Proving by hand – classic approach • human errors (similar to programming) • unsuitable for verifying large software and hardware systems
- 18. Theorem Proving with some machine support – machine checks the syntax, fixes layout, translates into different (meta)languages • less errors, readable consistent statements • still unsuitable for verifying large software and hardware systems
- 19. Theorem Proving interactive – proofs are fully checked by machine based on proof steps provided by user • guaranteed correctness (if the prover is correct) • can prove everything that is provable by hand
- 20. Theorem Proving automated – theorem is shown by machine; user must state it in a proper form so that the prover can solve the problem within reasonable amount of time • may be used by non-specialists • may be faster than interactive proving • many problems cannot be proved automatically • can often deal only with finite problems
- 21. Limitations of Theorem Proving • Large manpower investment to prove small theorems, difficult to prove large or hard theorems • Usable only by experts, requires deep understanding of both the system design and proving methodology • Automated for narrow class of system designs
- 22. Model Checking Automated technique that, given a finite-state model of a system and a formal property, systematically checks whether this property holds for (a given state in) that model. ! Modelling → Running → Analysing
- 23. Modelling • Model the system under consideration using the model description language of the model checker at hand • As a first sanity check and quick assessment of the model perform some simulations • Formalise the property to be checked using the property specification language.
- 24. Running • Run the model checker to check the validity of the property in the system model.
- 25. Analysis • Property satisfied? • Check next property (if any) • Property violated? • Analyse generated counterexample by simulation • Refine the model, design, or property • Repeat the entire procedure. • Out of memory? • Try to reduce the model and try again.
- 26. Temporal Logic Model Checking • Specifications are written in propositional temporal logic to specify time related system behaviour properties either in absolute time or in terms of sequences of state transitions • Verification is an exhaustive search of the state space of the design
- 27. Basic Temporal Operators Let p be an atomic proposition, e.g. device_Enabled • Xp – p holds next time • Fp – p holds sometime in a future • Gp – p holds globally in a future (always) • pUq – p holds until another atomic proposition q holds ! Use with ¬∧∨ etc. to form temporal logic formulae
- 28. Temporal Logic Formula Example The microwave oven does not heat up until the door is closed ! Not heat_up holds until door_closed ! (¬heat_up) U door_closed
- 29. Temporal Logic Formula Example The microwave oven does not heat up until the door is closed ! Not heat_up holds until door_closed ! (¬heat_up) U (door_closed ∧ powered_on)
- 30. Temporal Logic Model Checking Goals Safety – something bad will never happen. To satisfy, the system must not demonstrate forbidden behaviour ! Liveness – something good will happen in future. To satisfy, the system must demonstrate desired behaviour
- 31. Model Checking: Older Approaches • Construct a model of a system in terms of a finite state machine • Choose a property, express it in some sort of temporal logic and use a tool to explore the state space and to check if the property holds • Explicit-state checker enumerates all possible states [SPIN] • Symbolic checker uses binary decision diagram (BDD) to encode the state transition function [NuSMV etc.]
- 32. Model Checking: Older Approaches • Good for liveness and safety properties • “is a state with property p reachable?” • “if I see x, will I eventually see y?” • “is property p true for all states?” • Ill-suitable for functional properties • “does this function compute AES-256?”
- 33. Model Checking: Newer Approaches SAT-based model checkers • Bounded model-checking (BMC) – an otherwise large or even infinite-state FSM can be analysed by checking a finite number of state transitions • Property directed reachability (PDR) – combination of induction, over-approximation and SAT solving
- 34. Model Checking: Newer Approaches Going into details of SAT and SMT solvers is probably too much to handle for this session. ! X(explain_sat ∧ explain_smt)
- 35. Model Checking Strengths • General verification approach that is applicable to a wide range of systems • Supports partial verification (properties can be checked individually, essential ones first) • Provides diagnostic information in case a property is invalidated (useful for debugging)
- 36. Model Checking Strengths (cont.) • Requires neither a high degree of user interaction nor a high degree of expertise • Can be easily integrated in existing development cycles • Sound mathematical underpinning, based on theory of graph algorithms, data structures, logic etc.
- 37. Model Checking Weaknesses • Mainly for control-intensive systems, less suitable for data-intensive ones • Verifies a model and not the actual system itself; complimentary techniques are needed (testing etc.) • Check only stated requirements, completeness is not guaranteed
- 38. Model Checking Weaknesses (cont.) • Suffers from the state-space explosion problem • Requires some expertise in finding appropriate abstractions to obtain smaller system models and to state properties in the logical formalism used • Does not allow checking generalisations • A model checker may contain software defects
- 39. Model Checking Provided various approaches, it is an effective technique to expose design errors
- 40. Formally Verified System Design Model Implementation theorem proving model checking logic/syntax checkers testing
- 41. Thank you This presentation is based on materials provided courtesy of and various publicly available Internet sources. All grammar and syntax errors are, let’s say, for watermarking purposes 2013