272: Software Engineering Fall 2012

272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 1: Software Verification with Spin and Bandera

State of the art in verification: Model Checking • What is model checking? • Automated verification technique • Focuses on bug finding rather than proving correctness • The basic idea is to exhaustively search for bugs in software • Has many flavors • Explicit-state model checking • Symbolic model checking • Bounded model checking • …

Model Checking and Temporal Logics • Model checking tools assume that the properties that one wants to check about a system are expressed using temporal logics • Temporal logics are a type of modal logics • Modal logics were developed to express modalities such as “necessity” or “possibility” • Temporal logics focus on the modality of temporal progression • Temporal logics can be used to express, for example, that: • an assertion is an invariant (i.e., it is true all the time) • an assertion eventually becomes true (i.e., it will become true sometime in the future)

Temporal Logics • We will assume that there is a set of basic atomicpropertiescalled • These are used to write the basic (non-temporal) assertions about the program • Examples: a=true, pc0=c, x=y+1 • We will use the usual boolean connectives:  ,  ,  • We will also use four temporal operators: Invariantp : G p (aka p or [] p) (Globally) Eventuallyp : F p (aka p or <> p) (Future) Next p : X p (aka p) (neXt) pUntilq : pU q(Until)

LTL Properties . . . X p p . . . G p p p p p p p . . . F p p . . . p U q p p p p q

Example Properties Examples: mutual exclusion: Two processes are not in the critical section (cs) at the same time: G (  (pc1=cs pc2=cs)) starvation freedom: If a process starts waiting (wait) it will eventually get in the critical section: G(pc1=wait  F(pc1=cs))  G(pc2=wait  F(pc2=cs))

Linear Time vs. Branching Time • In linear time logics we look at the execution paths individually • In branching time logics we view the computation as a tree • computation tree: unroll the transition relation Transition System Execution Paths Computation Tree s3 s3 s3 s1 s2 s3 s4 s1 s4 s4 s1 s2 s3 s3 s2 . . . s3 s4 s1 s3 . . . . . . . . . s4 s1 . . . . . .

Computation Tree Logic (CTL) • In CTL we quantify over the paths in the computation tree • We use the same four temporal operators: X, G, F, U • However we attach path quantifiers to these temporal operators: • A : for all paths • E : there exists a path • We end up with eight temporal operators: • AX, EX, AG, EG, AF, EF, AU, EU • Expressive power of CTL and LTL are not comparable • There are properties that can be expressed in LTL but cannot be expressed in CTL, and visa versa • There are temporal logics which are more powerful than both CTL and LTL (CTL*, mu-calculus)

Model Checking Model checking problem: Given a transition system (a sate machine) and a temporal logic property, determine if all the paths (or all the computation trees) starting from the initial states satisfy the property. • A model checker is a tool that can automatically answer this question • If the property fails, then the model checker generates a counter-example behavior: An execution path that demonstrates the violation of the property If the input system has a finite number of states then model checking can be done fully automatically • Its complexity is linear in the size of the input transition system but could be exponential in the size of the formula

Model Checking Tools • Two model checking tools that had significant impact • Spin model checker: An explicit state model checker that focuses on verification of concurrent protocols • SMV model checker: A BDD-based symbolic model checker that focuses on hardware specifications • Spin and SMV have their own input specification languages • To check a specification using them, you need to write your system in their input specification language • This requires translation of the system to be verified to the input language of the model checker • Most of the time these translations are not automated and use ad-hoc simplifications and abstractions

Automata-based LTL Model Checking • Büchi automata: Finite state automata that accept infinite strings • The better known variant of finite state automata accept finite strings (used in lexical analysis for example) • A Büchi automaton accepts a string when the corresponding run visits an accepting state infinitely often • Note that an infinite run never ends, so we cannot say that an accepting run ends at an accepting state • LTL properties can be translated to Büchi automata • The automaton accepts a path if and only if the path satisfies the corresponding LTL property

LTL Properties  Büchi automata The size of the property automaton can be exponential in the size of the LTL formula (recall the complexity of LTL model checking) true p G p p true p F p p p p p G (F p) p

Büchi Automata: Language Emptiness Check • Given a Buchi automaton, one interesting question is: • Is the language accepted by the automaton empty? • i.e., does it accept any string? • A Büchi automaton accepts a string when the corresponding run visits an accepting state infinitely often • To check emptiness: • Look for a cycle which contains an accepting state and is reachable from the initial state • Find a strongly connected component that contains an accepting state, and is reachable from the initial state • If no such cycle can be found the language accepted by the automaton is empty

LTL Model Checking • Generate the property automaton from the negated LTL property • Generate the product of the property automaton and the transition system • Show that there is no accepting cycle in the product automaton (check language emptiness) • i.e., show that the intersection of the paths generated by the transition system and the paths accepted by the (negated) property automaton is empty • If there is a cycle, it corresponds to a counterexample behavior that demonstrates the bug

LTL Model Checking Example Property to be verified Example transition system G q Negation of the property 1 p,q  G q  F q Property automaton for the negated property 2 3 q p true q q Each state is labeled with the propositions that hold in that state

Transition System to BuchiAutomaton Example transition system Corresponding Buchi automaton i 1 p,q p∧q p∧q 1 q 2 3 q p q 2 3 Each state is labeled with the propositions that hold in that state p

Buchi automaton for the transition system (every state is accepting) Product automaton 1,1 i p∧q p∧q p∧q 2,1 p∧q 1 q q 3,1 q 2 3 p q p 3,2 4,2 p Property Automaton Accepting cycle: (1,1), (2,1), (3,1), ((4,2), (3,2)) Corresponds to a counter-example path for the property G q true q q

