Download presentation

Presentation is loading. Please wait.

Published byAlexis Rodgers Modified over 2 years ago

1
Carnegie Mellon University Formal Verification of Infinite-State Systems Using Boolean Methods Formal Verification of Infinite-State Systems Using Boolean Methods Randal E. Bryant

2
– 2 – FLoC 06 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 automateOutline Why infinite state systems? UCLID modeling capabilities Verification methods Implementation Advances in SAT and decision procedures Prospects and challenges

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

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

5
– 5 – FLoC 06 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 tailhead In Use

6
– 6 – FLoC 06 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 tail head In Use 0 Max-1 P2P2 PNPN P1P1

7
– 7 – FLoC 06 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
– 8 – FLoC 06 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?

9
– 9 – FLoC 06 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

10
– 10 – FLoC 06 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

11
– 11 – FLoC 06 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?

12
– 12 – FLoC 06 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

13
– 13 – FLoC 06 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

14
– 14 – FLoC 06 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

15
– 15 – FLoC 06 Effect of Memory Write Operation Writing Transforms Memory M = Write(M, wa, wd) Reading from updated memory: Address wa will get wd Otherwise get whats already in M Express with Lambda Notation M = a. ITE(a = wa, wd, M(a)) M M a 1010 wd = wa

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

17
– 17 – FLoC 06 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

18
– 18 – FLoC 06 ALU execute Directly Addressable Select particular entry for execution Retrieve result value from executed instruction Access Modes for Reorder Buffer FIFO Insert when dispatch Remove when retire Content Addressable Broadcast result to all entries with matching source tag headtail RetireDispatch result busGlobal Flush all queue entries when instruction at head causes exception

19
– 19 – FLoC 06 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
– 20 – FLoC 06 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

21
– 21 – FLoC 06 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

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

23
– 23 – FLoC 06 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

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

25
– 25 – FLoC 06 Reachable States Verifying Safety Properties Prove: System will never reach bad state Reset States Bad States Present State Next State Inputs (Arbitrary) Reset

26
– 26 – FLoC 06 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

27
– 27 – FLoC 06 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?

28
– 28 – FLoC 06 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 Bryant, Lahiri, Seshia, CHARME 03 Bad States R1R1 Reset States

29
– 29 – FLoC 06 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

30
– 30 – FLoC 06 Verification Example: OOO 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

31
– 31 – FLoC 06 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

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

33
– 33 – FLoC 06 State Consistency Invariants Register rename unit & reorder buffer encode same information redundantly Rename Unit: Registers Tags Reorder Buffer: Tags Registers Reorder Buffer Fields Reorder Buffer valid value src1valid src1val src1tag src2valid src2val src2tag dest op Register Rename Unit valid tag val headtail dispatch

34
– 34 – FLoC 06 valid value src1valid src1val src1tag src2valid src2val src2tag dest op valid tag val dispatch 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)) reg.tag(rob.dest(t)) < rob.tail]

35
– 35 – FLoC 06 Inductive Invariants 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 Overall Correctness Follows by induction on time Restricted form of invariants x 1 x 2 … x k (x 1 …x k ) (x 1 …x k ) is a CLU formula without quantifiers x 1 …x k are integer variables free in (x 1 …x k ) Express properties that hold for all buffer indices, register IDs, etc.

36
– 36 – FLoC 06 Proving Invariants Proving invariants inductive requires quantifiers |= [ x 1 x 2 … x k (x 1 …x k ) ] [ y 1 y 2 … y m (y 1 …y m ) ] Prove unsatisfiability of formula x 1 x 2 … x k (x 1 …x k ) (y 1 …y m ) Undecidable Problem In logic with uninterpreted functions and equality

37
– 37 – FLoC 06 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

38
– 38 – FLoC 06 Automatic Recipe Generation Want Something More Given any set of ingredients Generate best recipe possible Ingredients Recipe Creator Result

39
– 39 – FLoC 06 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

40
– 40 – FLoC 06 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

41
– 41 – FLoC 06 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

42
– 42 – FLoC 06 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 RnRn R2R2 R1R1 Reset States A Abstract System Concretize Concrete System I Reset States C

43
– 43 – FLoC 06 Symbolic Formulation of Predicate Abstraction Task Predicates P = p 1 ( S ), …, p k ( 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 Lahiri, Bryant, Cook, CAV 03 Abstract System ( B ) Abstract Transitions

44
– 44 – FLoC 06 Symbolic Formulation of P.A. Approach Create formula of form ( S, B ) Possible combinations of current concrete state S and next abstract state B Abstract System ( B ) Concretize [P/ B ] Concrete System B P General Concretize B P[ / S ] All Predecessors ( S, B ): [P/ B ] B P[ / S ]

45
– 45 – FLoC 06 Symbolic Formulation of P.A. Computing Next-State Set Compute ( B ) S ( S, B ) Requires quantifier elimination Abstract System ( B ) Concretize [P/ B ] Concrete System B P General Concretize B P[ / S ] All Predecessors ( S, B ): [P/ B ] B P[ / S ] ( B ) ( B ) S ( S, B ) S ( S, B )

46
– 46 – FLoC 06 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 : reg.tag(r) = t p 3 : rob.dest(t) = r 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]

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

48
– 48 – FLoC 06 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
– 49 – FLoC 06 SAT-based Decision Procedures Input Formula Boolean Formula satisfiable unsatisfiable Satisfiability-preserving Boolean Encoder SAT Solver EAGER ENCODING Input Formula Boolean Formula satisfiable unsatisfiable Approximate Boolean Encoder SAT Solver satisfying assignment satisfiable First-order Conjunctions SAT Checker unsatisfiable additional clause LAZY ENCODING

