Presentation is loading. Please wait.

Presentation is loading. Please wait.

Algorithmic Software Verification Rajeev Alur University of Pennsylvania ARO Review, May 2005.

Similar presentations


Presentation on theme: "Algorithmic Software Verification Rajeev Alur University of Pennsylvania ARO Review, May 2005."— Presentation transcript:

1 Algorithmic Software Verification Rajeev Alur University of Pennsylvania ARO Review, May 2005

2 Software Model Checking Code Abstractor Model Verifier Specification Yes Counter-example Predicate abstraction Finite-state Boolean vars On-the-fly explicit state Or Symbolic fixpoint evaluation LTL/CTL/Automata Regular! Observables

3 Abstracting Modular Programs main() { bool y; … x = P(y); … z = P(x); … } bool P(u: bool) { … return Q(u); } bool Q(w: bool) { if … else return P(~w) } A2 A1 A3 A2 A3 A1 Entry/Inputs Exit/outputs Box (function-calls) Program Recursive State Machine (RSM)/ Pushdown automaton

4 Software Model Checking Code Abstractor Model Verifier Specification Yes Counter-example Predicate abstraction Recursive State Machines On-the-fly explicit state (see poster for VERA) LTL/CTL/Automata Regular! Observables

5 LTL Linear-time Temporal Logic (LTL) Q ::- p | not Q | Q or Q’ | Next Q | Always Q | Eventually Q | Q Until Q’ Interpreted over (infinite) sequences. Models of any LTL formula is a regular language. Useful for stating sequencing properties:  If req happens, then req holds until it is granted: Always ( req → (req Until grant) )  An exception is never raised: Always ( not Exception )

6 LTL is not expressive enough LTL cannot express:  Classical Hoare-style pre/post conditions  If p holds when procedure A is invoked, q holds upon return  Total correctness: every invocation of A terminates  Integral part of emerging standard JML  Stack inspection properties For security/access control  If a setuuid bit is being set, process root must be in the call stack Above requires matching of calls with returns, or finding unmatched calls --- Context-free properties!

7 Context-free specifications But model-checking context-free properties against context-free models is Undecidable. However, the properties described are verifiable.  Existing work in security that handles some stack inspection properties [JMT99,JKS03]  Adding assert statements in the program (with additional local variables, if needed), and then checking regular properties (e.g. reachability) amounts to checking context-free properties

8 CARET CARET: A temporal logic for Calls and Returns Expresses context-free properties A B C A Global successor used by LTL ………….

9 CARET CARET: A temporal logic for Calls and Returns Expresses context-free properties A B C D Global successor used by LTL …………. Local successor: Jump from calls to returns Otherwise global successor at the same level

10 CARET CARET: A temporal logic for Calls and Returns Expresses context-free properties A B C A Global successor used by LTL …………. Local successor: Jump from calls to returns Otherwise global successor at the same level

11 CARET CARET: A temporal logic for Calls and Returns Expresses context-free properties A B C A Global successor used by LTL …………. Local successor: Jump from calls to returns Otherwise global successor at the same level Local path

12 CARET CARET: A temporal logic for Calls and Returns Expresses context-free properties A B C A Global successor used by LTL …………. Local successor: Jump from calls to returns Otherwise global successor at the same level Caller modality: Jump to the caller of the current module Defined for every node except top-level nodes

13 CARET CARET: A temporal logic for Calls and Returns Expresses context-free properties A B C A Global successor used by LTL …………. Abstract successor: Jump from calls to returns Otherwise global successor at the same level Caller modality: Jump to the caller of the current module Defined for every node except top-level nodes Caller path gives the stack content!

14 CARET Definition Syntax: Q ::- p | not Q | Q or Q’ | Next Q | Always Q | Eventually Q | Q Until Q’ Local-Next Q | Local-always Q Local-Eventually Q | Q Local-Until Q’ Caller Q | Callerpath-always Q CallerPath-Eventually Q | Q CallerPath-Until Q’  Local- and Caller- versions of all temporal operators  All these operators can be nested

15 Expressing properties in Caret  Pre-post conditions  If P holds when A is called, then Q must hold when the call returns Always ( (P and call-to-A) Local-Next Q ) A P Q Pre-post conditions are integral to specifications for JML (Java Modeling Language)

16 Expressing properties in Caret  If A is called with low priority, then it cannot access the file Always ( call-to-A and low-priority Local-Always ( not access-file ) ) A lowpriority A highpriority access-file

17 Expressing properties in Caret Stack inspection properties If variable x is accessed, then A must be on the call stack Always ( access-to-x CallerPath-Eventually call-to-A ) access-to-x A

