1 / 23

CS 294-8 Extended Static Checking cs.berkeley/~yelick/294

CS 294-8 Extended Static Checking http://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

peter-perkins
Download Presentation

CS 294-8 Extended Static Checking cs.berkeley/~yelick/294

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 294-8Extended Static Checkinghttp://www.cs.berkeley.edu/~yelick/294

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

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

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

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

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

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

  8. Edit/Prove/Debug Loop Annotated Program Verification Condition Generator Error message Theorem Prover “Sorry, can’t find any more errors” Post Processor

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

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

  11. Procedures in ESC • Procedure and methods: • Modifies: list of all variable that could be modified • Requires (precondition) • Ensures (postcondition)

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

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

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

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

  16. 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?

  17. 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)

  18. 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^

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

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

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

  22. 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?

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

More Related