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

2. Outline • Task • Formally verify 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. Air Bag Controller Speedometer Reading Deploy! Accelerometer Reading Truly Infinite-State Systems • Systems where want to model real-world values (temperature, speed, ...) • Hybrid systems • Very difficult to verify • Systems with real-valued time constraints • E.g., timed automata • Somewhat easier to verify, since all clocks move at same rate

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

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

6. IF/ID ID/EX EX/WB PC Control Control Op Instr Mem Rd Ra = Adat Reg. File ALU Imm +4 = Rb Very Large Finite-State Systems • Abstract 32-bit words as arbitrary integers • View memories as having unbounded capacity

7. Example: HP/Compaq Alpha 21264 • Pipeline State • Multiple caches • Instruction queues • Dynamically-allocated registers • Memory queue • Many buffers between stages • Verification Tasks • Does it implement the Alpha ISA? Microprocessor Report, Oct. 28, 1996

8.  x p T F x 1 0 ITE(p, x, y) x x 1 0 1 0 y x y y y Abstracting Data from Bits to Integers x0 x1 • View Data as Symbolic “Terms” • Arbitrary integers • Verification proves correctness of design for all possible word sizes • Can store in memories & registers • Can select with multiplexors • ITE: If-Then-Else operation x2 xn-1

9. ALU Abstraction Via 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. IF/ID ID/EX EX/WB PC Control Control Op Instr Mem Rd Ra = Adat Reg. File ALU Imm +4 = Rb Abstraction Via Uninterpreted Functions • For any Block that Transforms or Evaluates Data: • Replace with generic, unspecified function • Also view instruction memory as function F3 F2 F1

11. EUF: Equality with Uninterp. Functs • Decidable fragment of first order logic • Formulas (F ) Boolean Expressions F, F1F2, F1F2 Boolean connectives T1 = T2 Equation P (T1, …, Tk) Predicate application • Terms (T ) Integer Expressions ITE(F, T1, T2) If-then-else Fun (T1, …, Tk) Function application • Functions (Fun) Integer  Integer f Uninterpreted function symbol Read, Write Memory operations • Predicates (P) Integer  Boolean p Uninterpreted predicate symbol

12. e 1 f T F Ù e Ø 0 = x f 0 T Ú = F T F d 0 Decision Problem • Logic of Equality with Uninterpreted Functions (EUF) • 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 is universally valid • True for all interpretations of variables and function symbols

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

14. 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 • EUF formula can be translated into propositional logic • Tautology iff original formula valid

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

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

17. Required Logic • Increased Expressive Power • Model queue pointers • Increment & decrement operations • Relative ordering • Ability to construct complex memory structures • Not just set of fixed memory types • Don’t Go Too Far • Want practical decision procedures • Efficient reduction to propositional logic

18. succ (T) Increment pred (T) Decrement T1 < T2 Inequality EUF  CLU • Terms (T ) ITE(F, T1, T2) If-then-else Fun (T1, …, Tk) Function application • Formulas (F ) F, F1F2, F1F2 Boolean connectives T1 = T2 Equation P(T1, …, Tk) Predicate application

19.  x1, …, xk . T Function lambda expression  x1, …, xk . F Predicate lambda expression • Arguments can only be terms • Lambdas are just mutable arrays EUF  CLU (Cont.) • Functions (Fun) f Uninterpreted function symbol Read, Write Memory operations • Predicates (P) p Uninterpreted predicate symbol

20. Memory M Modeled as Function M(a): Value at location a Initially Arbitrary state Modeled by uninterpreted function m0 Writing Transforms Memory M = Write(M, wa, wd) a . ITE(a = wa, wd, M(a)) Future reads of address wa will get wd M a M wa = M wd a m0 M a 1 0 Modeling Memories with ’s

21. • • • • • • Modeling Unbounded FIFO Buffer Already Popped • Queue is Subrange of Infinite Sequence • Q.head = h • Index of oldest element • Q.tail = t • Index of insertion location • Q.val = q • Function mapping indices to values • q(i) valid only when hi < t • Initial State: Arbitrary Queue • Q.head = h0, Q.tail = t0 • Impose constraint that h0 t0 • Q.val = q0 • Uninterpreted function q(h–2) q(h–1) head q(h) q(h+1) • • • increasing indices q(t–2) q(t–1) tail q(t) q(t+1) Not Yet Inserted

22. op = PUSH Input = x • • • next[h] := ITE(operation = POP, succ(h), h) • • • • • • q(h–2) q(h–2) q(h–1) q(h–1) next[h] q(h) q(h) h q(h+1) q(h+1) next[t] := ITE(operation = PUSH, succ(t), t) • • • • • • q(t–2) q(t–2) q(t–1) q(t–1) next[q] :=  (i). ITE((operation = PUSH & i=t), x, q(i)) t q(t) x next[t] q(t+1) q(t+1) • • • Modeling FIFO Buffer (cont.)

23. Systems of Identical Processes • Each Process has k State Variables • Each state variable represented as array • Indexed by process Id • • • • • • sv1 • • • • • • sv2 • • • • • • svk State of Process i

24. • • • • • • inuse p 0/1 state CRITICAL IDLE TRYING Modeling System of Identical Processes • On Each Step: • Select arbitrary process index p • As if chosen by nondeterministic scheduler • Update state for selected process next[state] := lambda(i) case i = p &state(i) = IDLE: TRYING i = p &state(i) = TRYING & inuse : TRYING i = p &state(i) = TRYING & !inuse: CRITICAL default: state(i) esac

