520 likes | 532 Views
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. Outline. Task
E N D
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
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
Theoretically Infinite-State Systems • Systems with unbounded buffers • Even though can’t really build one In Use • • • • • • • • • tail head
• • • 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
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
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?
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
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
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
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
Systems with Buffers Circular Queue Unbounded Buffer • Modeling Method • Mutable function to describe buffer contents • Integers to represent head & tail pointers
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
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
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
Write Back Decode fd de mw Arg1 src1 RF Arg2 Instr src2 Data Dest Valid Writing & Reading Register File
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
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
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
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
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
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
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 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
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
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 • Do not affect OOO behavior • Generated when instruction dispatched • Predict values of operands and result • From ISA model OOO Reg. File PC Reorder Buffer
Invariant Checking • 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 • 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
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)
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
Comparative Verification Effort (Person time shown cumulatively)
“I Just Want a Loaf of Bread” Ingredients Result Recipe
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 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
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 (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]
Systems Verified with Predicate Abstraction • Safety properties only
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