1. Carnegie Mellon University Formal Verification of Infinite-State Systems Using Boolean Methods Formal Verification of Infinite-State Systems Using Boolean Methods http://www.cs.cmu.edu/~bryant Randal E. Bryant Contributions by former graduate students: Sanjit Seshia, Shuvendu Lahiri

2. – 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. – 3 – Theoretically Infinite-State Systems Systems with unbounded buffers Even though can’t really build one tailhead In Use

4. – 4 – 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 tail head In Use 0 Max-1 P2P2 PNPN P1P1

5. – 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. – 6 – What About Theorem Provers? Traditional Tool for Formal Verification Allow many forms of abstraction Hard to Use Lots of manual effort & expertise requiredQuestion: Can we incorporate some of these abstraction abilities into an automated tool?

7. – 7 – Data Abstraction #1: Bits → Integers View Data as Symbolic Words Arbitrary integers No assumptions about size or encoding Classic model for reasoning about software Can store in memories & registers x0x0 x1x1 x2x2 x n-1 x 

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

9. – 9 – 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) ALUALU f

10. – 10 – Abstracting Functions For Any Block that Transforms Data: Replace by uninterpreted function Ignore detailed functionality Conservative approximation of actual system Data Path Control Logic Com. Log. 1 Com. Log. 1 F1F1 F2F2

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

12. – 12 – Abstraction #3: Modeling Memories as Mutable Functions Memory M Modeled as Function M(a): Value at location aInitially Arbitrary state Modeled by uninterpreted function m 0 M a M a m0m0

13. – 13 – 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 M M a 1010 wd = wa

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

15. – 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. – 16 – 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  Present State Next State Inputs (Arbitrary) Reset

17. – 17 – Pipeline Modeling Example DLX Pipeline Single-issue, 5-stage pipeline pc pPC fd Valid PC Type Instr de Valid PC Type Instr Arg2 Arg1 mw Valid Dest Data em Branch Valid Type Instr Arg2 Value Target RFMem FetchDecodeExecuteMemory Write Back Integer state Boolean state Function state

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

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

20. – 20 – Reading Register File fd Instr de Arg2 Arg1 RF Decode src1 src2 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. – 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. – 22 – CLU Logic Counter Arithmetic, Lambda Expressions and Uinterpreted Functions Terms ( T )Integer Expressions ITE(F, T 1, T 2 ) If-then-else Fun (T 1, …, T k ) Function application succ (T) Increment pred (T) Decrement Formulas ( F )Boolean Expressions  F, F 1  F 2, F 1  F 2 Boolean connectives T 1 = T 2 Equation T 1 < T 2 Inequality P(T 1, …, T k ) Predicate application To support pointer operations

23. – 23 – CLU Logic (Cont.) Functions ( Fun )Integer  Integer f Uninterpreted function symbol x 1, …, x k. T Function definition Predicates ( P )Integer  Boolean p Uninterpreted predicate symbol x 1, …, x k. F Predicate definition

24. – 24 – 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 operationTask 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 =   f T F T F f T F  = e 1 e 0 x 0 d 0 T F T F T F e 1 e 0 x 0 d 0 =   f f  =

25. – 25 – =   f T F T F f T F  = e 1 e 0 x 0 d 0 T F T F T F e 1 e 0 x 0 d 0 =   f f  = Finite Model Property Observation Any formula has limited number of distinct expressions Only property that matters is whether or not different terms are equal x0x0 d0d0 f (x0)f (x0) f (d0)f (d0)

26. – 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 Expression Possible Values Bit Encoding x0x0{0}00 d0d0{0,1}0 b 10 f (x0)f (x0){0,1,2} b 21 b 20 f (d0)f (d0){0,1,2,3} b 31 b 30

27. – 27 – Recent Progress in SAT Solving

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

29. – 29 – Reachable RnRn R2R2 Bounded Model Checking 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 Bad States R1R1 Reset States

30. – 30 – Implementing BMC Construct verification condition formula for step n by symbolically simulating system for n cycles Check with decision procedure Do as many cycles as tractable         S X1X1 X2X2 XnXn  Bad Reset Satisfiable?

31. – 31 – RnRn R2R2 True Model Checking Reach Fixed-Point R n = R n+1 = Reachable Impractical for Term-Level Models Many systems never reach fixed point Can keep adding elements to buffer Convergence test undecidable Bad States R1R1 Reset States 

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

33. – 33 – An Out-of-order Processor (OOO) 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 Reorder Buffer Fields PC Program memory Reorder Buffer valid value src1valid src1val src1tag src2valid src2val src2tag dest op result bus DECODEDECODE Register Rename Unit valid tag val ALU headtail incr dispatch retire execute result 1 st Operand 2 nd Operand

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

35. – 35 – 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 ISA Reg. File PC OOO Reg. File PC Reorder Buffer

36. – 36 – Invariant Checking Formulas I 1, …, I n I j (s 0 ) holds for any initial state s 0, for 1  j  n I 1 (s)  I 2 (s)  …  I n (s)  I j (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. – 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  rob t.(  reg.valid(rob.dest(t))  t  reg.tag(rob.dest(t)) < rob.tail)

38. – 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. – 39 – Comparative Verification Effort baseexcexc / brexc / br / mem-simp exc / br / mem Total Invariants 1334396771 UCLID time 54 s236 s403 s1594 s2200 s Person time 2 days7 days9 days24 days34 days (Person time shown cumulatively)

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

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

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

43. – 43 – Automatic Predicate Abstraction Graf & Saïdi, CAV ‘97Idea Given set of predicates P 1 (s), …, P k (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 checkingImplementation 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. – 44 – Abstract State Space Concrete States Abstract States  P 1 (s), …, P k (s)  sAbstraction Function  t Abstraction Concrete States Abstract States st Concretization Function  Concretization

45. – 45 – Abstract State Machine Transitions in abstract system mirror those in concrete Abstract  Concrete System Abstract System s Concretize  t t s Concrete Transition Abstract Transition

46. – 46 – 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 RnRn R2R2 R1R1 Reset States AA Abstract System Concretize  Concrete System I Reset States CC

47. – 47 – Quantified Invariant Generation (Lahiri & Bryant, VMCAI 2004) User supplies predicates containing free variables Generate globally quantified invariantExample Predicates p 1 : reg.valid(r) p 2 : rob.dest(t) = r p 3 : reg.tag(r) = t Abstract state satisfying ( p 1  p 2   p 3 ) 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. – 48 – Systems Verified with Predicate Abstraction Safety properties only Model PredicatesIterationsCPU Time Out-Of-Order Execution Unit2591,207s German’s Cache Protocol13914s German’s Protocol, unbounded channels 2417427s Lamport’s Bakery Algorithm3318471s

49. – 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

50. – 50 –

51. – 51 – Automatic Predicate Discovery Strength of Predicate Abstraction If give it right set of predicates, PA will put them together into invariantWeakness Gets nowhere without right set of predicates Typical failure mode: Generate “true” as invariantChallenges Too many predicates will overwhelm PA engine Our use of quantified invariants precludes counterexample- generated refinement techniques

52. – 52 – Implementation of Predicate Discovery Lahiri & Bryant, CAV ’04 Initially: Extract predicates from verification condition Iterate: Add new predicates by composing next-state formulas With some heuristics thrown inExperience Can automatically generate invariants for real examples ~10X slower than for hand-selected predicates