Extended Static Checking Extended Static Checking Greg Nelson MJ - PDF document

Authors Authors Author Defn. Num.* K. Rustan M. Leino MJS 13 Extended Static Checking Extended Static Checking Greg Nelson MJ 6 James B. Saxe MJ 6 Wolfram Schulte S 3 David Detlefs M 2 Raymie Stata J 2 Mike Barnett S 2 Michael Clarkson Cormac Flanagan J 1 * w.r.t. bibliography CS 711 at end of talk Mark Lillibridge J 1 Robert DeLine 1 November 15, 2005 M ESC/Modula-3 Manuel Fähndrich 1 J ESC/Java Silvija Seres 1 S Spec# Clarkson: Extended Static Checking 2 Verification of Safety Properties Extended Static Checking (ESC) Verification of Safety Properties Extended Static Checking (ESC) • Purpose: finding bugs, not full verification • SRC project ca. 1995-2000 • Abstraction: predicates • Nine out of the last twelve seminar papers: – Encode program and property into (first-order) – ESP, buffer overflows, race detection, predicate(s) ownership types, pointer assertions – Truth of predicates implies program satisfies property • Approach so far: • Algorithm: theorem prover – Invoke prover on predicates – Define a clever abstraction – Use (clever) algorithm to verify property in the • Idea has been around since early 1970s abstraction Clarkson: Extended Static Checking 3 Clarkson: Extended Static Checking 4 Extended Static Checking (ESC) Extended Static Checking (ESC) Overview Overview • Cons: • ESC/Java – Theorem prover is a blunt tool – Demo • It may need help from the user (interaction, annotations) • Spec# • It may diverge – Bug-finder, not full verifier • Data abstraction • “We aren’t proving that the program meets its full functional specification, only that it doesn’t crash” • “Without discipline, you can quickly slide into the black hole of full correctness verification.” • Pros: – General purpose – Conceptually elegant 5 6 Clarkson: Extended Static Checking Clarkson: Extended Static Checking 1

ESC/Java Design ESC/Java Demo ESC/Java Design ESC/Java Demo • Priority: useful – Check (statically) for runtime errors • Null dereference, buffer overrun, type cast, division by 0, etc. – Check for common synchronization errors • Race conditions and deadlocks – Check programmer-supplied specifications • Preconditions, postconditions, invariants – Be modular – Be automatic • Sacrifice soundness and completeness Actually ESC/Java2 Clarkson: Extended Static Checking 7 Clarkson: Extended Static Checking 8 ESC/Java Architecture ESC/Java Assertion Language ESC/Java Architecture ESC/Java Assertion Language Annotated Java Front End • Two primitives: – assume P AST – assert P GC Translator • Variables: GC for each routine – non_null VC Generator • Method specifications: VCs for each routine – requires P – ensures P Java semantics Theorem Prover – exsures (T t) P “Valid” or counterexample – pure Postprocessor Output to user – modifies V Clarkson: Extended Static Checking 9 Clarkson: Extended Static Checking 10 ESC Assertion Language ESC Assertion Language Translating Java to GCs Translating Java to GCs • Class declaration: • Target language is: – invariant P • Predicates: S ::= x = E | skip | raise | assert P | assume P – Any side-effect free Java expression | var x in S end | S ; S | S ! S | S [] S – \result | loop {inv P} S end | call m (E*) – \old(E) – \forall T V; E • Then loop and call are translated away – \exists T V; E • … 11 12 Clarkson: Extended Static Checking Clarkson: Extended Static Checking 2

