automated tools for software reliability suhabe bugrara [email protected] stanford university

72
Automated Tools for Software Reliability Suhabe Bugrara [email protected] Stanford University

Upload: britton-cook

Post on 23-Dec-2015

234 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Automated Tools for Software Reliability

Suhabe [email protected]

Stanford University

Page 2: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Problem

• 80% of development cost on identifying and correcting defects

• Software errors cost US economy $60 billion annually (0.6% of GDP)

Page 3: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Manual Testing

• Traditional approach to quality assurance• Expensive• Time consuming• Not systematic• Difficult to quantify effectiveness of test suite• Cannot make any guarantees about reliability• Insufficient for safety critical systems

Page 4: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Automated Tools

• Programs to find defects in programs• Automated• Systematic• Easy to quantify effectiveness• Provide guarantees about reliability• Sometimes expensive (for now…)• Sometimes time consuming (for now…)

Page 5: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Program Analyzers

Sound

Unsound

Complete Incomplete

Undecidable

Decidable

Decidable

•Reports all errors•May report false alarms

•Reports all errors•Reports no false alarms

•May not report all errors•May report false alarms

Decidable

•May not report all errors•Reports no false alarms

Page 6: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Static Driver Verifier

• Program analyzer for API usage rules

• Developed by Microsoft Research

• Applied to device drivers in Windows

• Sound: reports all possible errors

• Incomplete: may report false alarms

Page 7: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

SDV: Overview

1. Write API usage rule specification

2. Instrument program with usage checks

3. Abstract program

4. Check abstraction for errors

5. If error found, see if error is false alarm

6. If false alarm, refine abstraction

7. If not false alarm, report error as bug

Page 8: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 9: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 10: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

API Usage Rules

• Ex. locks are alternatingly acquired and released

Page 11: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

API Usage Rules• Ex. locks are alternatingly acquired and released• Expressed as finite state machine

– States = {locked, unlocked,error}– Transitions = {acquire(), release()}

Page 12: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

API Usage Rules• Ex. locks are alternatingly acquired and released• Expressed as finite state machine

– States = {locked, unlocked,error}– Transitions = {acquire(), release()}

lockedunlocked

error

acquire();

release();

acquire();release();

Page 13: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

state {

enum { Unlocked=0; Locked=1} state = Unlocked;

}

KeAcquireSpinLock.return {

if (state == Locked)

error();

else

state = Locked;

}

KeReleaseSpinLock.return {

if (!(state == Locked))

error();

else

state = Unlocked;

}

Page 14: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

enum {Unlocked=0, Locked=1} state = Unlocked

void KeAcquireSpinLock_return() {

if (state == Locked)

error();

else

state = Locked;

}

void KeReleaseSpinLock_return() {

if (!(state == Locked))

error();

else

state = Unlocked;

}

Page 15: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 16: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: void example() {2: do {3: KeAcquireSpinLock();4:5: nPacketsOld = nPackets;6: req = devExt->WLHV7: if (req && req->status) {8: devExt->WLHV = req->Next9: KeReleaseSpinLock();10:11: irp = req->irp;12: if (req->status > 0) {13: irp->IoS.Status = SUCCCESS;14: irp->IoS.Info = req->Status;15: } else {16: irp->IoS.Status = FAIL;17: irp->IoS.Info = req->Status;18: }19: SmartDevFreeBlock(req);20: IoCompleteRequest(irp);21: nPackets++;22: }23: } while (nPackets!=nPacketsOld);24: KeReleaseSpinLock();25:26: }

Page 17: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 18: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

enum {Unlocked=0, Locked=1} state = Unlocked

void KeAcquireSpinLock_return() {

if (state == Locked)

error();

else

state = Locked;

}

void KeReleaseSpinLock_return() {

if (!(state == Locked))

error();

else

state = Unlocked;

}

Page 19: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: void example() {2: do {3: KeAcquireSpinLock();4: KeAcquireSpinLock_return();5: nPacketsOld = nPackets;6: req = devExt->WLHV7: if (req && req->status) {8: devExt->WLHV = req->Next9: KeReleaseSpinLock();10: KeReleaseSpinLock_return();11: irp = req->irp;12: if (req->status > 0) {13: irp->IoS.Status = SUCCCESS;14: irp->IoS.Info = req->Status;15: } else {16: irp->IoS.Status = FAIL;17: irp->IoS.Info = req->Status;18: }19: SmartDevFreeBlock(req);20: IoCompleteRequest(irp);21: nPackets++;22: }23: } while (nPackets!=nPacketsOld);24: KeReleaseSpinLock();25: KeReleaseSpinLock_return();26: }

Program A

Page 20: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 21: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