18 Model checking CARET  Given: A (boolean) recursive state machine/ pushdown automaton M A CARET formula Q  Model-checking: Do all runs of M satisfy the specification Q? CARET can be model-checked in time that is polynomial in M and exponential in Q. |M| 3. 2 O(|Q|) Complexity same as that for LTL !

19 Model-checking CARET: intuition Main Idea:  The specification matches calls and returns of the program.  Hence the push (pop) operations of the model and the specifications synchronize  Given M and formula Q,  Build a Buchi pushdown automaton that accepts words exhibited by M that satisfy (not Q)  Check this pushdown automaton for emptiness  Specification automaton also pushes onto the stack! s, Q1 s Push s and Q1 Local-Next Q1 Pop s and Q1 ; Check Q1

20 Can we generalize the idea? LTL Regular Languages CARET ? Must be a superset of CARET Must be model-checkable against pushdown models

21 Generalizing the idea  Structured words: Partitioned alphabet: Σ = S push  S pop  S internal  Consider finite words over Σ  A visibly pushdown automaton over Σ is a pushdown automaton that  pushes a symbol onto the stack on a letter in S push  pops the stack on a letter in S pop  cannot change the stack on a letter in S internal Note: Stack size at any time is determined by the input word but not the stack content

22  A language is a VPL over a partitioned alphabet Σ, if there is a visibly pushdown automata that accepts it (acceptance by final state) CARET is contained in VPL Model-checking:  CARET Q  VPL L Q  Pushdown model M  VPL L M  M satisfies Q iff L M  L Q =  (Emptiness of pushdown automata is decidable) Visibly pushdown languages (VPL) VPL is closed under boolean operations: union, intersection and complement

23 VPL  VPLs are also determinizable (Consequence: Runtime monitors for CARET/VPL can be built)  We have also extended this class to languages of infinite words. Regular Lang DCFL CFL VPL

24 Regular CFL DCFL VPL L PSPACE EmptinessInclusion Yes NLOG YesNo Undec PTIME NoYesPTIME Undec Yes PTIME Exptime

25 VPL: Connection to tree languages  Let w = i 5 c 1 i 1 c 2 i 4 i 3 i 3 r 3 c 1 i 1 r 1 r 5 i 5 i 3 i5 c1 r5 i1 c2 i4 i3 i5 i3 r3 Stack trees r1 c1 i1

26 VPL: Connection to tree languages Tree-language characterization: Let L be a set of strings and let ST(L) be the set of stack trees that correspond to L. Then L is a VPL iff ST(L) is a regular tree language

27 VPL is robust Visibly pushdown languages  Regular  stack- trees  Monadic second order logic with a matching predicate  Context-free Grammar Subset (generalizes Knuth’s Parantheses Languages)

28 ω-VPL - extension to infinite words  A Büchi VPA:  VPA over infinite strings  A word is accepted if along a run, the set Q F is seen infinitely often  ω-VPL – class of languages accepted by B ü chi VPAs  ω-VPL is closed under all boolean operations Characterization using regular trees and MSO characterization hold.  However, ω-VPLs are not determinizable!  Let L be the set of all words such that the stack is “repeatedly bounded” i.e.  n. the stack depth is n infinitely often.  L is an ω-VPL but there is no deterministic Muller VPA for it.

29 “Regular-like” properties continue..  Congruences and minimization (Myhill-Nerode Theorem) cornerstone of theory of regular languages  Given a language L, for well-matched words u and v, define u ~ L v iff for all words x and y, xuy in L iff xvy in L  Theorem: A language L of well-matched words is a VPL iff the congruence ~ L is of finite index  Minimization  No unique minimal deterministic VPA in general, but…  Minimization of RSMs (i.e. procedural boolean programs) possible. Partitioning into k procedures/modules is adequate to get canonicity!

30 Conclusions  Exposing calls and returns leads to an interesting subclass of context-free languages  VPLs seem robust and adequate to model software analysis problems  Publications: TACAS’04, STOC’04, TACAS’05, ICALP’05  Coauthors: S. Chaudhuri, K. Etessami, V. Kumar, P. Madhusudan, M. Viswanathan  Active area of current research  DTDs, XML, and query languages  Branching-time logics, Fixpoint calculus, and visibly pushdown tree automata

31 New Foundations for Software Model Checking Code Abstractor Model Verifier Specification Yes Counter-example Predicate abstraction Recursive State machines+ Boolean vars On-the-fly explicit state Or Symbolic fixpoint evaluation Caret/VPAs/VP VPLs Observable Calls/rets


Download ppt "Algorithmic Software Verification Rajeev Alur University of Pennsylvania ARO Review, May 2005."

Similar presentations


Ads by Google