Producing Effective Interpolants for SAT-based Incremental - PowerPoint PPT Presentation

Producing Effective Interpolants for SAT-based Incremental Verification and Upgrade Checking Grigory Fedyukovich Joint work with: Ondrej Sery, Simone Fulvio Rollini, Leonardo Alt, Antti E. J. Hyvärinen, and Natasha Sharygina F ORMAL V ERIFICATION L AB University of Lugano VSSE 2014, 5 Apr 2014, Grenoble, France

Motivation • Incremental checking of program correctness • One program, several properties • Eliminate redundancy in consequent verification runs • Checking upgrade correctness • Several programs, one property • Localize the verification to the change • Our methods • Use SAT-based Bounded Model Checking • Extracting function summaries by means of Craig Interpolation • Reusing function summaries in both scenarios • Controlling the size and strength of Craig Interpolants • Making the verification more efficient 2

Background Bounded Model Checking [Biere et al. 1999] • Successful technique to prove program safety • Static • Automatic • Gives a concrete counter-example or proof of safety • Loops and recursion unwound • Up to a given bound • Encoding into a BMC formula • Different logics available • Conjoin with the negation of a property • To encode an undesired b е havior • Satisfiability check by a SAT/SMT-solver • UNSAT à System is safe • SAT à Error found • Satisfying assignment identifies an error trace • Problems • Detecting the bound enough for complete checking • Constructing abstractions of the behavior 3

Background Counter-Example-Guided Abstraction Refinement [Ball et al. 2000] Initial Abstract Program Verification Proof Abstraction Model Safe model Checker Refine Counterexample the abstraction Refinement Simulator Bug found Simulation successful Counterexample is spurious 4

Background Abstraction • Over-approximates program behavior • Is used to speed up verification • No precise encoding required • Sound • If it is proven to be safe then the original program is safe • Possibly non-terminating • Every detected bug should be simulated on the real program • After each spurious counter-example the abstraction should be refined • Refinement may not terminate • Random • How to construct better abstraction? 5

Craig Interpolation [Craig et al. 1957] Definition: • Given mutually unsatisfiable formulas A and B, an Interpolant is a formula I such that • A → I • I ∧ B is unsatisfiable • Variables in I are common to both A and B A I B 6

Craig Interpolation [Craig et al. 1957] Definition: • Given mutually unsatisfiable formulas A and B, an Interpolant is a formula I such that • A → I • I ∧ B is unsatisfiable • Variables in I are common to both A and B ∧ B I’ A I B 6

Labeled Interpolation System [D’Silva et al. 2010] • Propositional logic, construction from unsatisfiablity proof • Generation of different interpolants from the same refutation • Interpolants of different size and strength • Generalization of algorithms of: • P by [Pudlak 1997] • M by [McMillan 2003] • M’ by [D’Silva et.al 2010] M P M’ 7

Proof reduction Affects the size of summaries • Eliminate redundancies in the proof DAG • Applied before interpolation • Different methods available: • RecyclePivotsWithIntersection [Bar-Ilan et al. 2008, Fontaine et al. 2010] • LowerUnits [Fontaine et al. 2010] • Structural hashing based approach [Cotton et al. 2010] • Local rewriting rules [Rollini et al. 2010] • Practically, ends up with more compact interpolants • the smaller formula, the faster usage 8

PeRIPLO high level overview 9

PeRIPLO high level overview The first … • set of techniques to obtain Verification Environment interpolants of different strength and size φ φ interp. system; f ᴧ g ᴧ ... distibution configure PBMC formula A ᴧ B • experimentation evidence SAT UNSAT that compact interpolants improve performance in Logic Solver interpolant the context of software A I → B ᴧ I → ⊥ BMC proof of UNSAT Proof Interpolator Transformer • evaluation of the impact of interpolant strength in PeRIPLO Summarization-based BMC 9

Function summaries in Bounded Model Checking • Apply Craig interpolation after SAT-solver returns UNSAT • Iterative procedure over the set of function calls • BMC created in a partitioned way • Each function represented by a separate partition in the BMC formula • Not monolithic as for classical BMC • Function summary • An over-approximation of the real behavior • Contains only the relevant information • Expressed using function’s in/out parameters 10

Summaries substitution During the check of another property of the same code 1) No error is reachable à OK, program is safe 2) Error is reachable A) due to over-approximation of summaries B) real error Solution: Refine the abstraction • Identify candidate summaries • Appeared along the error trace • Replace them by precise representation 11

Summaries substitution During the check of another property of the same code 1) No error is reachable à OK, program is safe 2) Error is reachable Σ A) due to over-approximation of summaries Σ B) real error Refinement of the abstraction: Σ • Identify candidate summaries Σ • Appeared along the error trace • Replace them by precise representation 12

