Carnegie Mellon University

1. Formal Verification of Infinite-State Systems Using Boolean Methods Randal E. Bryant Carnegie Mellon University http://www.cs.cmu.edu/~bryant

2. Main Ideas • Infinite State Systems • Greater power & generality than finite-state models • Verified by extensions of finite-state model checking • Must find balance between expressiveness of model & ability to automate • Outline • Why infinite state systems? • UCLID modeling capabilities • Verification methods • Implementation • Advances in SAT and decision procedures • Prospects and challenges

3. Verification Example • Task • Verify that microprocessor correctly implements instruction set definition • Even though heavily pipelined Alpha 21264 Microprocessor Microprocessor Report, Oct. 28, 1996

4. Verification Challenges • Sources of Complexity • Lots of internal state • Complex control logic • Opportunities • Most of the logic serves to store, select, and communicate data Alpha 21264 Microprocessor Microprocessor Report, Oct. 28, 1996

5. Sources of Infinity • Real-life computers are finite state • Infinite-State Abstractions • Traditional model for reasoning about programs • Soundness depends on properties being verified • Computer words • Memory capacities In Use • • • • • • • • • tail head

6. • • • P1 P2 PN Max-1 head 0 Sources of Infinity (cont.) • Finite, but unbounded • Synchronization protocol that should work for arbitrary number of processes • Verify for arbitrary N • Circular buffer with fixed, but arbitrary capacity • Verify for arbitrary value of Max In Use • • • • • • • • • tail

7. Existing Automatic Verification Methods • Simulators, model checkers, … • All Operate at Bit Level • State model • State encoded as words and arrays of words • Comprised of bits • Must track how each bit of state gets updated • Only Verify Single Instance of Design • Fixed values for parameters • Word size • Buffer sizes • Number of processes • Some Work in Parameterized System Verification • Exploit symmetries in system • Limited applicability

8. What About Theorem Provers? • Traditional Tool for Formal Verification • Allow many forms of abstraction • Hard to Use • Lots of manual effort & expertise required • Question: • Can we incorporate some of these abstraction abilities into an automated tool?

9. UCLID • Seshia, Lahiri, Bryant, CAV ‘02 • Term-Level Verification System • Language for describing systems • Inspired by CMU SMV • Symbolic simulator • Generates integer expressions describing system state after sequence of steps • Decision procedure • Determines validity of formulas • Support for multiple verification techniques • Available by Download http://www.cs.cmu.edu/~uclid

10.  x Data Abstraction #1: Bits → Integers x0 • View Data as Symbolic Words • Arbitrary integers • No assumptions about size or encoding • Classic model for reasoning about software • Can store in memories & registers x1 x2 xn-1

11. Data Path Data Path Com. Log. 1 Com. Log. 1 ? Com.Log. 2 Com. Log. 1 ? What do we do about logic functions? Abstracting Data Bits Control Logic

12. ALU Abstraction #2: Uninterpreted Functions • For any Block that Transforms or Evaluates Data: • Replace with generic, unspecified function • Only assumed property is functional consistency: a = x b = y f(a, b) = f(x, y) f

13. F1 F2 Abstracting Functions Control Logic • For Any Block that Transforms Data: • Replace by uninterpreted function • Ignore detailed functionality • Conservative approximation of actual system Data Path Com. Log. 1 Com. Log. 1

14. M a M m0 a Abstraction #3: Modeling Memories as Mutable Functions • Memory M Modeled as Function • M(a): Value at location a • Initially • Arbitrary state • Modeled by uninterpreted function m0

15. Writing Transforms Memory M = Write(M, wa, wd) Reading from updated memory: Address wa will get wd Otherwise get what’s already in M Express with Lambda Notation M = a . ITE(a = wa, wd, M(a)) M wa = wd a M 1 0 Effect of Memory Write Operation

16. Theory of Arrays Read operation Read(M, a) Write operation Write(M, wa, wd) Memory comparison predicate M1 = M2 Mutable Functions Function application M(a) Lambda definition  a . ITE(a = wa, wd, M(a)) Content comparison a . M1(a) = M2(a) Only feasible for positive equality Not limited to one dimension Lambda definition allows other forms of updating Comparison to Array Modeling

17. An Out-of-order Processor (OOO) valid tag val D E C O D E incr dispatch • Data Dependencies Resolved by Register Renaming • Map register ID to instruction in reorder buffer that will generate register value • Inorder Retirement Managed by Retirement Buffer • FIFO buffer keeping pending instructions in program order Program memory valid value src1valid src1val src1tag src2valid src2val src2tag dest op result PC Register Rename Unit 1st Operand result bus retire 2nd Operand ALU execute Reorder Buffer head tail Reorder Buffer Fields

18. FIFO Insert when dispatch Remove when retire Content Addressable Broadcast result to all entries with matching source tag Retire Dispatch result bus ALU execute head tail • Directly Addressable • Select particular entry for execution • Retrieve result value from executed instruction Access Modes for Reorder Buffer • Global • Flush all queue entries when instruction at head causes exception