Automata Theoretic LTL Model Checking Input: A transition system T and an LTL property f • Translate the transition system T to a Buchi automaton AT • Negate the LTL property and translate the negated property f to a Buchi automaton Af • Check if the intersection of the languages accepted by AT and Af is empty • Is L(AT)  L(Af) =  ? • If L(AT)  L(Af) , then the transition system T violates the property f

Automata Theoretic LTL Model Checking • Note that • L(AT)  L(Af) =  if and only if L(AT)  L(Af) • By negating the property f we are converting language subsumption check to language intersection followed by language emptiness check • Given the Buchi automata AT and Af we will construct a product automaton AT Af such that • L(AT Af) = L(AT)  L(Af) • So all we have to do is to check if the language accepted by the Buchi automaton AT Af is empty

SPIN • A model checking tool • Checks finite state systems • Properties are specified using temporal logic LTL • Input language: PROMELA • Asynchronous processes • Shared variables • Message passing through (bounded) communication channels • Variables: boolean, char, integer (bounded), arrays (fixed size) • Structured data types

SPIN Verification in SPIN • Uses automata-theoretic LTL model checking approach • Constructs the product automaton on-the-fly • It is possible to find an accepting cycle (i.e. a counter-example) without constructing the whole state space • Uses a nested depth-first search algorithm to look for an accepting cycle • Uses various heuristics to improve the efficiency of the nested depth first search: • partial order reduction • state compression

Example Mutual Exclusion Protocol in Promela Two concurrently executing processes are trying to enter a critical section without violating mutual exclusion #define cs1 process1@cs #define cs2 process2@cs #define wait1 process1@wait #define wait2 process2@wait #define true 1 #define false 0 bool a; bool b; bool turn; proctype process1() { out: a = true; turn = true; wait: (b == false || turn == false); cs: a = false; goto out; } proctype process2() { out: b = true; turn = false; wait: (a == false || turn == true); cs: b = false; goto out; } init { run process1(); run process2() }

Property automaton generation % spin -f "! [] (! (cs1 && cs2))“ never { /* ! [] (! (cs1 && cs2)) */ T0_init: if :: ((cs1) && (cs2)) -> goto accept_all :: (1) -> goto T0_init fi; accept_all: skip } % spin -f "!([](wait1 -> <>(cs1)))“ never { /* !([](wait1 -> <>(cs1))) */ T0_init: if :: ( !((cs1)) && (wait1) ) -> goto accept_S4 :: (1) -> goto T0_init fi; accept_S4: if :: (! ((cs1))) -> goto accept_S4 fi; } Concatanate the generated never claims to the end of the specification file • Input formula • “[]” means G • “<>” means F • “spin –f” option • generates a Buchi automaton for the input LTL formula

SPIN • “spin –a mutex.spin” generates a C program “pan.c” from the specification file • This C program implements the on-the-fly nested-depth first search algorithm • You compile “pan.c” and run it to the model checking • Spin generates a counter-example trace if it finds out that a property is violated

%mutex -a warning: for p.o. reduction to be valid the never claim must be stutter-invariant (never claims generated from LTL formulae are stutter-invariant) (Spin Version 4.2.6 -- 27 October 2005) + Partial Order Reduction Full statespace search for: never claim + assertion violations + (if within scope of claim) acceptance cycles + (fairness disabled) invalid end states - (disabled by never claim) State-vector 28 byte, depth reached 33, errors: 0 22 states, stored 15 states, matched 37 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) 2.622 memory usage (Mbyte) unreached in proctype process1 line 18, state 6, "-end-" (1 of 6 states) unreached in proctype process2 line 27, state 6, "-end-" (1 of 6 states) unreached in proctype :init: (0 of 3 states)

Bandera • A tool set for model checking Java source code • Automated compact finite state model extraction from Java source code • Uses existing model checkers, translates into an existing model checker's input language • Promela (input language of the Spin model checker), SMV, etc. • The properties to be verified are specified in Bandera Specification Language (BSL) • Supports both pre and post conditions and also temporal properties

Design criteria for Bandera • Reuse of existing verification technologies • Automated support for abstractions used by experienced model developers • Specialized models for specific properties • An open design for extensibility • Synergistic integration with existing testing and debugging techniques

Strategy for model checking software • Irrelevant component elimination: Many parts of the code can be irrelevant for the property that we want to check • Data abstraction: State space of the program can be reduced using data abstraction • Component restriction: Using a bounded search that searches only a part of the full state space can still reveal bugs since many bugs reveal themselves even in small versions of a system

Bandera • It uses various techniques to reduce the size of the state space of the program • Slicing to automatically eliminate irrelevant components • Abstraction engine for reduction of the domains of the variables • Uses an intermediate language: Bandera Intermediate Language (BIR) • Maps the error trace generated by the model checkers to the source code • Abstraction library • Users can define their own abstractions for data domains or use one of the existing abstractions from the abstraction library • Users can write abstraction in Bandera Abstraction Specification Language (BASL)

Component based tool architecture • Slicer: Slicing component compresses paths in the program by removing control points variables and data structures that are irrelevant for checking a given property • Abstraction Engine: Allows user to reduce the cardinality of data sets associated with data variables. Includes a language for specifying abstractions which can be collected in an abstraction library for reuse. • Back End: Generates BIR: a low-level intermediate language based on guarded commands that abstracts common model checker input languages. The back end also contains a translator each model checker supported. • User Interface: An advanced graphical user interface that facilitates interaction with various components and displays counter-examples to the user like on the source code like a debugger.

272: Software Engineering Fall 2012