SDV: Abstraction

• Construct abstraction B of original program A– Over-approximates reachability

• If error() is reachable in A, then it is also reachable in B– This characteristic makes SDV sound

• If error() is reachable in B,then it may not be reachable in A– This characteristic makes SDV incomplete

• Check abstraction B for any errors

Page 22: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Reachable States

Original Aerror

Abstraction B

Sound: If A has error, then B has error

real bug!

Page 23: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Reachable States

Original A

Abstraction Berror

Incomplete: If B has error, then A may not have error

false alarm!

Page 24: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

bool b1;

b1 = false; Abstract state == Locked with b1

void KeAcquireSpinLock_return() {

if (b1)

error();

else

b1 = true;

}

void KeReleaseSpinLock_return() {

if (!(b1))

error();

else

b1 = false;

}

Page 25: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: void example() {2: do {3: ;4: KeAcquireSpinLock_return();5: ;6: ;7: if (SdvMakeChoice()) {8: ;9: ;10: KeReleaseSpinLock_return();11: ;12: if (SdvMakeChoice()) {13: ;14: ;15: } else {16: ;17: ;18: }19: ;20: ;21: ;22: }23: } while (SdvMakeChoice());24: ;25: KeReleaseSpinLock_return();26: }

Program B

Page 26: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 27: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: void example() {2: do {3: ;4: KeAcquireSpinLock_return();5: ;6: ;7: if (SdvMakeChoice()) {8: ;9: ;10: KeReleaseSpinLock_return();11: ;12: if (SdvMakeChoice()) {13: ;14: ;15: } else {16: ;17: ;18: }19: ;20: ;21: ;22: }23: } while (SdvMakeChoice());24: ;25: KeReleaseSpinLock_return();26: }

Error trace found!

Page 28: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: void example() {2: do {3: KeAcquireSpinLock();4: KeAcquireSpinLock_return();5: nPacketsOld = nPackets;6: req = devExt->WLHV7: if (req && req->status) {8: devExt->WLHV = req->Next9: KeReleaseSpinLock();10: KeReleaseSpinLock_return();11: irp = req->irp;12: if (req->status > 0) {13: irp->IoS.Status = SUCCCESS;14: irp->IoS.Info = req->Status;15: } else {16: irp->IoS.Status = FAIL;17: irp->IoS.Info = req->Status;18: }19: SmartDevFreeBlock(req);20: IoCompleteRequest(irp);21: nPackets++;22: }23: } while (nPackets!=nPacketsOld);24: KeReleaseSpinLock();25: KeReleaseSpinLock_return();26: }

But, no bug in original program!

Page 29: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 30: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: void example() {2: do {3: ;4: KeAcquireSpinLock_return();5: b2 = false;6: ;7: if (SdvMakeChoice()) {8: ;9: ;10: KeReleaseSpinLock_return();11: ;12: if (SdvMakeChoice()) {13: ;14: ;15: } else {16: ;17: ;18: }19: ;20: ;21: b2 = !b2 ? true : SdvMakeChoice();22: }23: } while (b2);24: ;25: KeReleaseSpinLock_return();26: }

Program C

Page 31: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Reachable States

Original A

Abstraction Berror

Refined C

false alarm no longer reported!

Page 32: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

SDV: Summary

1. Write API usage rule specification

2. Instrument program with usage checks

3. Abstract program

4. Check abstraction for errors

5. If error found, see if error is false alarm

6. If false alarm, refine abstraction

7. If not false alarm, report error as bug

Page 33: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Soundness

• Assume memory safety– No buffer/integer overflows– Safe memory management– No null pointer dereferences

• Oversimplified harness– Use stubs to model calls into OS procedures– Stubs may not represent all behavior

Page 34: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Research Challenges in Verification

• Eliminate assumption of memory safety

• Eliminate false alarms

• Scale to the entire operating system

• Verify more complicated properties– prove consistency of file system data structures

Page 35: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Program Analyzers

Sound

Unsound

Complete Incomplete

Undecidable

Decidable

Decidable

•Reports all errors•May report false alarms

•Reports all errors•Reports no false alarms

•May not report all errors•May report false alarms

Decidable

•May not report all errors•Reports no false alarms

Page 36: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

EXE

• Automatically generate test cases that explore important program paths

• Developed by Dawson Engler’s group

• Bug finding tool

• Unsound: may not report all errors

• Complete: never reports false alarms

Page 37: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

int bad_abs (int x) {if (x < 0)

return –x;

if (x == 12345678)return –x;

return x;}

Page 38: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

int bad_abs (int x) {if (x < 0)

return –x;

if (x == 12345678)return –x;

return x;}

Page 39: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

