Property Directed Equivalence via Abstract Simulation Grigory Fedyukovich, Arie Gurfinkel, and Natasha Sharygina CAV, Jul 23, 2016
Motivation / Goals Little Leaks Add Up to Big Bills software safety must be re-proven after even a small change verification from scratch is expensive Property Directed Equivalence of Programs in contrast to absolute equivalence check whether two programs both satisfy the same property Safety Proof Migration formally verify one program aim at establishing a simulation relation lift the proof using the simulation to another program 1
counter-example change impact Big Picture Niagara Framework...... Simulation Discovery to synthesize a mapping between variables [LPAR 15] evolution process V i proof program encoding Simulation Discovery prev. round V i Proof Adapt to migrate the proof certificate across evolution boundaries to obtain a counter-example and a change impact Program Repair 2 to provide a hint to the user how to fix the detected bug [NFM 14] [CAV 16] [tbd...] evolution process... candidate repair simulation relation abstraction of Vi proof to be adapted proof program Proof V i+1 encoding Adapt V i+1 evolution process program encoding program encoding Program Repair adapted proof enable next round...
What We Mean By Proofs [Hoare 69] Hoare Triples {precond} code {postcond} precond, postcond are expressions over program variables code is some code fragment That is, if code starts in a state satisfying precond and terminates, then code ends in a state satisfying postcond Example {x>=0} x++; if (*) x:=1 else x++ {x>=1} validity of the triple as unsatisfiability of the formula: (x 0 0) ^ (x 1 = x 0 + 1) ^ (x 2 =1_ x 2 = x 1 + 1) ^ (x 2 1) =)? 3
Example Safe Program {>} {x 0} {?} Cutpoint graph (CPG) [Beyer et al. 09] generalization of classical Control-Flow graph each edge is a longest loop-free program path A safety proof is a mapping from nodes of CPG to expressions such that each edge is a valid Hoare triple (inductiveness) entry location is mapped to true error location is mapped to false (safety) 4 Assume no overflow for simplicity of presentation
Example Safe Program Evolved and Got an Extra Loop {>} {>} {?} {x 0} {?} {?} {?} 5 Assume no overflow for simplicity of presentation
Example Establishing Simulation between Programs {>} {>} {?} {x 0} {?} {?} {?} 5 Assume no overflow for simplicity of presentation
Example Using Simulation to Lift Proofs between Programs {>} {>} {x 0} {x 0} {x 0} {?} safety is preserved {?} 5 Assume no overflow for simplicity of presentation
Abstract Simulation Discovery [Milner 71] Searching for total simulation relations for each behavior of one program (called source) there should exist a behavior of another program (called target) matched by some simulation relation Synthesizing abstract simulation relations if the target does not simulate the source search for an abstraction of the target that does 6
Prior Work big picture [LPAR 15] source target Two loops T i.e., allowing the target to have more behaviors first, find an abstraction via T second, refine using Skolem as much as possible i.e., removing some infeasible behavior Sk 7
Prior Work big picture [LPAR 15] source target Two loops i.e., allowing the target to have more behaviors first, find an abstraction via T T second, refine using Skolem as much as possible i.e., removing some infeasible behavior Sk Drawback: No control over abstraction Only concrete simulations can be used to lift proofs Abstract simulations are not generally applicable 7
Lifting Proofs via Simulation [Pnueli et al. 00] [Namjoshi 03] Given programs S, T (~y ) is invariant of T (~y ) If T (~y ) simulates S(~x ) via (~x, ~y ) then 9~y (~x, ~y ) ^ (~y ) is an invariant of S(~x ) 8
Lifting Proofs via Simulation [Pnueli et al. 00] [Namjoshi 03] Given programs S, T (~y ) is invariant of T (~y ) If T (~y ) simulates S(~x ) via (~x, ~y ) then 9~y (~x, ~y ) ^ (~y ) is an invariant of S(~x ) But Concrete simulations are not needed It is enough to find an abstraction of T simulates S is safe with respect to (~y ) 8
Property Preserving Abstraction T Produced by mapping each CPG-edge by the invariant over the post-state 9
Our Solution ASSI + : Abstract Simulation Synthesis with Invariants forces the abstraction to preserve safety still goes to abstraction level when needed no Skolem-based refinement 10
Lifting Invariants Directly Given programs, S(~x ) T (~y ) (~y ) is invariant of T (~y ) simulates S(~x ) via then 9~y (~x, ~y ) ^ (~y ) is an invariant of S(~x ) (~x, ~y ) 11
Lifting Invariants Partially When delivered abstraction T (~y ) is too weak: i.e., abstraction T (~y ) does not preserve (~y ) but still S(~x ) T (~y ) S(~x ) thus, 9~y (~x, ~y ) ^ (~y ) is not an invariant of 12
Lifting Invariants Partially We propose weakening (~y ) =) 0 (~y ) 0 (~y ) T (~y ) S(~x ) such that is an invariant for then 9~y (~x, ~y ) ^ 0 (~y ) is an invariant of strengthening 9~y (~x, ~y ) ^ 0 (~y ) to become safe invariant of S(~x ) reducing the problem to Constraint Horn Solving When delivered abstraction T (~y ) is too weak: i.e., abstraction T (~y ) does not preserve (~y ) but still S(~x ) T (~y ) S(~x ) thus, 9~y (~x, ~y ) ^ (~y ) is not an invariant of 12
To recap ASSI + : Abstract Simulation Synthesis with Invariants forces the abstraction to preserve safety still goes to abstraction level when needed no Skolem-based refinement PDE Property Directed Equivalence exploits ASSI + and checks if the delivered abstraction is psi-safe skips verification if success (i.e., if the invariants are lifted completely) Verify 13 lifts the invariants partially via abstract simulation performs counter-example-guided weakening of invariants strengthens the invariants using Constraint Horn Solving
Evaluation ASSI + vs SimAbs Tools LLVM compiler + indvars + licm optimization passes UFO model checker (Z3/ PDR engine) to get proofs 115 Safe C programs from SVCOMP 13 psi-safe abstractions by SimAbs 39 psi-safe abstractions by ASSI in order of magnitude faster 14
Evaluation PDE vs UFO Tools LLVM compiler + indvars + licm optimization passes UFO model checker (Z3/ PDR engine) to get proofs, perform weakening/strengthening 115 Safe C programs from SVCOMP: 90: PDE outperformed UFO 15
Conclusion Incremental Verification Fully automated and exhaustive analysis of software versions SMT-based Unbounded Model Checking The first approach that combines using Reusable specifications Relational specifications Implemented and Evaluated ASSI + and PDE within Niagara framework Validation of non-trivial LLVM-optimizations 16
Thank you!