19. Underlying Logic • Scalar Data Types • Formulas (F ) Boolean Expressions • Control signals • Terms (T ) Integer Expressions • Data values • Functional Data Types • Functions (Fun) Integer  Integer • Immutable: Functional units • Mutable: Memories • Predicates (P) Integer  Boolean • Immutable: Data-dependent control • Mutable: Bit-level memories

20. To support pointer operations CLU Logic • Counter Arithmetic, Lambda Expressions and Uinterpreted Functions • Terms (T ) Integer Expressions ITE(F, T1, T2) If-then-else Fun (T1, …, Tk) Function application succ (T) Increment pred (T) Decrement • Formulas (F ) Boolean Expressions F, F1F2, F1F2 Boolean connectives T1 = T2 Equation T1 < T2 Inequality P(T1, …, Tk) Predicate application

21. CLU Logic (Cont.) • Functions (Fun) Integer  Integer f Uninterpreted function symbol  x1, …, xk . T Function definition • Predicates (P) Integer  Boolean p Uninterpreted predicate symbol  x1, …, xk . F Predicate definition

22. UCLID Decision Procedure Operation CLU Formula • Series of transformations leading to propositional formula • Except for lambda expansion, each has polynomial complexity Lambda Expansion -free Formula Function & Predicate Elimination Term Formula Finite Instantiation Boolean Formula Boolean Satisfiability

23. Present State Next State  Reset Inputs (Arbitrary) System Model • State Variable Types • Boolean • Control signals • Integer • Data, addresses • Function • Memories, buffers • System Operation • Synchronous • All state variables updated on each step of operation • Interleaving • One (set of) state variable(s) updated at a time • Simulate in synchronous model with uninterpreted scheduling function

24. Outline • Why Infinite State Systems? • Modeling capabilities of UCLID • Verification Methods • Implementation • Advances in SAT and decision procedures • Prospects and Challenges

25. Present State Next State  Inputs (Arbitrary) Verifying Safety Properties • Prove: System will never reach bad state Bad States Reachable States Reset States Reset

26. Reachable Rn • • • Bounded Model Checking Bad States • Repeatedly Perform Image Computations • Set of all states reachable by one more state transition • Easy to Implement • Underapproximation of Reachable State Set • But, typically catch most bugs with 8–10 steps R2 R1 Reset States

27. Reset    Bad     S X1 X2 Xn Implementing BMC Satisfiable? • Construct verification condition formula for step n by symbolically simulating system for n cycles • Check with decision procedure • Do as many cycles as tractable

28. Reach Fixed-Point Rn = Rn+1 = Reachable Impractical for Term-Level Models Many systems never reach fixed point Can keep adding elements to buffer Convergence test undecidable Bryant, Lahiri, Seshia, CHARME ‘03  Rn • • • True Model Checking Bad States R2 R1 Reset States

29.  I Inductive Invariant Checking Bad States • Key Properties of System that Make it Operate Correctly • Formulate as formula I • Prove Inductive • Holds initially I(s0) • Preserved by all state changes I(s)  I((i, s)) Reachable States Reset States

30. Verification Example: OOO valid tag val D E C O D E incr dispatch Program memory valid value src1valid src1val src1tag src2valid src2val src2tag dest op result PC Register Rename Unit 1st Operand result bus retire 2nd Operand ALU execute Reorder Buffer head tail Reorder Buffer Fields

31. ISA Reg. File PC OOO Reg. File PC Reorder Buffer Verifying OOO • Lahiri, Seshia, & Bryant, FMCAD 2002 • Goal • Show that OOO implements Instruction Set Architecture (ISA) model • For all possible execution sequences • Challenge • OOO holds partially executed instructions in reorder buffer • States of two systems match only when reorder buffer flushed

32. ISA Reg. File PC Adding Shadow State • McMillan, ‘98 • Arons & Pnueli, ‘99 • Provides Link Between ISA & OOO Models • Additional info. in ROB • Does not affect OOO behavior • Generated when instruction dispatched • Predict values of operands and result • From ISA model OOO Reg. File PC Reorder Buffer

33. valid tag val dispatch valid value src1valid src1val src1tag src2valid src2val src2tag dest op Register Rename Unit Reorder Buffer head tail Reorder Buffer Fields State Consistency Invariants • Register rename unit & reorder buffer encode same information redundantly • Rename Unit: Registers  Tags • Reorder Buffer: Tags  Registers

34. valid tag val dispatch valid value src1valid src1val src1tag src2valid src2val src2tag dest op State Consistency Invariant Examples • Register Renaming invariants (2) • Any mapped register should be in the ROB, and the destination register should match r.reg.valid(r) (rob.head  reg.tag(r) < rob.tail  rob.dest(reg.tag(r)) = r ) • For any ROB entry, the destination should have reg.valid as false and tag should be to this or later instruction robt.[reg.valid(rob.dest(t))  t  reg.tag(rob.dest(t))  reg.tag(rob.dest(t)) < rob.tail]

