1 / 67

670 likes | 684 Views

Formal Verification of Infinite-State Systems Using Boolean Methods. Randal E. Bryant. Carnegie Mellon University. http://www.cs.cmu.edu/~bryant. Main Ideas. Infinite State Systems Greater power & generality than finite-state models Verified by extensions of finite-state model checking

Download Presentation
## Carnegie Mellon University

**An Image/Link below is provided (as is) to download presentation**
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.
Content is provided to you AS IS for your information and personal use only.
Download presentation by click this link.
While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

**Formal Verification**of Infinite-State Systems Using Boolean Methods Randal E. Bryant Carnegie Mellon University http://www.cs.cmu.edu/~bryant**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**Verification Example**• Task • Verify that microprocessor correctly implements instruction set definition • Even though heavily pipelined Alpha 21264 Microprocessor Microprocessor Report, Oct. 28, 1996**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**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**•**• • 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**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**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?**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****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**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**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**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**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**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**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**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**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**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**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, F1F2, F1F2 Boolean connectives T1 = T2 Equation T1 < T2 Inequality P(T1, …, Tk) Predicate application**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**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**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**Outline**• Why Infinite State Systems? • Modeling capabilities of UCLID • Verification Methods • Implementation • Advances in SAT and decision procedures • Prospects and Challenges**Present**State Next State Inputs (Arbitrary) Verifying Safety Properties • Prove: System will never reach bad state Bad States Reachable States Reset States Reset**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**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**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****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**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**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**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**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**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]**Inductive Invariants**• Formulas I1, …, In • Ij(s0) holds for any initial state s0, for 1 jn • I1(s) I2(s) … In(s) Ij(s ) for any current state s and successor state s for 1 jn • Overall Correctness • Follows by induction on time • Restricted form of invariants • x1x2…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.**Proving Invariants**• Proving invariants inductive requires quantifiers |= [x1x2…xk (x1…xk)] [y1y2…ym (y1…ym)] • Prove unsatisfiability of formula x1x2…xk (x1…xk) (y1…ym) • Undecidable Problem • In logic with uninterpreted functions and equality**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**Automatic Recipe Generation**Ingredients • Want Something More • Given any set of ingredients • Generate best recipe possible Result Recipe Creator**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**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**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**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**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**General**Concretize Concretize B’ P [P/B] (S,B): [P/B] BP[/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**(B)** S(S,B) General Concretize Concretize B’ P [P/B] (S,B): [P/B] BP[/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**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 (p1p2p3) 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]**Outline**• Why Infinite State Systems? • Modeling capabilities of UCLID • Verification Methods • Implementation • Advances in SAT and decision procedures • Prospects and Challenges**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**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**Recent Progress in SAT Solving**Driven by annual SAT competitions

More Related