A Specification Logic for Exceptions and Beyond Cristina

A Specification Logic for Exceptions and Beyond Cristina David Cristian Gherghina National University of Singapore

Context (Roy Maxion et al. “Improving software robustness with dependability cases”) Exception failures ◦ Up to 2/3 of system crashes ◦ 50% of system security vulnerabilities Need for ◦ Specifying behavior even in the presence of exceptions ◦ Precisely defined yet flexible exception safety guarantees ◦ Tools to enforce such specifications 2

Contributions A specification logic for all control flow types An improvement of the classical exception safety guarantees A verification system for a Java-like language 3

Specification Logic Current specification logics fail to track control flow types We propose Explicit tracking of control flow information in the specification logic An unified view of all control flow types 4

Specification Logic An unified view of the control flow: Unify both normal and abnormal control flows Unify both static and dynamic control flows • static flow: break, continue, return • dynamic flow: try-catch, raise 5

Unified control flow hierarchy can be caught dynamic control flows due to exceptions static control flows cannot be caught dynamic static normal execution 6

Specification Logic The specification formulae are enriched separation logic formulae They allow for capturing the states for both normal and exceptional executions 7

Specification Formulae ◦ ¯ captures constraints on flow variables ◦ ¿ captures the current flow ◦ Current flow values can be: Exact flow types Subtypes and type differences 8

Exception Safety Guarantees (Stroustrup: Exception Safety: Concepts and Techniques) ◦ No-leak guarantee Exceptions leave the operands in well-defined states Every acquired resources is released ◦ Basic guarantee The class invariants are always maintained Very forgiving with the programmer ◦◦ Relaxed strong guarantee Strong guarantee ◦ ◦ Precise explicit effect The operation either succeeds or has no effect if an exception is raised Currently, to specify More difficult to implement ◦ No throw guarantee ◦ Never throw an exception 9

No Throw Guarantee E. g. a swap function The postcondition specifies that no exceptional flow can escape the swap method 10

Strong Guarantee An operation leaves its operands in well-defined states ensures that every acquired resource is released class invariants are maintained succeeds, or has no effects when an exception occurs 11

Relaxed Strong Guarantee An operation leaves its operands in well-defined states ensures that every acquired resource is released eventually class invariants are maintained succeeds, or has a precisely known effect when an exception occurs 12

Verification System Translates Source Language programs into Core Language programs ◦ (C. David et al. ”Translation and optimization for a core calculus with exceptions” PEPM 09) Performs forward verification by computing the strongest post condition Proven to be sound 13

Source Language Src. Lang • Supports constructs challenging from the point of how control flow is transferred • finally construct • multi-return function call • try catch with multiple handlers • break and continue statements 14

Core Language • As small as a corresponding one without exceptions • Supports the translation of challenging constructs from the source language • Easier to analyze than the source language 15

Source Lang Core Lang … 16

Important constructs of the Core Lang • Flow and value: ft#v • normal flow: norm#v • exceptional flow: ty(v)#v • Try-catch construct: try e 1 catch((c@fv)#v) e 2 • captures both exceptional and normal control flow the thrown value variable capturing the control flow type (fv<: c) 17

Verification Example try { if (x>0) compute(x, p) else ret#p }catch(over_exc@fv#v) brk_l#() 18

Verification Example {true & flow=norm} if (x>0) {x>0 & flow=norm} compute(x, p); {(x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res: : num_exc() & x>0 & p=0 & flow=num_exc)} else {x≤ 0 & flow = norm} ret#p {x≤ 0 & res=p & flow = ret} { (x≤ 0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res: : num_exc() & x>0 & p=0 & flow=num_exc)} 19

Verification Example {true & flow=norm} over_exc <: num_exc try{ {true & flow=norm} … { (x≤ 0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res: : num_exc() & x>0 & p=0 & flow=num_exc)} }catch(over_exc@fv#v) {v: : over_exc() & x>0 & p=0 & flow=norm & fv=over_exc} brk_l#() {v: : over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc} {(x≤ 0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) 9 v, fv ¢ (x>0 & res=3 & v=x& flow=exception & fv=exception)} 20

Verification Example try{ … over_exc <: num_exc { (x≤ 0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res: : num_exc() & x>0 & p=0 & flow=num_exc)} }catch(over_exc@fv#v) … {v: : over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc} {(x≤ 0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç 9 v, fv ¢ (v: : over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc) Ç (res: : num_exc() & x>0 & p=0 & flow=num_exc – over_exc)} 21

Try-catch and “#” Verification Rules the “caught” states the “uncaught” states 22

Experimental Results Successfully verified test examples from: ◦ Ke. Y project, exercising specific features ◦ SPEC benchmarks, broad range exception handling 23

Related Work SPEC# ◦ K. Rustan et al. “Exception safety for C#” KEY project ◦ B. Beckert et al. “Verification of Object. Oriented Software: The Ke. Y Approach” Type systems ◦ M. Blume et al. “Exception handlers as extensible cases” CSP 24

Thank you! 25

Multi-return function call • Explicitly captures the choice of the return point, based on the control flow caught after the evaluation 26