COMS W4117
Compilers and Translators:
Software Verification Tools
Lecture 2: Introduction to Software Verification
September 6, 2007
Lecture Outline
- Review
- Software reliability
- Liveness vs. safety properties
- False positives vs. false negatives
- Examples of software bugs
- Approaches to software verification
- Representative static verification tools
- Reading assignment
1. Review
- Introductions
- Course overview
- Textbooks and references
- Course requirements and grading
- What is reliable software?
- How can we make reliable software
- Reading
2. Software Reliability
- Reliability vs. availability
- Reliability is mean time between failures (MTBF).
- Availability is MTBF/(MTBF + MTTR) where MTTR is the mean time to restore.
- Five-nines availability means at most 5 minutes 15 seconds of down time in a year.
- Theoretical approaches to reliability
- In 1948 Claude Shannon showed how we can get reliable communication over
a noise channel using error-detecting and -correcting codes.
- In 1956 John von Neumann showed how we can get more reliable hardware
out of unreliable components by using redundacy.
- Why hasn't a similar paper been written for software: how can we get
reliable software from unreliable programmers?
- Note that N-version programming doesn't work since programmers' software
errors are correlated, even if they don't communicate with one another.
- The probabilistically correct proof (PCP) theorem *might* show the way.
Wikipedia: PCP Theorem
- Industrial approaches to more reliable software
- Better processes
- Better tools
3. Liveness vs. Safety Properties
- A liveness property asserts that a program eventually enters a desirable
state, that is, something good eventually happens.
Owicki and Lamport, Proving Liveness Properties of Concurrent Programs
- The light will turn green.
- The program will terminate.
- A safety property asserts that something bad never happens, that is,
the program never enters an unacceptable state.
- The nuclear power plant will never blow up.
- If a system fails to satisfy a safety property, then there exists a
finite execution path that reveals this fact.
4. False Positives vs. False Negatives
- A false positive is a test result that is erroneously positive when the situation
is normal.
- A false positive is a false alarm.
- For example, a legitimate email is incorrectly marked as spam.
- A false negative is a test result that shows no abnormality
although the condition is actually present.
- A false negative is the opposite of a false positive.
- For example, a spam email is incorrectly marked as legitimate.
- In software verification we want to minimize the number of false positives
and false negatives. Too many false positives can sink a software verification
tool.
5. Examples of Software Bugs
- A software bug (or just "bug") is an error in a computer program that prevents
it from behaving as intended (e.g., producing an incorrect result).
Wikipedia: Software Bug
- Examples of common types of bugs
- Divide by zero
- NULL pointer dereference
- Infinite loops
- Arithmetic overflow or underflow
- Exceeding array bounds
- Using an uninitialized variable
- Accessing memory not owned
- Memory leak
- Stack overflow or underflow
- Buffer overflow
- Deadlock
- Off-by-one error
- Race condition
- Loss of precision in type conversion
- Failure to meet system requirements
- Trustworthiness of software systems has become an acute issue.
6. Approaches to Software Verification
- Testing
- Code reviews
- Static verification tools
- These tools examine the source code without running it.
- Pro: thorough analysis -- analysis covers all of the source code
- Con: can generate false positives and false negatives
- Dynamic verification tools
- These tools examine the source code while the object code is running by
intercepting calls to support routines and substituting calls to error-checking
versions of the same routines.
- Pro: False positives are rare.
- Con: Coverage is limited to test scripts.
- Fuzzing: bombarding an application with random data during testing
- Model checkers
- Simulators
7. Representative Static Verification Tools
- ASTRIE: A static analyzer for large safety-critical software
- Cousot and Cousot et al:
The ASTRIE Static Analyzer
- In Nov. 2003, ASTRIE was able to prove completely automatically the absence
of any run-time errors in the primary flight-control software of the Airbus A340
fly-by-wire system, a program of 132,000 lines of C.
- FindBugs: A static analyzer for finding bugs in Java code
-
Microsoft program analysis tools
- ESP: Error detection via scalable program analysis
- espX: Annotation-based software validation
- PREfast: Intra-procedural source code analysis
- PREfix: Scalable, path sensitive source code analysis
- PREsharp: Defect detection tool for C#
- PSE: A tool for post-mortem analysis of program failures
-
Saturn: Precise and scalable software analysis of multi-million line
software systems
- Summary based -- the analysis of a function is a summary of its behavior
- Uses boolean satisfiability as the primary constraint language
- Program analyses are expressed in a logic programming language
- SLAM: Checking whether a program obeys API usage rules
-
The Spec# programming system
- Spec# is
- a programming language that extends C# with specification constructs
- a compiler that emits run-time checks for specification constructs
- a static verifier that modularly proves the run-time checks never fail
- An environment with base class library contracts and a Visual Studio extension
8. Reading Assignment
- Check out one or more of the static analysis tools mentioned above
aho@cs.columbia.edu