Translating Java to GCs Using Theorem Prover Translating Java to GCs Using Theorem Prover • Effort to use must be low: • wlp and VCgen easy to define for remaining GCs – Fully automatic – wlp.S.R,X,Z – Counterexample generation – Goal is to show that assert never fails – Reasonably fast – Behaves like a type checker • Full translation takes 40 pages to document – Example: • Simplify (ESC/Modula-3, ESC/Java, Spec#) – Engineered to work well for the kinds of formulas that « t = (T) s; ¬ = assert (s = null ∨ typeof(s) <: T); VCgen produces t = s; – Performs heuristic search for satisfying assignment to ¬ VC – Labels predicates with program location to produce – typeof and <: are relations defined by background human-readable error messages predicate Clarkson: Extended Static Checking 13 Clarkson: Extended Static Checking 14 Sources of Unsoundness Sources of Unsoundness Sources of Unsoundness Sources of Unsoundness • Modifies lists not enforced • Finite unrolling of loops (default is 1.5) – Aliasing and subclassing make it impossible to write – Avoids need for programmers to supply invariants down an accurate modifies list anyway • Object invariants not universally enforced – But prover still assumes that modifies list is correct – Invariants should hold for all allocated objects at all • Overriding methods can change strengthen routine boundaries precondition – But checking would be – Similar to allowing covariant arguments • Too expensive: too many objects to check – Included so that a class can mention its fields when • Too strict: sometimes programmers temporarily violate overriding a specification inherited from an interface invariants • Multiple inheritance: super types’ specifications – So instead: not all enforced • At call sites, only check invariants for parameters • Arithmetic overflow, string semantics • Use heuristics to reduce set of invariants Clarkson: Extended Static Checking 15 Clarkson: Extended Static Checking 16 Sources of Unsoundness Sources of Unsoundness Sources of Incompleteness Sources of Incompleteness • Most Java errors and exceptions ignored • Simplify – NullPointer, IndexOutOfBounds, ClassCast, – Theory of arithmetic is undecidable: May ArrayStore, Arithmetic, NegativeArraySize are the abort attempted proof and report a only one checked counterexample to avoid potential infinite loop • Constructors that terminate abnormally can leak – No semantics for multiplication uninitialized objects – No support for induction • … • Java semantics not fully modeled – Floating–points, strings, exceptions, JDK, dynamic typing of arrays, integer overflow, reflection • … 17 18 Clarkson: Extended Static Checking Clarkson: Extended Static Checking 3

Spec# Spec# Soundness Spec# Spec# Soundness • MSR project: ESC for C# • Loops – Use abstract interpretation to synthesize invariant • Does not attempt to prove absence of • Modifies clauses unchecked exceptions – Checked statically • Major goal: recover soundness – Introduce mechanism to abstract over heap – “[The verifier] attempts to completely verify a • Overriding specifications program without missing errors; its ability to – No changes to preconditions allowed do so is bound to depend on the simplicity of • Multiple inheritance the specifications” – Disallow shared implementation of methods with differing preconditions • … Clarkson: Extended Static Checking 19 Clarkson: Extended Static Checking 20 Spec# Demo Evaluation (ESC/Java) Spec# Demo Evaluation (ESC/Java) • Annotating a program increases LOC by 10% • Annotation rate is 300-600 LOC/hour • Time to check a routine correlates with size of routine – Reasonable (0-50 LOC): 0-10 sec – Large (50-1000 LOC): up to 5 min deadline – About 3 hours to check 41KLOC in 2300 routines • These results are for their own front end • There seems to be no reported, thorough evaluation? Clarkson: Extended Static Checking 21 Clarkson: Extended Static Checking 22 Evaluation Evaluation Open Problems in ESC Open Problems in ESC • “The start-up cost [for a preexisting code • Reduce annotation burden (Houdini, base] is still too high” Daikon) • “[We] found about [6] errors…assessed as • Sound checking not having been worth 3 weeks to • Sound and complete logic for higher-order discover” functions • Temporary violation of invariants • Reasoning about machine arithmetic • Instructional use 23 24 Clarkson: Extended Static Checking Clarkson: Extended Static Checking 4

Pseudo- -Cornell Work on ESC Cornell Work on ESC Extensible Architecture Pseudo Extensible Architecture • Yanling Wang, ESC for Cyclone: – Safety policies supplied by code consumer BDD-solver rather than producer Owl Simplify – Pluggable theorem provers ESC Cyclone Prover SAT-solver Clarkson: Extended Static Checking 25 Clarkson: Extended Static Checking 26 Conclusion Bibliography Conclusion Bibliography • Extended static checking • Extended static checking for Java. • The Spec# programming system: An overview. – Find bugs in programs • ESC/Java user’s manual. – User-supplied predicates as annotations • Data abstraction and information hiding. – Theorem prover as backend • Verification of object-oriented programs with invariants. • Applications of extended static checking. • Extended static checking: A ten-year perspective. • Still searching for sweet spot between • Houdini, an annotation assistant for ESC/Java. soundness, usefulness, completeness • Static verification of dynamically detected program invariants: Integrating Daikon and ESC/Java. • Checking Java programs via guarded commands. • Wide-spread adoption requires reducing • ESC/Java quick reference. • Simplify: A theorem prover for program checking. annotation burden and improving safety • Exception safety for C# guarantees Clarkson: Extended Static Checking 27 Clarkson: Extended Static Checking 28 5