int bad_abs (int x) {if (x < 0)

return –x;

if (x == 12345678)return –x;

return x;}

(x >= INT_MIN) && (x <= INT_MAX) && (x < 0) && (ret = -x)

find a solution using an automatic constraint solver…

x = -1

Page 40: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

int bad_abs (int x) {if (x < 0)

return –x;

if (x == 12345678)return –x;

return x;}

(x >= INT_MIN) && (x <= INT_MAX) && (x >= 0) && (x = 12345678) && (ret = -x)

find a solution using an automatic constraint solver…

x = 12345678

Page 41: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

int bad_abs (int x) {if (x < 0)

return –x;

if (x == 12345678)return –x;

return x;}

(x >= INT_MIN) && (x <= INT_MAX) && (x >= 0) && (x != 12345678)

&& (ret = x)

find a solution using an automatic constraint solver…

x = 4

Page 42: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

int bad_abs (int x) {if (x < 0)

return –x;

if (x == 12345678)return –x;

return x;}

EXE automatically generated test cases for each path…

x = -1x = 12345678x = 4

Page 43: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

int bad_abs (int x) {if (x < 0)

return –x;

if (x == 12345678)return –x;

return x;}

Page 44: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: int symbolic_bad_abs (int x) {2: add_constraints(x >= INT_MIN, x <= INT_MAX);3: ret = new symbol; 4:5: if (fork() == child) {6: add_constraints(x < 0, ret = -x);7: return ret;8: //(x >= INT_MIN) && (x <= INT_MAX) && (x < 0) && (ret = -x)9: } else 10: add_constraints(x >= 0);11:12: if (fork() == child) {13: add_constraints(x = 12345678, ret = -x);14: return ret;15: //(x >= INT_MIN) && (x <= INT_MAX) && (x >= 0) && (x = 12345678) 16: // && (ret = -x)17: } else 18: add_constraints(x != 12345678);19:20: add_constraints(ret = x);21: return ret;22: //(x >= INT_MIN) && (x <= INT_MAX) && (x >= 0) && (x != 12345678) 23: && (ret = x)24:}

Page 45: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

1: int main (void) {2: unsigned i, t, a[4] = { 1, 3, 5, 2};3: make_symbolic(&i);4:5: if (i >= 4) 6: exit(0);7:8: char *p = (char *) a + i * 4;9: *p = *p – 1;10:11: t = a[*p];12:13: t = t / a[i];14:15: if (t == 2)16: assert(i == 1);17: else18: assert(i == 3);19: }

Page 46: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University
Page 47: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Review

• Why does SDV produce false alarms and EXE doesn’t?

• Why use SDV, then?

Page 48: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Saturn

• Large-scale program verification

• Developed by Alex Aiken’s group

• Sound: reports all errors

• Incomplete: may report false alarms

• Gives guarantees of reliability on systems as large as the Linux kernel with over 6.2 million lines of code

Page 49: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Program Analyzers

Sound

Unsound

Complete Incomplete

Undecidable

Decidable

Decidable

•Reports all errors•May report false alarms

•Reports all errors•Reports no false alarms

•May not report all errors•May report false alarms

Decidable

•May not report all errors•Reports no false alarms

Page 50: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Unchecked User Pointer Dereferences

• Security property of operating systems• Two types of pointers in operating systems

– kernel pointer: pointer created by the operating system– user pointer: pointer created by a user application and passed to the

operating system via an entry point such as a system call

• Must check that a user pointer points into userspace before dereferencing it

Page 51: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Unchecked User PointerDereferences

1: static ssize_t read_port(…, char * __user buf, …) { 2: unsigned long i = *ppos; 3: char * __user tmp = buf; 4: 5: if (!access_ok(..,buf,...)) //check 6: return -EFAULT; 7: 8: while (count-- > 0 && i < 65536) { 9: if (__put_user(inb(i),tmp) < 0) //deref10: return -EFAULT; 11: i++; 12: tmp++; 13: }14:15: *ppos = i; 16: return tmp-buf; 17: }

Page 52: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Security Vulnerability

• Malicious user could– Take control of the operating system– Overwrite kernel data structures– Read sensitive data out of kernel memory– Crash machine by corrupting data

Page 53: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Verifying the Security Property

• Eliminate the need for annotations

• Eliminate false positives

• Provide guarantee that no security vulnerabilities of this kind are present

Page 54: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Security Verifier

• Design a sound and incomplete verifier to prove statically that no unchecked user pointer dereferences exist

Page 55: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Security Verifier

• Compute set of facts at each program point

• States = { user, checked, error }

• Facts are pairs of locations and states– (*v,user) signifies that v is a user pointer

• Verify that program never in error state

Page 56: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Security Verifier

• Pointer is in user state if created by user application• Pointer is in checked state if access_ok applied• Pointer is in error state if dereferenced when

1. Pointer is in user state, AND

2. Pointer is NOT in checked state

Page 57: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Example1: int sys_call (int *u, int cmd) { //u is user pointer

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) { //check u

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u; //dereference u

12: …

Page 58: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

One Possible Approach

…, but, procedure does not contain any vulnerabilities!

(*u,user)(*u,error) emit warning!

(*u,user) lost precision!

(*u,user)(*u,checked)

1: int sys_call (int *u, int cmd) {

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) {

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u;

12: …

(*u,user)

(*u,user)

(*u,user)

Page 59: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Path Sensitivity

• Ability to reason about branch correlations

• Important for reducing false positive rate

• Programs use substantial amount of branch correlation in practice

Page 60: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Example1: int sys_call (int *u, int cmd) { //u is user pointer

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) { //check u

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u; //dereference u

12: …

Page 61: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Path Sensitivity

Valid Path

1: int sys_call (int *u, int cmd) { //u is user pointer

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) { //check u

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u; //dereference u

12: …

Page 62: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Path Sensitivity

Valid Path

1: int sys_call (int *u, int cmd) { //u is user pointer

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) { //check u

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u; //dereference u

12: …

Page 63: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Path Sensitivity

Valid Path

1: int sys_call (int *u, int cmd) { //u is user pointer

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) { //check u

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u; //dereference u

12: …

Page 64: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Path Sensitivity

Invalid Path!

1: int sys_call (int *u, int cmd) { //u is user pointer

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) { //check u

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u; //dereference u

12: …

Page 65: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Path Sensitive Analysis

(*u,user) true(*u,checked) cmd == 1(*u,error) cmd == 1 &&

!(cmd == 1) && true

false

(*u,user) true(*u,checked) cmd == 1

(*u,user) true(*u,checked) cmd == 1

(*u,user) true1: int sys_call (int *u, int cmd) {

2: int x;

3:

4: if (cmd == 1) {

5: if (!access_ok(u)) {

6: return –ERR;

7: }

8: }

9: …

10: if (cmd == 1)

11: x = *u;

12: …

(*u,user) true

(*u,user) true

Page 66: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Design of Saturn Security Verifier

• Generate summary of behavior for each procedure with respect to calling context

• Apply summary of callee at call site in caller

• Repeatedly generate and apply summaries until a fixed point is reached

Page 67: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Experimental Setup

• Implemented verifier for unchecked user pointer dereferences

• Applied verifier to Linux 2.6.17.1 built for x86 architecture

• 6.4 million lines of code

• Analyzed in 6 hours over 50 node cluster

Page 68: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Results

• 91,543 procedures

• 154 (.17%) of procedures time out

• 627 system call parameters

• 867,544 dereferences

• 15,452 (1.8%) of dereferences time out

Page 69: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Results

• Verified automatically– 620 out of 627 system call arguments (99%)– 851,914 out of 852,092 dereferences (99.96%)

• Warnings– 7 warnings on system call arguments– 278 warnings on dereferences– 20 annotations required to verify

Page 70: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Saturn: Other Analyses

• Null pointer dereferences bug finder– Found hundreds of bugs in systems code– Isil Dillig, Thomas Dillig, and Alex Aiken. Static Error

Detection Using Semantic Inconsistency Inference, PLDI 2007

• Buffer overflow• Safe casting • Integer overflow• Locking• Safe memory management

Page 71: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

Other Tools

• BLAST• CQual• Metal• Daikon • Vault• ESP• ESPX• MOPS• DART

• Prefast• Failure

Oblivious Computing

• CSSV• Alloy• eXplode• Chord• TVLA• CCured• Clouseau• STeP• Prefix

Page 72: Automated Tools for Software Reliability Suhabe Bugrara suhabe@stanford.edu Stanford University

References

• A. Aiken et al. An Overview of the Saturn Project. PASTE 2007

• T. Ball et al. Thorough Static Analysis of Device Drivers. EuroSys 2006

• C. Cadar et al. EXE: Automatically Generating Inputs of Death. CCS 2006

• C. Cadar et al. Execution Generated Test Cases: How to Make Systems Code Crash Itself. SPIN 2006

• B. Hackett et al. Modular Checking for Buffer Overflows in the Large. ICSE 2006.

• J. Yang et al. Automatically generating malicious disks using symbolic execution. IEEE Security and Privacy 2006

• Software Errors Cost U.S. Economy $59.5 Billion Annually. NIST 2002. http://www.nist.gov/public_affairs/releases/n02-10.htm