Partitioned BMC main () ¡ φ main UNSAT ¡ call ¡ f () ¡ ∧ ⇔ φ f asser0on ¡holds ¡ call ¡ g () ¡ ∧ φ g ∧ return ¡ φ bug assert(!bug); ¡ return ¡ return ¡ 13

Construction of function summaries main () ¡ φ main B A ¡ ∧ B ¡ ¡ call ¡ f () ¡ ∧ UNSAT ¡ φ f B call ¡ g () ¡ ∧ φ g A ∧ return ¡ φ bug assert(!bug); ¡ return ¡ return ¡ B 13

Construction of function summaries main () ¡ φ main B A ¡ ∧ B ¡ ¡ call ¡ f () ¡ ∧ UNSAT ¡ φ f B call ¡ g () ¡ ∧ proof ¡of ¡UNSAT ¡ φ g A ∧ return ¡ φ bug assert(!bug); ¡ return ¡ return ¡ B 13

Construction of function summaries main () ¡ φ main B call ¡ f () ¡ ∧ φ f B call ¡ g () ¡ ∧ proof ¡of ¡UNSAT ¡ φ g I A ∧ return ¡ I ¡ ∧ B ¡ ¡ A ⇒ I φ bug assert(!bug); ¡ return ¡ return ¡ B UNSAT ¡ 13

Using summary for checking another assertion main () ¡ φ main UNSAT ¡ call ¡ f () ¡ ∧ ⇔ φ f asser0on ¡holds ¡ call ¡ g () ¡ ∧ φ g ∧ return ¡ Subs0tute ¡existent ¡ φ bug' assert(!bug'); ¡ return ¡ return ¡ summary ¡instead ¡of ¡ precise ¡encoding ¡ 14

Using summary for checking another assertion main () ¡ φ main UNSAT ¡ call ¡ f () ¡ ∧ ⇔ φ f asser0on ¡holds ¡ call ¡ g () ¡ ∧ φ g ∧ return ¡ Subs0tute ¡existent ¡ φ bug' assert(!bug'); ¡ return ¡ return ¡ summary ¡instead ¡of ¡ precise ¡encoding ¡ 14

Using summary for checking another assertion main () ¡ φ main SAT ¡ call ¡ f () ¡ ∧ ⇔ φ f bug ¡witness ¡ call ¡ g () ¡ ∧ φ g ∧ return ¡ φ bug φ bug' assert(!bug'); ¡ return ¡ return ¡ The ¡more ¡accurate ¡ summary, ¡the ¡be1er ¡ chance ¡to ¡prove ¡safety! ¡ 14

Interpolation algorithms main () ¡ φ main P by [Pudlak 1997] call ¡ f () ¡ M by [McMillan 2003] ∧ M’ by [D’Silva et al. 2010] φ f call ¡ g () ¡ ∧ φ g M P M’ ∧ return ¡ φ bug' assert(!bug'); ¡ return ¡ return ¡ The ¡stronger ¡interpolant, ¡the ¡ more ¡accurate ¡summary! ¡ 14

sources summaries *.c known new summaries summaries *.h goto binary parser PBMC formula goto-cc φ f ᴧ φ g ᴧ ... UNSAT solver PBMC Correct encoder PeRIPLO initializer SAT eager/lazy refiner Bug CEG/greedy & error trace Σ * * Σ Σ Σ Σ initial subst. scenario refined subst. scenario 15

FunFrog evaluation • 50 C benchmarks • Assertions on different call-tree levels • Checking one assertion at a time • Strength: M, P, M’ • Size: proof compression for interpolants reduction 16

FunFrog evaluation 17

Function-summarization-based Upgrade Checking The eVolCheck algorithm 0) Verification of the base version of the software ( bootstrap ) • function summaries generated and stored 18

Function-summarization-based Upgrade Checking The eVolCheck algorithm 0) Verification of the base version of the software ( bootstrap ) • function summaries generated and stored 1) The user upgrades the software 2) Upgraded version of the software is preprocessed 3) eVolCheck identifies the modified code • by comparing parse trees for both the base and the upgraded version • function per function, in the intermediate program representation 4) eVolCheck attempts to verify the upgraded version 4) by rechecking whether old summaries still over-approximate new code 5) If all old function summaries are still valid then the upgrade is safe 6) If a summary is invalid, eVolCheck propagates 6) The user fixes the reported errors and continues from step 2) 18

Upgrade Checking [Fedyukovich et al. 2013] Original version is safe main () ¡ φ main call ¡ f () ¡ ∧ φ f call ¡ g () ¡ ∧ φ g ∧ return ¡ φ bug assert(!bug); ¡ return ¡ return ¡ 19