1 / 35

Lecture 17

Lecture 17. Model-based Verification and Static Analysis - Some slides from Ranjit Jhala’s talk and MOPS paper. Roadmap for Today . Verification and model checking: intro A case study: MOPS Static analysis. Verification . Verification: verifying the correctness of computer systems

tyrone
Download Presentation

Lecture 17

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. Lecture 17 Model-based Verification and Static Analysis - Some slides from RanjitJhala’s talk and MOPS paper

  2. Roadmap for Today • Verification and model checking: intro • A case study: MOPS • Static analysis

  3. Verification • Verification: verifying the correctness of computer systems • hardware, software or combination • It is most obvious in • safety-critical systems • commercially critical • mission critical

  4. Verification and Validation in the modeling process

  5. Verification parts • Formal Verification techniques consist of three parts: • Models for systems • Models for property • A verification method

  6. Classification • Approaches to verification can be classified in several ways: • Proof-based (find proof/deduction) vs. model-based (find counter example) • Degree of automation • Full- vs. property- verification • Intended domain of application • hardware-software, sequential-concurrent, reactive- (os, embedded system) terminating, …

  7. Model-Based Development and Verification

  8. Does Model-Based Development/Verification Scale? Airbus A380 Systems Developed Using MBD • Flight Control • Auto Pilot • Fight Warning • Cockpit Display • Fuel Management • Landing Gear • Braking • Steering • Anti-Icing • Electrical Load Management Length 239 ft 6 in Wingspan 261 ft 10 in Maximum Takeoff Weight 1,235,000 lbs Passengers Up to 840 Range 9,383 miles

  9. Example – ADGS-2100 Adaptive Display & Guidance System Further Reference: http://shemesh.larc.nasa.gov/fm/papers/ADGS-2100WindowManagerAnalysis.pdf Requirement Drive the Maximum Number of Display Units Given the Available Graphics Processors Counterexample Found in 5 Seconds! 883 Subsystems 2.9 x 1052 Reachable States Checking 373 Properties Found Over 60 Errors

  10. Reduces Cost of Testing Clear Specifications Improves Communication Enables More Testing Eliminates Manual Coding Easy Validation Makes Model Primary Artifact Finds Errors Early Why Model Based Development/Verification? - reported by rockwellcollins Requirements Elicitation Reuse 15% 10% Autotest Modeling 5% 10% Autocode Simulation Automated Analysis 10% - 20% Cheaper Than Manual Analysis Finds the Really Hard Errors

  11. Model Checking Model checking is an automatic, model-based, property-verificationapproach Has been used in concurrent and reactive systems History: 1) first Hardware verifications (Intel, Motorola, IBM…); 2) Software model checking: early 90s, model checking protocols Advantage: automatic, considers all combinations of input and program states Disadvantage: state space exploration (10100 – 10300States)

  12. Model Checking

  13. Model Checking Process Modeling: design/code to formalism – can be automatic • Finite state machine • Pushdown automata • Other Mathematical descriptions Specification – mostly manual • temporal logic (CTL- computational tree logic, LTL- linear tree logic) • finite state machine • UML can be translated to FSM Verification: automatic, iteratively search • SMV, SPIN

  14. Example: Double Locking An attempt to re-acquire an acquired lock or release a released lock will cause a deadlock.” Calls to lock and unlock must alternate.

  15. Modeling Check to Find Double Locking

  16. What a Program Really is

  17. The Safety Verification Problem

  18. Model Checking: Analyze Abstraction • Analyze finite graph Over Approximate: No false negatives Problem Spurious counterexamples

  19. One Solution: Iterative Refinement

  20. A case study You will learn: • How to make verification practical? • How to model properties • The power of model checking in terms of improving code qualities • Real challenges of current model checking

  21. A case study: MOPSMOdel checking Programs for Security properties • Model checking for security properties – developed in 2002, Berkley • Practical aspect of software modeling checking • Model security properties, check against software • Checked entire Linux and found hundreds of bugs • Privilege issues • Memory bugs • Verifying untrusted data • Tools and document available: http://www.cs.berkeley.edu/~daw/mops/

  22. Case study: the problem • Full software verification is totally impractical? What might be the important properties to verify • Security properties, e.g., unintentionally violate implicit usage rules of APIs • Models for these rules are missing, especially for legacy code

  23. Techniques to build FSMs: Example Rules An FSA illustrating Property 2 (chroot() must always be immediately followed by chdir()) and a program violating it

  24. Example Rules An FSA illustrating Property 2 (stat(f) must not be followed by open(f)) and a program violating it.

  25. Build a Complex Model from Simpler Ones User applications must not run with root privilege” When execvis called, must have suid!= 0

  26. Complex Models A model of process privilege in Linux 2.4.17, this time capturing all of the ruid, euid, suid, effective and permitted capabilities.

  27. Check Property Against Code to Find problems

  28. Potential Imprecision

  29. How this Model Check Runs to Find Property Violations • mops cc: a parser that takes a file containing C source code and generates a Control Flow Graph(CFG) • mops ld: a linker that takes a set of CFG files and merges them into a single CFG file, resolving cross references of external functions and variables • mops check: the model checker that takes a CFG and an FSA and decides if the program may violate the security property in the FSA

  30. Case study: Summery • Advantage: model checking is path-sensitive • Potential imprecision source: • Model of the code is not equivalent to code, thus have imprecisions • Focus mostly on control not data

  31. Case study: Summery • How to make verification practical - a light weight verification • Check application-independent properties • Reduce specification costs through reuse • Support only a subclass of properties • Temporal safety properties: i.e., “ordering” • Exploit advances in model checking • Analyze control flow; ignore data flow • Be conservative: warn when unsure

  32. Exercise: build your rules A temporal safety property that encodes correct usage of the stdio file output library, including open/close/print

  33. Simulate a Model Checker to Find an Error Path

  34. Users and Designers of the model checking tools • Users of model checking tools: • Knowing the available tools: wiki List_of_model_checking_tools • Model properties into FSAs • Designers of model checkers: • Scalability challenges of model checkers • Automatic building models from design or code

  35. Wild & Crazy Ideas The role of research on software industries? • Do we need to introduce research ideas? • What we should introduce? • How we should introduce? From individual software developers point of view and from manager point of the view?

More Related