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 Contributions by former graduate students: Sanjit Seshia, Shuvendu Lahiri

2. Outline • Task • Formally verify abstract models of hardware and software systems • Build on success in verifying finite models • Infinite-State Models • Need logic that is suitably expressive, yet remains reasonably tractable • Verification Techniques • Solve problems by mapping into propositional logic • Proof engines can use powerful Boolean methods • Different levels of automation and capacity

3. Theoretically Infinite-State Systems • Systems with unbounded buffers • Even though can’t really build one In Use • • • • • • • • • tail head

4. • • • P1 P2 PN Max-1 head 0 Arbitrarily Large Finite-State Systems • 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

5. 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

6. 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?

7.  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

8. 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

9. 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

10. 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

11. Modeling Data-Dependent Control Branch? Cond • Model by Uninterpreted Predicate • Yields arbitrary Boolean value for each control + data combination • Produces same result when arguments match Adata p Branch Logic Bdata

12. 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

13. M wa = wd a M 1 0 Effect of Memory Write Operation • Writing Transforms Memory • M = Write(M, wa, wd) • Reading from updated memory M(a): • Address wa will get wd • Otherwise get what’s already in M

14. Systems with Buffers Circular Queue Unbounded Buffer • Modeling Method • Mutable function to describe buffer contents • Integers to represent head & tail pointers

15. 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

16. 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

17. pc fd de mw em Branch Arg1 Target Arg2 RF Mem Value Instr Instr Arg2 Type Type Data Instr pPC PC PC Dest Type Valid Valid Valid Valid Modeling Example Boolean state Integer state • DLX Pipeline • Single-issue, 5-stage pipeline Function state Pipeline Write Back Fetch Decode Execute Memory

18. Write Back Decode fd de mw Arg1 src1 RF Arg2 Instr src2 Data Dest Valid Writing & Reading Register File

19. mw Data Dest Valid Writing Register File init[RF] := rf0; (* Uninterpreted Function *) next[RF] := Lambda(a) . case mw_Valid & (a = mw_Dest) : mw_Data; default : RF(a); esac; Write Back RF

20. fd de Arg1 Decode Arg2 Instr src1 RF src2 Reading Register File init[de_Arg1] := dea10; (* Initially arbitary *) next[de_Arg1] := next[RF](src1(fd_Instr)); init[de_Arg2] := dea20; (* Initially arbitary *) next[de_Arg2] := next[RF](src2(fd_Instr)); Write-before-read semantics

21. 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

22. 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

23. 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

24. e e 1 1 f f T T F F Ù Ù Ø e e Ø 0 0 = = x x f f Ú 0 0 T T Ú = = F F T T F F d d 0 0 Decision Problem • Circuit Representation of Formula • Truth Values • Dashed Lines • Model Control • Logical connectives • Equations • Integer Values • Solid lines • Model Data • Uninterpreted functions • If-Then-Else operation • Task • Determine whether formula F is universally valid • True for all interpretations of variables and function symbols • Often expressed as (un)satisfiability problem • Prove that formula F is not satisfiable

25. e e 1 1 f f T T F F x0 d0 f(x0) f(d0) Ù Ù Ø e e Ø 0 0 = = x x f f Ú 0 0 T T Ú = = F F T T F F d d 0 0 Finite Model Property • Observation • Any formula has limited number of distinct expressions • Only property that matters is whether or not different terms are equal

26. Boolean Encoding of Integer Values • For Each Expression • Either equal to or distinct from each preceding expression • Boolean Encoding • Use Boolean values to encode integers over small range • CLU formula can be translated into propositional logic • Logic circuit with multiplexors, comparators, logic gates • Tautology iff original formula valid

27. Recent Progress in SAT Solving

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

29. 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

30. 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

31. 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  Rn • • • True Model Checking Bad States R2 R1 Reset States

32.  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

33. 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

34. 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

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

36. Invariant Checking • 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 • Invariants for OOO (13) • Refinement maps (2) • Show relation between ISA and OOO models • Shadow state (3) • Shadow values correctly predict OOO values • State consistency (8) • Properties of OOO state that ensure proper operation • Overall Correctness • Follows by induction on time

37. 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)) < rob.tail)

38. Extending the OOO Processor • base • Executes ALU instructions only • exc • Handles arithmetic exceptions • Must flush reorder buffer • exc/br • Handles branches • Predicts branch & speculatively executes along path • exc/br/mem-simp • Adds load & store instructions • Store commits as instruction retires • exc/br/mem • Stores held in buffer • Can commit later • Loads must scan buffer for matching addresses

39. Comparative Verification Effort (Person time shown cumulatively)

40. “I Just Want a Loaf of Bread” Ingredients Result Recipe

41. 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

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

43. 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

44. 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

45. 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

46. A I Rn • • • R2 R1 Reset States Concretize  C Concrete System Reset States Generating Concrete Invariant • 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

47. Quantified Invariant Generation (Lahiri & Bryant, VMCAI 2004) • User supplies predicates containing free variables • Generate globally quantified invariant • Example • Predicates p1: reg.valid(r) p2: rob.dest(t) = r p3: reg.tag(r) = t • 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]

48. Systems Verified with Predicate Abstraction • Safety properties only

49. Future Prospects • Evaluation • Demonstrated ability to verify complex, parameterized systems • Predicate Abstraction Shows Promise • Provides key automation advantage of model checking • Successful Application to Program Application • Qadeer & Lahiri, POPL ’06 • Generate loop invariants for list manipulation programs