[PPT]Computing Power (in Apollo Control Computer Units)evans/talks/dependable551-f03.ppt · Web...
Transcript of [PPT]Computing Power (in Apollo Control Computer Units)evans/talks/dependable551-f03.ppt · Web...
David Evanshttp://www.cs.virginia.edu/evans
CS551/651: Dependable ComputingUniversity of VirginiaComputer Science
Static Analysis
25 September 2003 Dependable Computing Fall 2003 2
Menu
• Validation• Why Static Analysis is Impossible• Why we do it anyway• Static Analysis Tools
25 September 2003 Dependable Computing Fall 2003 5
Dictionary Definition
val·i·date 1. To declare or make legally valid. 2. To mark with an indication of official
sanction. 3. To establish the soundness of;
corroborate.
Can we do any of these with software?
25 September 2003 Dependable Computing Fall 2003 6
Sun’s Java License5. LIMITATION OF LIABILITY. TO THE EXTENT
NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. …
25 September 2003 Dependable Computing Fall 2003 7
Java’s License2. RESTRICTIONS. … Unless enforcement is
prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun disclaims any express or implied warranty of fitness for such uses.
25 September 2003 Dependable Computing Fall 2003 8
Software Validation
• Process designed to increase our confidence that a program works as intended
• For complex programs, cannot often make guarantees
• This is why typical software licenses don’t make any claims about their program working
25 September 2003 Dependable Computing Fall 2003 9
Increasing Confidence• Testing
– Run the program on set of inputs and check the results
• Verification– Argue formally or informally that the program
always works as intended• Analysis
– Poor programmer’s verification: examine the source code to increase confidence that it works as intended
25 September 2003 Dependable Computing Fall 2003 10
Testing
• If all the test cases produce the correct results, you know that a particular execution of the program on each of the test cases produced the correct result
• Concluding that this means the program is correct is like concluding there are no fish in the river because you didn’t catch one!
• What makes a good test case?
25 September 2003 Dependable Computing Fall 2003 11
Analysis
• Make claims about all possible paths by examining the program code directly, not executing it
• Use formal semantics of programming language to know what things mean
• Use formal specifications of procedures to know that they do
25 September 2003 Dependable Computing Fall 2003 12
Example Software Properties
• Does what the customer wants• Does what the programmer intends• Doesn’t do anything dangerous• Always eventually halts• Never dereferences null• Always opens a file before writing to it• Never prints “3”
25 September 2003 Dependable Computing Fall 2003 13
Hopelessness of Analysis
It is impossible to correctly decide if any interesting property is true for an arbitrary program!
25 September 2003 Dependable Computing Fall 2003 14
Halting Problem
• Can we write a program that takes any program as input and returns true if that program always halts, and returns false if it sometimes doesn’t halt.
bool alwaysHalts (Program p) { … // returns true iff p will halt}
25 September 2003 Dependable Computing Fall 2003 15
Informal Proof• Suppose we could write alwaysHalts.• Proof by contradiction:
bool contradictHalts () { if (alwaysHalts (contradictHalts)) { while (true) ; // loop forever } else { return false; }} What is alwaysHalts (contradictHalts) ?
25 September 2003 Dependable Computing Fall 2003 16
Hopelessness of Analysis
• But this means, we can’t write a program that decides any other interesting property either:
bool dereferencesNull (Program p) // EFFECTS: Returns true if p ever dereferences null, // false otherwise.
bool alwaysHalts (Program p) { return (derefencesNull (new Program (“p (); *NULL;”)));}
25 September 2003 Dependable Computing Fall 2003 18
Compromises• Only work for some programs• Accept unsoundness and incompleteness• False positives: sometimes an analysis tool will
report warnings for a program, when the program is actually okay (incompleteness – can’t prove a property that is true)
• False negatives: sometimes an analysis tool will report no warnings for a program, even when the program violates properties it checks (unsoundness – proves a property that is not true)
25 September 2003 Dependable Computing Fall 2003 19
Properties to Analyze• Generic Properties
– Dangerous Code• C: memory leaks, dereferencing null, type
mismatches, undefined behavior, etc.• Concurrency: race conditions, deadlocks
– Don’t need a specification (but it may help across procedure boundaries)
• Application-Specific Properties– Need some way of describing the properties
we want
25 September 2003 Dependable Computing Fall 2003 20
SplintAnnotation-assisted lightweight analysis tool for C
25 September 2003 Dependable Computing Fall 2003 21
A Gross Oversimplification
Effort RequiredLow Unfathomable
Formal Verifiers
Bug
s D
etec
ted
none
all
Compilers
SplintSplint
25 September 2003 Dependable Computing Fall 2003 22
(Almost) Everyone Likes Types
• Easy to Understand• Easy to Use• Quickly Detect Many Programming
Errors• Useful Documentation• …even though they are lots of work!
– 1/4 of text of typical C program is for types
25 September 2003 Dependable Computing Fall 2003 23
Limitations of Standard Types
Type of reference never changes
State changes along program paths
Language defines checking rules
System or programmer defines checking rules
One type per reference
Many attributes per reference
25 September 2003 Dependable Computing Fall 2003 24
Type of reference never changes
State changes along program paths
Language defines checking rules
System or programmer defines checking rules
One type per reference
Many attributes per reference
AttributesLimitations of
Standard Types
25 September 2003 Dependable Computing Fall 2003 25
Approach• Programmers add annotations (formal
specifications)– Simple and precise– Describe programmers intent:
• Types, memory management, data hiding, aliasing, modification, null-ity, buffer sizes, security, etc.
• Splint detects inconsistencies between annotations and code– Simple (fast!) dataflow analyses
25 September 2003 Dependable Computing Fall 2003 26
Sample Annotation: only
• Reference (return value) owns storage• No other persistent (non-local) references to it• Implies obligation to transfer ownership• Transfer ownership by:
– Assigning it to an external only reference– Return it as an only result– Pass it as an only parameter: e.g.,
extern void free (only void *);
extern only char *gptr;extern only out null void *malloc (int);
25 September 2003 Dependable Computing Fall 2003 27
Example
1 int dummy (void) {2 int *ip= (int *) malloc (sizeof (int));3 *ip = 3;4 return *ip;5 }
extern only null void *malloc (int); in library
Splint output:dummy.c:3:4: Dereference of possibly null pointer ip: *ip dummy.c:2:13: Storage ip may become nulldummy.c:4:14: Fresh storage ip not released before return
dummy.c:2:43: Fresh storage ip allocated
25 September 2003 Dependable Computing Fall 2003 28
Security Flaws
Malformed Input16%
Resource Leaks
6%
Format Bugs6%
Buffer Overflows
19%
Access16%
Pathnames10%
Symbolic Links11%
Other16%
Reported flaws in Common Vulnerabilities and Exposures Database, Jan-Sep 2001.[Evans & Larochelle, IEEE Software, Jan 2002.]
190 VulnerabilitiesOnly 4 having to do with crypto108 of them could have been
detected with simple static analyses!
25 September 2003 Dependable Computing Fall 2003 29
Example: Buffer OverflowsDavid Larochelle
• Most commonly exploited security vulnerability– 1988 Internet Worm– Still the most common attack
• Code Red exploited buffer overflow in IIS• >50% of CERT advisories, 23% of CVE entries in 2001
• Attributes describe sizes of allocated buffers• Heuristics for analyzing loops• Found several known and unknown buffer
overflow vulnerabilities in wu-ftpd
25 September 2003 Dependable Computing Fall 2003 30
Defining Properties to Check
• Many properties can be described in terms of state attributes– A file is open or closed
• fopen: returns an open file• fclose: open closed• fgets, etc. require open files
– Reading/writing – must reset between certain operations
25 September 2003 Dependable Computing Fall 2003 31
Defining Opennessattribute openness context reference FILE * oneof closed, open annotations open ==> open closed ==> closed transfers open as closed ==> error closed as open ==> error merge open + closed ==> error losereference open ==> error "file not closed" defaults reference ==> openend
Cannot abandon FILE in open state
Object cannot be openon one path, closed on another
25 September 2003 Dependable Computing Fall 2003 32
Specifying I/O Functions
/*@open@*/ FILE *fopen (const char *filename, const char *mode);
int fclose (/*@open@*/ FILE *stream) /*@ensures closed stream@*/ ;
char *fgets (char *s, int n, /*@open@*/ FILE *stream);
25 September 2003 Dependable Computing Fall 2003 33
Reading, ‘Riting, ‘Rithmeticattribute rwness context reference FILE * oneof rwnone, rwread, rwwrite, rweither annotations read ==> rwread write ==> rwwrite rweither ==> rweither rwnone ==> rwnone merge rwread + rwwrite ==> rwnone rwnone + * ==> rwnone rweither + rwread ==> rwread rweither + rwwrite ==> rwwrite transfers rwread as rwwrite ==> error "Must reset file between read and write." rwwrite as rwread ==> error "Must reset file between write and read." rwnone as rwread ==> error "File in unreadable state." rwnone as rwwrite ==> error "File in unwritable state." rweither as rwwrite ==> rwwrite rweither as rwread ==> rwread defaults
reference ==> rweitherend
25 September 2003 Dependable Computing Fall 2003 34
Reading, ‘Righting/*@rweither@*/ FILE *fopen (const char *filename, const char *mode) ;
int fgetc (/*@read@*/ FILE *f) ;int fputc (int, /*@write@*/ FILE *f) ;
/* fseek resets the rw state of a stream */int fseek (/*@rweither@*/ FILE *stream, long int offset, int whence) /*@ensures rweither stream@*/ ;
25 September 2003 Dependable Computing Fall 2003 35
Checking
• Simple dataflow analysis• Intraprocedural – except uses annotations
to alter state around procedure calls• Integrates with other Spint analyses (e.g.,
nullness, aliases, ownership, etc.)
25 September 2003 Dependable Computing Fall 2003 36
Example
FILE *f = fopen (fname, “rw”);int i = fgetc (f);if (i != EOF) { fputc (i, f); fclose (f);}
f:openness = open, f:rwness = rwread
Attribute mismatch – passed read where write FILE * expected.
Possibly null reference f passed where non-null expected
f:openness = openf:rwness = rweither
Branches join in incompatible states: f is closed on true branch,open on false branch
f:openness = closed, f:rwness = rwnone
25 September 2003 Dependable Computing Fall 2003 37
Other Static Analysis Tools• PREfix (Microsoft)
– C/C++ defect detection, no user annotations (models of library functions)
– Runs on Windows, Office, etc. code base• Thousands of warnings, prioritize those most likely
to be interesting
• ESC/Java (Compaq SRC)– Annotations describe invariants– Warnings where Java programs could raise
RunTime exceptions, concurrency issues
25 September 2003 Dependable Computing Fall 2003 38
Summary• Redundancy is good for dependability• Static analysis tools can check redundant
information is consistent• Any useful property is impossible to decide
soundly and completely (but, lots of useful checking can still be done)
• For more on Splint: www.splint.org