A Specification Logic for Exceptions and Beyond

1. A Specification Logic for Exceptions and Beyond Cristina David CristianGherghina National University of Singapore

2. 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

3. 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

4. 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

5. 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

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

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

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

9. 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 • Precise explicit effect • Currently, difficult to specify • Strong guarantee • The operation either succeeds or has no effect if an exception is raised • More difficult to implement • No throw guarantee • Never throw an exception

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

11. 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

12. 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

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

14. Source Language SrcLang • 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

15. 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

16. Source Lang Core Lang …

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

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

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

20. Verification Example try{ … }catch(over_exc@fv#v) brk_l#() {true & flow=norm} over_exc <: num_exc {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)} {v::over_exc() & x>0 & p=0 & flow=norm & fv=over_exc} {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) 9v,fv¢ (x>0 & res=3 & v=x& flow=exception & fv=exception)}

21. Verification Example try{ … }catch(over_exc@fv#v) … 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)} {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) Ç 9v,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)}

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

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

24. Related Work • SPEC# • K. Rustanet al. “Exception safety for C#” • KEY project • B. Beckertet al. “Verification of Object-Oriented Software: The KeY Approach” • Type systems • M. Blumeet al. “Exception handlers as extensible cases” • CSP

25. Thank you!

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