50
– 50 – FLoC 06 Recent Progress in SAT Solving Driven by annual SAT competitions

51
– 51 – FLoC 06 UCLID Decision Procedure Eager approach Lambda Expansion Function & Predicate Elimination Finite Instantiation Boolean Satisfiability CLU Formula -free Formula Term Formula Boolean Formula

52
– 52 – FLoC 06 Eager Encoding Characteristics –Must encode all information about domain properties into Boolean formula –Some properties can give exponential blowup +Lets SAT solver do all of the work Good Approach for Some Domains Modern SAT solvers have remarkable capacity Good at extracting relevant portions out of very large formulas Learns about formula properties as search proceeds Input Formula Boolean Formula satisfiable unsatisfiable Satisfiability-preserving Boolean Encoder SAT Solver

53
– 53 – FLoC 06 DPLL(T) Ganzinger, Hagen, Nieuwenhuis, Oliveras, Tinell, CAV 04 Modular, Lazy Decision Procedure Modern SAT solver as control loop Theory-specific solver (for theory T) plugs in Compared to Other Lazy Solvers Tighter coupling between DPLL engine & theory solver DPLL Engine Theory Solver Formula Tentative Partial Solution OK / Backtrack Info.

54
– 54 – FLoC 06 DPLL(T) Example g(a) c [f(g(a)) f(c) g(a) d] c d p1p1 [ p 2 p 3 ] p 4 ActionPropositionalTheory Unit Propagate p1p1 g(a) c Theory Propagate p2p2 f(g(a)) f(c) Unit Propagate p3p3 g(a) d Theory Propogate p4p4 c d (Failure) Formula Propositional Form T = Equality with Uninterpreted Functions (EUF)

55
– 55 – FLoC 06 Invariant Checking Revisited Prove Unsatisfiability of Formula x 1 x 2 … x k (x 1 …x k ) (y 1 …y m ) General Form: X (X) (Y) Quantifier Instantiation Generate expressions E 1 (Y), …, E n (Y) Using terms that appear in View as a set of axioms that apply to terms in Expand as (E 1 (Y)) … (E n (Y)) (Y) If unsatisfiable, then so is quantified formula Sound, but incompleteTrade-off Be clever about instantiation, or Instantiate many terms and rely on decision procedure capacity

56
– 56 – FLoC 06 Versions of 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

57
– 57 – FLoC 06 Comparative Verification Effort UCLID & Barcelona DPLL(T) decision procedures Measurements by Shuvendu Lahiri Person time shown cumulatively baseexcexc / brexc / br / mem-simp exc / br / mem Total Invariants UCLID time 54 s236 s403 s1594 s2200 s DPLL(T) time 1 s4 s7 s85 s Person time 2 days7 days9 days24 days34 days

58
– 58 – FLoC 06 Predicate Abstraction Revisited Formulate as Quantifier Elimination Problem Generate formula of form ( B ) S ( S, B ) S : Integer variables Solve by SAT Enumeration Find satisfying assignment ( S ) ( B ) for Record ( B ) as disjunct in Reformulate as ( B )Implementations UCLID Do eager translation, then run incremental SAT solver DPLL(T) [Lahiri, Nieuwenhuis, Oliveras, CAV 06] Modify DPLL engine to backtrack when it finds solution

59
– 59 – FLoC 06 Systems Verified with Predicate Abstraction Safety properties only Model PredicatesIterations UCLID Time DPLL(T) Time Out-Of-Order Execution Unit259921s36s Germans Cache Protocol16934s1s Germans Protocol, unbounded channels 26171,119s23s Lamports Bakery Algorithm s11s

60
– 60 – FLoC 06 Why SAT Enumeration Works Model with P predicates Number of abstract reachable states << 2 P Model PredicatesStatesFraction Out-Of-Order Execution Unit2510,7283 X Germans Cache Protocol X Germans Protocol, unbounded channels 262,2383 X Lamports Bakery Algorithm X 10 -7

61
– 61 – FLoC 06 UCLID Counterexample Generation Counterexample trace showing value of each state variable on each step. Value of a lambda is a set of argument/value pairs Important feature for tool users Lambda Expansion Function & Predicate Elimination Finite Instantiation Boolean Satisfiability Symbolic Simulation Trace Partial Interp. of Lambdas Partial Interpretation of UIFs Integer Assignment Boolean Assignment

62
– 62 – FLoC 06 Providing Counterexamples Bounded Checking Trace shows concrete failure case Could represent error in design, in model, or in specification Invariant Checking Failure could be due to weak invariant or insufficient quantifier instantiation Predicate Abstraction Does not provide useful counterexamples Generally yields abstract state true

63
– 63 – FLoC 06 Outline Why Infinite State Systems? Modeling capabilities of UCLID Verification Methods Implementation Advances in SAT and decision procedures Prospects and Challenges

64
– 64 – FLoC 06 Why Verification Tasks Feasible CLU Logic Fairly Simple Equality, uninterpreted functions, difference constraints Small model property Deep Reasoning Not Required Formulas large and messy, but straightforward Verifying systems that are designed to have constrained behaviors Only checking effect of a few cycles of system operation

65
– 65 – FLoC 06 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 Verification Qadeer & Lahiri, POPL 06 Generate loop invariants for list manipulation programs

66
– 66 – FLoC 06 Areas of Research Bit-Vector Decision Procedures True model for hardware & low-level software Automatically apply abstractions Abstract to symbolic terms whenever possible Other Types of Verification Liveness properties Abstraction must underapproximate concrete system Certified correctness Explanation-generating decision procedures Extension to predicate abstraction engine Counterexample generation Important for user Hard to provide as raise level of abstraction & automation

67
Questions?

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google