35. Inductive Invariants • Formulas I1, …, In • Ij(s0) holds for any initial state s0, for 1 jn • I1(s)  I2(s)  … In(s)  Ij(s ) for any current state s and successor state s for 1 jn • Overall Correctness • Follows by induction on time • Restricted form of invariants • x1x2…xk (x1…xk) • (x1…xk) is a CLU formula without quantifiers • x1…xk are integer variables free in (x1…xk) • Express properties that hold for all buffer indices, register IDs, etc.

36. Proving Invariants • Proving invariants inductive requires quantifiers |= [x1x2…xk (x1…xk)] [y1y2…ym (y1…ym)] • Prove unsatisfiability of formula x1x2…xk (x1…xk)  (y1…ym) • Undecidable Problem • In logic with uninterpreted functions and equality

37. Cooking with Invariants Ingredients: Predicates rob.head  reg.tag(r) Recipe: Invariants r,t.reg.valid(r)  reg.tag(r) = t  (rob.head  reg.tag(r) < rob.tail rob.dest(t) = r ) reg.valid(r) reg.tag(r) = t Result: Correctness rob.dest(t) = r

38. Automatic Recipe Generation Ingredients • Want Something More • Given any set of ingredients • Generate best recipe possible Result Recipe Creator

39. Automatic Predicate Abstraction • Graf & Saïdi, CAV ‘97 • Idea • Given set of predicates p1(S), …, pk(S) • Boolean formulas describing properties of system state • View as abstraction mapping: States {0,1}k • Defines abstract FSM over state set {0,1}k • Form of abstract interpretation • Do reachability analysis similar to symbolic model checking • Implementation • Early ones had weak inference capabilities • Call theorem prover or decision procedure to test each potential transition • Recent ones make better use of symbolic encodings

40. p1(s), …, pk(s) Abstraction Function  Concretization Function  s t s t Abstract State Space Abstraction Concretization Abstract States Abstract States Concrete States Concrete States

41. Abstract Transition Concretize  Abstract  Concrete Transition s s t t Abstract State Machine • Transitions in abstract system mirror those in concrete Abstract System Concrete System

42. A I Rn • • • R2 R1 Reset States Concretize  C Concrete System Reset States P.A. as Invariant Generator • Reach Fixed-Point on Abstract System • Termination guaranteed, since finite state • Equivalent to Computing Invariant for Concrete System • Strongest possible invariant that can be expressed by formula over these predicates Abstract System

43. Abstract Transitions (B’) Symbolic Formulation of Predicate Abstraction Lahiri, Bryant, Cook, CAV ‘03 • Task • Predicates P = p1(S), …, pk(S) • Compute set of legal abstract next states (B) given current abstract states (B) B,B: Abstract current and next-state state variables , : Boolean formulas (B) Abstract System

44. General Concretize  Concretize  B’ P [P/B] (S,B): [P/B]  BP[/S] Symbolic Formulation of P.A. • Approach • Create formula of form (S,B) Possible combinations of current concrete state S and next abstract state B (B) Abstract System Concrete System B P[/S] All Predecessors

45. (B)  S(S,B) General Concretize  Concretize  B’ P [P/B] (S,B): [P/B]  BP[/S] Symbolic Formulation of P.A. • Computing Next-State Set • Compute (B)  S(S,B) Requires quantifier elimination (B) Abstract System Concrete System B P[/S] All Predecessors

46. Quantified Invariant Generation (Lahiri & Bryant, VMCAI 2004) • User supplies predicates containing free variables • Generate globally quantified invariant • Example • Predicates p1: reg.valid(r) p2: reg.tag(r) = t p3: rob.dest(t) = r • Abstract state satisfying (p1p2p3) corresponds to concrete state satisfying r,t[reg.valid(r) reg.tag(r)=t  rob.dest(t)=r] rather than r[reg.valid(r)] r,t[reg.tag(r)=t] r,t[rob.dest(t)=r]

47. Outline • Why Infinite State Systems? • Modeling capabilities of UCLID • Verification Methods • Implementation • Advances in SAT and decision procedures • Prospects and Challenges

48. Decision Procedure Needs • Bounded Model Checking • Satisfiability of quantifier-free CLU formula • Handled by decision procedure • Invariant Checking • Satisfiability of quantified CLU formula • Undecidable • Predicate Abstraction • Eliminate quantifiers from CLU formula • Role of Decision Procedure • Apply in sound, but incomplete way

49. Input Formula Input Formula additional clause unsatisfiable Approximate Boolean Encoder Satisfiability-preserving Boolean Encoder First-order Conjunctions SAT Checker Boolean Formula Boolean Formula satisfiable SAT Solver SAT Solver satisfying assignment satisfiable unsatisfiable satisfiable unsatisfiable LAZY ENCODING EAGER ENCODING SAT-based Decision Procedures

50. Recent Progress in SAT Solving Driven by annual SAT competitions