25. Decision Procedure CLU Formula • Operation • Series of transformations leading to propositional formula • Propositional formula checked with BDD or SAT tools • Bryant, Lahiri, Seshia [CAV02] Lambda Expansion -free Formula Function & Predicate Elimination Function-free Formula Convert to Boolean Formula Boolean Formula Boolean Satisfiability

26. y –1 x x y –1 y –1 y –1 x x y –1 x x+1 y x+1 y y y x+1 x+1 y x+1 x = 0, y = 3 x = 2, y = 1 Finite Model Property for CLU x  y  succ(x) > pred(y) • Observation • Need to encode all possible relative orderings of expressions • Each symbolic value has maximum range of increments & decrements • Can use Boolean encodings of small integer ranges

27. 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 • Challenges • No bound on program length • OOO holds partially executed instructions in reorder buffer • States of two systems match only when reorder buffer flushed

28. ISA Reg. File PC Adding Shadow State • McMillan, ‘98 • Arons & Pnueli, ‘99 • Provides Link Between ISA & OOO Models • Additional entries 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

29. valid tag val Reorder Buffer Fields incr D E C O D E dispatch Program memory valid value src1valid src1val src1tag src2valid src2val src2tag dest op PC Register Rename Unit shdw.value shdw.src1val retire ALU shdw.src2val Reorder Buffer execute Shadow Fields head tail Adding Shadow Structures result bus • shdw.src1val[rob.tail]  Rfisa(src1) • shdw.src2val[rob.tail]  Rfisa(src2) • shdw.value[rob.tail]  ALU(Rfisa(src1), Rfisa(src2), op) Updated directly from the ISA model during dispatch

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

31. valid tag val dispatch incr Reorder Buffer Fields D E C O D E Program memory valid value src1valid src1val src1tag src2valid src2val src2tag dest op PC Register Rename Unit shdw.value result bus shdw.src1val retire ALU shdw.src2val Reorder Buffer execute head tail Shadow Fields Refinement Maps • Correspondence with a sequential ISA model • OOO and ISA synchronized at dispatch • For Register File Contents • r. reg.valid(r)  reg.val(r) = Rfisa(r) • For Program Counter • PCooo = PCisa

32. valid tag val Reorder Buffer Fields incr D E C O D E dispatch Program memory valid value src1valid src1val src1tag src2valid src2val src2tag dest op PC Register Rename Unit shdw.value shdw.src1val retire ALU shdw.src2val Reorder Buffer execute Shadow Fields head tail Shadow Invariants result bus • robt. rob.valid(t)  rob.value(t) = shdw.value(t) • robt. rob.src1valid(t)  rob.src1val(t) = shdw.src1val(t) • robt. rob.src2valid(t)  rob.src2val(t) = shdw.src2val(t)

33. State Consistency Invariants • Tag Consistency invariants (2) • Instructions only depend on instruction preceding in program order • Register Renaming invariants (2) • Tag in a rename-unit 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 entry, the destination should have reg.valid as false and tag should contain this or later instruction robt.(reg.valid(rob.dest(t))  t  reg.tag(rob.dest(t)) < rob.tail)

34. Quantified Invariants and Proofs • Allowed Form • x1x2…xk(x1…xk) • (x1…xk) is a CLU formula without quantifiers • x1…xk are integer variables free in (x1…xk) • Proving these invariants requires quantifiers |= (x1x2…xk (x1…xk))  y1y2…ym (y1…ym) • Prove x1x2…xk[(x1…xk)  (y1…ym)] is not satisfiable • Undecidable • Automatic instantiation of x1…xkwith concrete terms • Sound but incomplete method • Reduce the quantified formula to a CLU formula • Can use the decision procedure for CLU

35. Proving Invariants • Proved Automatically • Quantifier instantiation was sufficient in these cases • Time spent = 54s on 1.4GHz machine • Total effort = 2 person days • Comparison • Previous efforts using theorem provers took weeks of effort

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

37. Comparative Verification Effort

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

39. 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) Result: Correctness reg.tag(r) = t rob.dest(t) = r

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

41. 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 • Prior Implementations • Very weak inference capabilities • Call theorem prover or decision procedure to test each potential transition • Little support for quantified predicates

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

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

44. Overapproximation by Abstract Model • Path in abstract state space may not correspond to one in concrete • OK when verifying safety properties • Possible false negatives, but no false positives Abstract System Concrete System

45. Predicate Abstraction Example • State Space • State variables: { x, y } • Initial State • { (2, 1) } • Next State Behavior • x x • y y • Verification Task • Prove all bad states unreachable Initial State Bad States

46. Precise Analysis • Reachable States • { (2, 1), (2, 1) } Reachable States Bad States

47. cx:3 cx:y cy:0 L L G E E E G G L Predicates • Use 3-valued predicates in this example

48. cx:3 cx:y cy:0 L G G Abstract Initial State Reached Set #0 { LGG }

49. (Note loss of precision) Concretize Concretize Concretize g g g s s s Step 1: Concretize Reached Set #0 Reached Set #0 { LGG } cx:3 cx:y cy:0 L G G

50. Concretize Concretize Concretize g g g Concrete Transition Concrete Transition Concrete Transition ¢ ¢ ¢ s s s s s s Compute Possible Successor States x x y y