Sym Diff A differential program verifier Shuvendu Lahiri

  • Slides: 18
Download presentation
Sym. Diff: A differential program verifier Shuvendu Lahiri Research in Software Engineering (Ri. SE),

Sym. Diff: A differential program verifier Shuvendu Lahiri Research in Software Engineering (Ri. SE), Microsoft Research, Redmond, WA USA Workshop on Program Equivalence (April 2016)

What is Sym. Diff? • A platform for Leveraging and extending program verification to

What is Sym. Diff? • A platform for Leveraging and extending program verification to reason about “program differences” http: //research. microsoft. com/symdiff • Contributors • C. Hawblitzel, K. Mc. Millan, O. Strichman, Z. Rakamaric, S. He, • Interns: R. Sharma, M. Kawaguchi, H. Rebelo, R. Sinha, N. Partush, A. Gyori, … 2

Differential verification • Verifying properties of program differences • instead of the program itself

Differential verification • Verifying properties of program differences • instead of the program itself Motivations • No specs! • Proving assertions statically is harder (program-specific invariants, environment modeling, . . ) Applications • Program evolution • Compilers (equivalence preserving, approximate) • Comparing independent implementations 3

Sym. Diff architecture Language agnostic: relies on translators from C/C#/Java/x 86 to Boogie (bpl)

Sym. Diff architecture Language agnostic: relies on translators from C/C#/Java/x 86 to Boogie (bpl) P 1. bpl Product P 1 P 2. bpl Invariant inference P 2. bpl Diff spec P 1 P 2. bpl + invs Boogie program verifier+ Z 3 4

Language • Subset of Boogie (an intermediate verification language) [FMCO’ 05] • Commands •

Language • Subset of Boogie (an intermediate verification language) [FMCO’ 05] • Commands • x : = E • assert E • assume E • S; T • goto L 1, L 2, … Ln //non-deterministic jump to labels • call x, y : = Foo(e 1, e 2, . . ) //procedure call • Loops encoded as tail-recursive procedures • Can encode arrays using SMT theory of arrays (sel/upd) • x[e] sel(x, e) • x[y] : = z x : = upd(x, y, z) • x == y i. sel(x, i) == sel(y, i) 5

Modeling imperative programs/heaps • Various translators to Boogie: • C (HAVOC/SMACK/VCC/. . ), JAVA

Modeling imperative programs/heaps • Various translators to Boogie: • C (HAVOC/SMACK/VCC/. . ), JAVA (Joogie/. . ), C# (BCT) • E. g. , C Heap modeling in HAVOC [CHLQ, POPL’ 09] • A pointer is represented as an integer (int) • One heap map per scalar/pointer structure field and pointer type struct A { int f; int g; } x; Mem_A_f : [int]int Mem_A_g : [int]int • Simple example • C code x->f = 1; • Boogie Mem_A_f[x + Offset(f, A)] : = 1; 6

Differential specs: mutual summaries void F 1(int x 1){ if(x 1 < 100){ g

Differential specs: mutual summaries void F 1(int x 1){ if(x 1 < 100){ g 1 : = g 1 + x 1; F 1(x 1 + 1); }} void F 2(int x 2){ if(x 2 < 100){ g 2 : = g 2 + 2* x 2; F 2(x 2 + 1); }} MS(F 1, F 2): (x 1 = x 2 && g 1 <= g 2 && x 1 >= 0) ==> g 1’ <= g 2’ • A specification over the I/O vocabulary of (F 1, F 2) • Inputs: parameters, globals (g). • Outputs: return values, next state of globals (g’). [Hawblitzel, Kawaguchi, Lahiri, Rebelo CADE’ 13] 7

And now. . . verification. • 8

And now. . . verification. • 8

The product program f 1 Instrument calls proc f 1(x 1): r 1 modifies

The product program f 1 Instrument calls proc f 1(x 1): r 1 modifies g 1 { s 1; L 1: w 1 : = call h 1(e 1); t 1 } proc f 2(x 2): r 2 modifies g 2 { s 2; L 2: w 2 : = call h 2(e 2); t 2 } f 2 Instrument calls Replay, constrain, restore 9

Property of the product • Let p 1_p 2 be the product of (p

Property of the product • Let p 1_p 2 be the product of (p 1, p 2) Theorem: If S_p 1_p 2 is a summary of p 1_p 2, then it is a mutual summary of (p 1, p 2) • Aids in differential specification • A specification of the summary S_p 1_p 2 (e. g. partial equivalence) can be added as a postcondition of p 1_p 2 • More importantly, aids differential invariant inference • Can perform analysis on program P 1 x. P 2 to infer sound mutual summaries of (P 1, P 2) 10

Automatic differential invariant inference • 11

Automatic differential invariant inference • 11

Applications (1 / 3) • Equivalence checking • Compiler translation validation [CADE’ 13] •

Applications (1 / 3) • Equivalence checking • Compiler translation validation [CADE’ 13] • Cross-version compiler validation by comparing binaries [FSE’ 13] 12

Example (equivalence checking) f 1(n) { if (n == 0) { return 1; }

Example (equivalence checking) f 1(n) { if (n == 0) { return 1; } else { return n * f 1(n - 1); } } main(n) {return f 1(n); } f 2(n, a) { if (n == 0) { return a; } else { return f 2(n - 1, a * n); } } main(n) {return f 2(n, 1); } 13

Applications (2 / 3) • Differential assertion checking [FSE’ 13] 14

Applications (2 / 3) • Differential assertion checking [FSE’ 13] 14

Differential Assertion Checking (DAC) • Lahiri et al. FSE’ 13, • Joshi, Lahiri, Lal

Differential Assertion Checking (DAC) • Lahiri et al. FSE’ 13, • Joshi, Lahiri, Lal POPL’ 12 • Correctness Relative correctness • An input that can* satisfy p, cannot fail p’. • Note: asymmetric check • How? • Replace assert A with ok : = ok && A; • Write a mutual summary: MS(f 1, f 2) = ((i 1==i 2 && ok 1’) ==> ok 2’)) * Nondeterminism 15

DAC application: verifying bug fixes • Does a fix inadvertently introduce new bugs? •

DAC application: verifying bug fixes • Does a fix inadvertently introduce new bugs? • Verisec suite: “snippets of open source programs which contain buffer overflow vulnerabilities, and corresponding patched versions. ” • Relative memory safety (e. g. buffer overflow) checking • Snippets from apache, madwifi, sendmail etc. • Verified several bug fixes using automatic differential invariant inference 16

Example: DAC int main_buggy() { … fb : = 0; while(c 1=read()!=EOF) { fbuf[fb]

Example: DAC int main_buggy() { … fb : = 0; while(c 1=read()!=EOF) { fbuf[fb] = c 1; fb++; Buffer Overflow } … } int main_patched() { …Differential loop invariant: fb 2 fb 1 fb : = 0; while(c 1=read()!=EOF) { fbuf[fb] = c 1; fb++; if(fb >= MAX) fb = 0; } Can verify (relative) memory … safety automatically, without }manual preconditions 17

Applications (3/3) • Current research: • Verifying approximate transformations • Preserve assertions, termination and

Applications (3/3) • Current research: • Verifying approximate transformations • Preserve assertions, termination and accuracy • [w/ Rakamaric, He] • Semantic change impact analysis • Injecting change semantics into a dataflow-based taint analysis • [w/ Partush, Gyori] 18