1 / 25

Regression-Verification

Regression-Verification. Benny Godlin Ofer Strichman Technion. The goal of Regression Verification. The goal: formally verify the equivalence of two similar programs . Pros: Does not require formal specification . Computationally easier than functional verification

loman
Download Presentation

Regression-Verification

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

Presentation Transcript


  1. Regression-Verification Benny Godlin Ofer Strichman Technion

  2. The goal of Regression Verification • The goal: formally verify the equivalenceoftwosimilar programs. • Pros: • Does not requireformal specification. • Computationally easier than functional verification • Ideally, the complexity should depend on the semanticdifference between the programs, and not on their size. • Cons: • Defines a weaker notion of correctness.

  3. Previous work • In the theorem-proving world (mostly @ ACL2 community): • Not dealing with realistic programs / realistic programming languages • Not utilizing the equivalence of most of the code for simplifying the computational challenge • Industrial / realistic programs: • Code free of: loops, recursion, dynamic-memory allocation • microcode @ Intel, • embedded code @ Feng & Hu, • symbolic simulation @ Matsumoto et al.

  4. Our notion of equivalence Partial equivalence • Executions of P1 and P2 on equal inputs • …which terminate, • result in equal outputs. • Undecidable

  5. Partial equivalence • Consider the call graphs: • … where A,Bhave: • same prototype • no loops • Prove partial equivalence of A, B • How shall we handle the recursion ? A B Side 1 Side 2

  6. Hoare’s Rule for Recursion LetAbe a recursive function. “… The solution... is simple and dramatic: to permit the use of the desired conclusion as a hypothesis in the proof of the body itself.” [H’71]

  7. Hoare’s Rule for Recursion // {p} A( . . . ) { . . . // {p} call A(. . .); // {q} . . . } // {q}

  8. //in[A] A( . . . ) { . . . //in[call A] call A(. . .); //out[call A] . . . } //out[A] Rule 1: Proving partial equivalence //in[B] B( . . . ) { . . . // in[call B] call B(. . .); //out[call B] . . . } //out[B] A B

  9. Q: How can a verification condition for the premise look like? A: Replace the recursive calls with calls to functions that over-approximateA, B,and are partially equivalent by construction Natural candidates: Uninterpreted Functions Rule 1: Proving partial equivalence

  10. Proving partial equivalence • Let A,B be recursive functions as defined earlier • Let AUF , BUFbe A,B, after replacing the recursive call with a call to (the same) uninterpreted function. • We can now rewrite the rule: The premise is Decidable

  11. a, b) y) x, z; g; Using (PART-EQ-1): example unsigned gcd1UF (unsigned a, unsigned b) { unsigned g; if (b == 0) g = a; else { a = a % b; g = gcd1(b, a); } return g; } unsigned gcd2UF (unsigned x, unsigned y) { unsigned z; z = x; if (y > 0) z = gcd2(y, z % y); } return z; } ? = U U Transitions: Tgcd1Tgcd2 Inputs: a,b x,y outputs: g z

  12. Rule 1: example Equal inputs Equal outputs

  13. Partial equivalence: Generalization • Assume: • no loops; • 1-1 mapping mapbetween the recursive functions of both sides • Mapped functions have the same prototype • Define: • For a function f, UF(f) is an uninterpreted function such that • f and UF(f) have the same prototype • (f,g) 2map , UF(f) = UF(g).

  14. Partial equivalence: Generalization • Definition: is called in A]

  15. = f f’ UF UF Notation: Call to UF g’ g = UF UF Partial equivalence: Example {(g,g’),(f,f’)} 2 map g’ g f f’ Side 2 Side 1 Need to prove:

  16. Notation: Call to UF Partial equivalence: Example {(g,g’),(f,f’)} 2 map g’ g f f’ Side 2 Side 1 Need to prove: = g f f’ g’ g’ g = f f’

  17. Partial equivalence: extensions • Find a subset S of the mapped pairs that intersect all cycles in both sides • Replace calls to S functions with calls to uninterpreted functions. • Inline the rest • Prove equivalence of S pairs. h’ S = {(g,g’)} g’ g f f’ X X Side 2 Side 1

  18. g’ g f f’ h’ g’ g f f’ Partial equivalence: extensions h’ S = {(g,g’)} S = {(g,g’),(f,f’)} g’ g f f’ X X X X Side 2 Side 1

  19. is called inA] Partial equivalence: extensions • Recall: S is a set of pairs of function • Let mS denote the set of functions that appear in an S pair. • Let

  20. Partial equivalence: bottom-up Connected SCCs are proved bottom-up • Abstract partially-equivalent functions with uninterpreted functions • Inline g g’ f f ’ h h’

  21. PART-EQ: Soundness • Proved soundness for a simple programming language (LPL) • Covers most features of modern imperative languages • …but does not allow • call by reference, and • address manipulation.

  22. What (PART-EQ) cannot prove... returns n + nondet() returns n + n -1 + nondet()

  23. What (PART-EQ) cannot prove... • Many of these problems can be solved with unrolling + function summaries when n == 1 : returns 1 returns 1 + nondet()

  24. Decomposition algorithm (with SCCs) Legend: Equivalent pair Equivalence undecided yet Could not prove equivalent Syntactically equivalent pair Equivalent if MSCC B: A: CBMC f1() f1’() f2’() f5’() f2() f5() U U U U U U f6’() f3() f4() f3’() f4’() f6() U U U U

More Related