More on Verification and Model Checking · 2015. 10. 7. · Software model checking Bounded model...
Transcript of More on Verification and Model Checking · 2015. 10. 7. · Software model checking Bounded model...
1/60
More onVerification and Model Checking
Wednesday Oct 07, 2015
Philipp RümmerUppsala University
2/60
Course fair!
3/60
Exam
● October 21st, 8:00 – 13:00● If you want to participate, register
now!
● (You also need to bringID card/passport to the exam)
4/60
Outline
● Timed automata vs. software
● Four general model checking approaches
● Explicit-state● Symbolic● Bounded● Abstraction-based
6/60
Verification also here?
7/60
Software model checking
● Bounded model checking (BMC)● Geared towards bug finding● Tools like: CBMC, LLBMC, …
● Full model checking● Primarily used to show absence of bugs● Tools like: Spin, Blast, CPAChecker,
SatAbs, Eldarica, SeaHorn, …● Similar techniques as in Uppaal
● Annual competition: SV-COMP
8/60
Some examples
9/60
Definition of properties
● assert● Check whether condition holds;
otherwise, stop program execution with an error
● Comparable to a post-condition
● assume● Checks whether condition holds;
otherwise, suspend further program execution
● Comparable to a pre-condition
10/60
Web interfaces
● CBMChttp://logicrunch.it.uu.se:4096/~wv/cbmc/
● Eldaricahttp://logicrunch.it.uu.se:4096/~wv/eldarica/
11/60
Analysis ofTimed Automata vs. Code
● Representing one using the other?
12/60
Control-flow graphs (CFGs)int mult(int a, int b){ int z = 0; while ( a != 0) { if ( a % 2 != 0) { z = z+b; } a = a /2; b = b *2; } return z;}
Graphical representation of code:
● Nodes are control-flow locations + statements
● Edges denote transitions + guards
13/60
As automaton
● Represent every node as an automaton state
● Statements are turned into updates
14/60
Automata as code?
void main() { int i = 0;
wait : goto increase;
increase : if (i < 5) { i = i + 1; goto wait; } else { goto done; }
done : ;}
15/60
Additional aspects● Communication/synchronisation● Atomicity
● Guards + updates are atomic
● Time● Non-determinism
● Sometimes, multipletransitions might be possible
● Guards/partiality● For analysis, considered
as assume
Ingeneral,notexecutable
16/60
Additional features of software
● Structure● Functions, classes, modules
● Datatypes/structures● Pointers, heap, arrays
● Large state space● (But normally no time)
17/60
Global view:Transition systems (TS)
● Tuple● State space● Initial states● State transitions
● Notion capturing various types of systems
● Related concept: Kripke structures
18/60
Example
19/60
Finite automaton as TS
● Simply leave out labels to obtain TS
20/60
Automaton with time/data
21/60
Software program as TS
22/60
Safety of transition system
● Identify set of error states● System is safe if there is no
pathwith and
● Safety = (un)reachability in graph
“Is any error state reachable from an initial state?”
23/60
Example
24/60
The “state space explosion” problem
● The size of set grows very rapidly● Exponentially in number of variables● Exponentially in number of
threads/processes
● Sometimes, is even considered infinite (e.g., time is unbounded)
● Checking reachability can be challenging (or undecidable)
25/60
Method 1:Explicit-state model checking
● Explicitly construct graph● Check reachability of error states
● Example tool: Spin, Java Path Finder
● Problem: complexity linear in size of TS, only works for very small TS (millions/billions of states)
26/60
Side note: CTL properties
● Reachability covers the casesA[], E<>
● How can we check A<>, E[]?(for finite TS)
● For E[] p:● Search for cycles on which p holds in
every state● Determine states from which such cycle
are reachable, only following p states
27/60
Method 2:Symbolic model checking
● Represent graphsymbolically; normally usingBinary Decision Diagrams (BDDs)
● Check reachability of error states by fixed-point computation
● Example tool: SMV
28/60
Binary Decision Diagrams
● Data structure to represent Boolean functions
● Often concise in memory● Canonical representation● Boolean operations on BDDs (&&, ||,
etc) can be executed efficiently(usually in polynomial time)
29/60
Binary Decision Diagrams (2)
30/60
Binary Decision Diagrams (3)
● Sets can be represented by their characteristic function
● If elements of are encoded as sequences of , then is a Boolean function, can be represented as BDD
31/60
Binary Decision Diagrams (4)
● For transition systems● Represent using vector of Boolean
variables● can then be represented using
BDDs
● Safety + CTL properties can be checked by fixed-point computation
32/60
Method 2:Symbolic model checking
● Big success in the 90s:Suddenly able to analyse real hardware implementations (processors, memory, etc.)
● J.R. Burch, E.M. Clarke, K.L. McMillan. D.L. Dill, L.J. Hwang:Symbolic model checking: 10^20 states and beyond.
33/60
Method 2:Symbolic model checking
● 10^20 states is still way too few …● E.g., software program with ten 32bit
integer variables has states
34/60
Method 3:Bounded model checking
● Idea: search for bugs in programs/systems up to some depth; but otherwise reason fully precisely
● Tailored to showing reachability, not so much unreachability
● Today, one of the most successful techniques for hardware analysis
BMC ProblemDecide whether an error can be reached within the firstk execution steps of a program/system.
35/60
36/60
Monolithic BMC
● Transition system● Finite state space● Initial states● Transition relation
→ E.g., repres. by vectors of Booleans
● Errors
37/60
Monolithic BMC (2)
● If the formula can be solved, then represent a path visiting an error state
● Various solvers can be applied:● Linear/mixed integer programming● SAT/SMT solving● Convex optimisation
38/60
Monolithic BMC (3)
● Mainly works well for hardware● For software, formula contains a lot of
redundancy● Better to unwind program guided by
control structure
● Example tool: CBMC
39/60
BMC: straight-line programs
int x, y;
x = x * x;y = x + 1;
assert(y > 0);
(set-option :pp.bv-literals false)
(declare-const x0 (_ BitVec 32))(declare-const y0 (_ BitVec 32))
(declare-const x1 (_ BitVec 32))(declare-const y1 (_ BitVec 32))
(assert (= x1 (bvmul x0 x0)))(assert (= y1 (bvadd x1 (_ bv1 32))))
(assert (not (bvsgt y1 (_ bv0 32))))
(check-sat)(get-model)
Signed comparison
E.g., check using theconstraint solver Z3:
40/60
BMC: conditional branching
int x, y;
if (x > 0) y = x;else y = -x;
assert(y >= 0);
(set-option :pp.bv-literals false)
(declare-const x0 (_ BitVec 32))(declare-const y0 (_ BitVec 32))(declare-const y1a (_ BitVec 32))(declare-const y1b (_ BitVec 32))(declare-const y2 (_ BitVec 32))(declare-const b Bool)
(assert (= b (bvsgt x0 (_ bv0 32))))(assert (=> b (= y1a x0)))(assert (=> (not b) (= y1b (bvneg x0))))(assert (= y2 (ite b y1a y1b)))
(assert (not (bvsge y2 (_ bv0 32))))
(check-sat)(get-model)
41/60
Further features
● Data-structures, heap, pointers● Can be represented using scalar
variables, since only finitely many variables/heap locations can be used in k execution steps
● Concurrency● Systematically explore all possible
interleavings of threads
● Also applicable to timed automata, and other kinds of systems
42/60
Method 4:Abstraction-based MC
● Idea: instead of analysing full model/code, compute and analyse a small abstraction of it
● Refine if the abstraction is too coarse● In particular successful for software
● Example tools: CPAChecker, SatAbs, SLAM, Eldarica, SeaHorn
43/60
Example
→ Abstraction has introduced a spurious counterexample
44/60
Example
→ In this abstraction no error states are reachable!
45/60
Existential abstraction
A transition systemis an existential abstraction ofwith respect to if
1.2.
( is a homomorphism)
46/60
Safety through abstraction
If is an existential abstraction of with respect to and in none of the statesis reachable, then is safew.r.t.
(The same does not hold for all CTL properties; but other forms of abstraction exist ...)
47/60
Abstraction refinement
48/60
Predicate abstraction● In software, abstraction is usually
defined through a set of predicates
49/60
“CEGAR”Counterexample-guided abstraction refinement
50/60
CEGAR (2)
● In each refinement step, one (or multiple) abstract states are split
● The procedure never gives a wrong answer; but might not terminate for infinite-state systems
● Termination guaranteed for finite-state systems
51/60
Abstraction-based MC
● In many cases, abstraction-based model checking can also analyse infinite-state systems
● Programs with unbounded heap● Infinite datatypes (e.g., true integers)● Unbounded/infinite number of threads
52/60
What is Uppaal using?
● For automata locations, data variables:Explicit-state model checking
● For time and clocks:Abstraction-based model checking(“regions” and “zones”)
53/60
Case study: Fischer protocol
● Simple mutual exclusion protocol; only needs one shared variable lock
● Assumptions:● Time bound A known after which writes
to shared variable are visible to all threads
● Every process has an id (> 0), and a timer
● Popular model checking benchmark
54/60
Fischer protocol as code
loop wait until lock = 0; set lock to process id; // visible after <=A units wait for a delay >= B > A; if lock = process id enter critical sectionend
Every thread executes the following code:
55/60
Case study: Fischer protocol (2)
Safety property: no two processescan be in cs at the same time
56/60
Verifiable with any number of processes?
57/60
Fischer as parameterised system
● Infinite family of transition systems● One instance per number of threads
● Some model checkers can verify correctness for all instances at once
● E.g., Eldarica● Idea: analyse system assuming
infinitely many threads using abstraction; this subsumes all cases with finitely many threads
58/60
In C/Eldarica syntax
int lock = 0;
thread[tid] Proc { clock C; assume(tid > 0);
while (1) { atomic { assume(lock == 0); C = 0; } within (C <= 1) lock = tid; // within = time inv.
C = 0; // delay >1 time unit assume(C > 1); if (lock == tid) { // critical section assert(lock == tid); lock = 0; } }}
59/60
Conclusions
● Four model checking approaches● Explicit-state● Symbolic● Bounded● Abstraction-based
60/60
Further reading
● Orna Grumberg: Model Checking: From BDDs to Interpolationwww.cs.technion.ac.il/users/orna/markt-2011.pdf
● Daniel Kroening: Predicate Abstraction, A Tutorialfm.csl.sri.com/SSFT12/predabs-SSFT12.pdf