cs 294-8 extended static checking cs.berkeley/~yelick/294

CS294, Yelick ESC, p1

CS 294-8Extended Static

Checkinghttp://www.cs.berkeley.edu/~yelick/294


Agenda• Intro and recap• Overview of ESC (M3 and Java)• Comparison and Discussion


Two Themes in Reliable Software

• Limit scope of errors:– Prevent buggy/malicious app from doing

harm to others– Both direct (access to data) and indirect

(hogging resources) are important – The OS may be viewed a special:

• the “trusted arbiter” of limited resources

• Make the program itself run correctly– Adhere to some reasonable programming

discipline– Need to specify the discipline


Dealing with Buggy Software• Dynamic approaches

– Restrict access in HW or OS (kernel)– Software Fault Isolation– Checked exceptions and assertions– Virtual machines (e.g., JVM)

• Static approaches– Type checking– Verification– Restricted languages (avoid bugs)


Recap of Engler Talk

• How general was the approach?• How useful was it? • What about

soundness/completeness? • How could they find bugs in the Flash

code that a “verification” missed?• What is the right measure of success

for this kind of work? # bugs in popular code? Others?


Useful Classes of Rules• Never/always do X• Never/always do X before/after Y• In situation X, do/don’t perform Y

– Use locks; rollback state if failure

• Plus some “optimization-related”– Do X rather than Y– In situation Z, do X rather than Y

• How powerful is the language– For X, Y, Z expressions– Never/always/when and before/after control


Extended Static Checking• Similar goals to the MC work

– Check certain properties of programs– Not full verification

• Differences– Requires specifications rather than state

machine– Uses a theorem prover engine– Emphasis: control vs. abstraction– Languages: C vs. M3&Java


Edit/Prove/Debug Loop

Annotated Program

Verification Condition Generator

Theorem Prover

Error messag

e

“Sorry, can’t find any more

errors”

Post Processor


Default Errors in ESC• ESC acts like a power lint; it

checks:– Array bounds errors– Subrange errors– Null derefs– Narrowing type cast error– Missing returns– Exceptions not declared– Divide or mod by zero


ESC Specification Language• Programmer can add

specifications: – Procedures and methods– Abstraction– Concurrency– Invariants: loop, module, assertion

• ESC/Java allows for Java expressions in writing annotations


Procedures in ESC• Procedure and methods:

– Modifies: list of all variable that could be modified

– Requires (precondition)– Ensures (postcondition)


ESC/Java Syntax• Annotations are Java comments with

“@”, I.e., /*@ … */• 4 categories of annotations (pragmas)

– Lexical: where comments are allowed– Statement: where statements are allowed– Declaration: where declaration of class

and interface members are allowed– Modifier: within declarations


ESC/Java Pragmas• Requires E; assume E in body of method

and warn if can’t be proven at call sites• Modifies S; will assume calls only modify

these fields (does not check body)• Ensures E; assumes true after calls, and

proves for body• Assume E; assume E is true and ignore

branches where it is false• Assert E; issue a warning if E cannot be

proved • Nowarn L; turn off these warnings


Concurrency in ESC• ESC provides support for concurrent

programs:– Accessing protected variables without a lock– Acquiring locks out of order (for deadlock

avoidance)

• The programmer needs to specify– which variables are protected and – what order locks should be acquired

• Specified using general axiom facility– <* SPEC AXIOM (ALL [v: VBT.T] v < v.parent)

*>– Where “<“ denote lock acquisition order


Concurrency in ESC• Note that this may be more restrictive

than necessary, but is reasonable (?) practice.– Having a global lock acquisition order– Protecting a shared variable by a fixed lock

• Example:INTERFACE Rd;…TYPE T <: MUTEX;<* SPEC GetChar(rd) MODIFIES state[rd] REQUIRES valid[rd] AND sup(LL) < rd *>


Concurrency in ESC and MC• ESC and MC check properties of

concurrent programs, but does not check the concurrency directly.– ESC analyzes locks, MC interrupts– Neither analyze thread creation (e.g., to see

if there is real concurrency)

• Some of the more interesting properties (and bugs) come from currency

• Are there other common bugs one should detect?


Abstractions in ESC• ESC takes on global analysis and

thus abstraction as a primary focus. • Problem: specifications need to

describe variable modifications that are not in scope

• Solution: Use abstract variables in the specification. May have axioms on those variables (as in SPEC)


Data Abstraction in ESC• Downward closure

– Modifying an abstract variable implies license to modify concrete ones

• Lack of soundness– Need to link modifications of concrete

and abstract variables

• Depends maps DEPENDS Rd.state[rd: Rd.T] ON rd.st, rd.lo, rd.cur, rd.hi, rd.buff, rd.buff^


Comparisons to MC• Could everything done in MC framework

be done in ESC? Consider X after Y– Make Y’s spec ensure some property “P”

• E.g., interrupt = off

– Make X’s spec ensure ~P• E.g., interrupt = on

– Give all other procedures• Requires: interrupt on• Ensures: interrupt on

• Last point is key to simplicity: property enforced globally without adding specs everywhere


Comparison: ESC and MC• Choice of language is critical

– Modula 3 and Java, vs.– C

• Differences in – Popularity– Classes of errors that arise

• C is the easy case


Comparison: ESC and Java• Difference in background of work

– ESC comes from basic principles• Theorem proving, verification

– MC comes from systems programming• How was Exokernel written? What are

good rules to follow in writing systems?

• Related difference– Effort on the tool vs. effort on the

examples


Thoughts for Thursday• Larus will be talking about an

alternate programming style for servers– Events vs. threads– Related to Telegraph, Ninja, others?

• What programming problems likely to arise in this style?

• How could checkers help?


Administrivia• Jim Larus speaking Thursday

– Draft paper online

• Final projects: – Send mail to schedule meeting with me

• Next week:– Tuesday ?– Thursday: Kar and (the other) Hellerstein--

completely different approach to system reliability– Following Tuesday: guest lecture by Aaron Brown on

benchmarks; related to Kar and Hellerstein work.– Still to come: Gray, Lamport, and Liskov

cs 294-8 extended static checking cs.berkeley/~yelick/294

Documents