Type qualifiers
Download
1 / 60

Type Qualifiers - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on

Type Qualifiers. Lecture 14 CS 6340 (adapted from a talk by Jeffrey Foster). Even after large, extensive testing efforts, commercial software is shipped riddled with errors ("bugs"). -- PITAC Report to the President, February 24, 1999.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Type Qualifiers' - meir


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Type qualifiers

Type Qualifiers

Lecture 14CS 6340

(adapted from a talk by Jeffrey Foster)


Software quality today

Even after large, extensive testing efforts, commercial software is shipped riddled with errors ("bugs").

-- PITAC Report to the President, February 24, 1999

Trustworthy Computing is computing that is available, reliable, and secure as electricity, water services and telephony....No Trustworthy Computing platform exists today.

-- Bill Gates, January 15, 2002 (highest priority for Microsoft)

Software Quality Today


Conclusion
Conclusion? software is shipped riddled with errors ("bugs").

Software is buggy


So what
So What? software is shipped riddled with errors ("bugs").

  • Software has always been buggy

  • But now...

    • More people use software

    • Computers keep getting faster

      • Speed/quality tradeoff changing

    • Cost of fixing bugs is high


Common techniques for software quality
Common Techniques for Software Quality software is shipped riddled with errors ("bugs").

  • Testing

  • Code auditing

  • Drawbacks: Expensive, difficult, error-prone, limited assurances

  • What more can we do?

    • Tools that analyze source code

    • Techniques for avoiding programming mistakes


Tools need specifications
Tools Need Specifications software is shipped riddled with errors ("bugs").

  • put_tty_queue_nolock(c, tty);

  • spin_lock_irqsave(&tty->read_lock, flags);

  • spin_unlock_irqrestore(&tty->read_lock, flags);

  • Goal: Add specifications to programs

    • In a way that...

    • Programmers will accept

      • Lightweight

    • Scales to large programs

    • Solves many different problems


Type qualifiers1

const software is shipped riddled with errors ("bugs").

ANSI C

tainted

Security vulnerabilities

File operations

open

Type Qualifiers

  • Extend standard type systems (C, Java, ML)

    • Programmers already use types

    • Programmers understand types

    • Get programmers to write down a little more...

int

ptr( char)

int  ptr( FILE)


Application format string vulnerabilities
Application: Format String Vulnerabilities software is shipped riddled with errors ("bugs").

  • I/O functions in C use format strings

    printf("Hello!"); Hello!

    printf("Hello, %s!", name); Hello,name!

  • Instead of

    printf("%s", name);

    Why not

    printf(name); ?


Format string attacks
Format String Attacks software is shipped riddled with errors ("bugs").

  • Adversary-controlled format specifier

    name := <data-from-network>

    printf(name); /* Oops */

    • Attacker sets name = “%s%s%s” to crash program

    • Attacker sets name = “...%n...” to write to memory

  • Lots of these bugs in the wild

    • New ones weekly on bugtraq mailing list

    • Too restrictive to forbid variable format strings


Using tainted and untainted
Using Tainted and Untainted software is shipped riddled with errors ("bugs").

  • Add qualifier annotations

    int printf(untainted char *fmt, ...)

    taintedchar *getenv(const char *)

    tainted = may be controlled by adversary

    untainted = must not be controlled by adversary


Subtyping

tainted software is shipped riddled with errors ("bugs").untainted

/

Subtyping

void f(tainted int);

untainted int a;

f(a);

void g(untainted int);

tainted int b;

f(b);

OK

f accepts tainted or untainted data

Error

g accepts only untainted data

untainted tainted

untainted tainted


Framework
Framework software is shipped riddled with errors ("bugs").

  • Pick some qualifiers

    • and relation (partial order) among qualifiers

  • Add a few explicit qualifiers to program

  • Infer remaining qualifiers

    • and check consistency


Type qualifier inference
Type Qualifier Inference software is shipped riddled with errors ("bugs").

  • Two kinds of qualifiers

    • Explicit qualifiers: tainted, untainted, ...

    • Unknown qualifiers: a0,a1, ...

  • Program yields constraints on qualifiers

    tainteda0a0untainted

  • Solve constraints for unknown qualifiers

    • Error if no solution


Adding qualifiers to types

int software is shipped riddled with errors ("bugs"). ptr( FILE)

open

a0

a1

int

a2

ptr

ptr( char)

tainted

open

FILE

a

ptr

tainted

char

Adding Qualifiers to Types


Constraint generation

f software is shipped riddled with errors ("bugs").

y

z

a6a1

a0

a2a4

a1

int

a2

ptr

a4

ptr

a6

int

a3=a5

a3

int

a5

int

Constraint Generation

ptr(int) f(x : int) = { ... } y := f(z)


Constraints as graphs

untainted software is shipped riddled with errors ("bugs").

a0

a7

a2a4

a1

a2

a4

a6

a3=a5

a9

a3

a5

tainted

a8

Constraints as Graphs

Key idea: programs  constraints  graphs

a6a1


Satisfiability via graph reachability

a software is shipped riddled with errors ("bugs").0

a2a4

a1

a2

a4

a6

a3

a5

Satisfiability via Graph Reachability

Is there an inconsistent path through the graph?

untainted

a6a1

a7

a3=a5

a9

tainted

a8


Satisfiability via graph reachability1

a software is shipped riddled with errors ("bugs").0

a2a4

a1

a2

a4

a6

a3

a5

Satisfiability via Graph Reachability

Is there an inconsistent path through the graph?

untainted

a6a1

a7

a3=a5

a9

tainted

a8


Satisfiability via graph reachability2

a software is shipped riddled with errors ("bugs").0

a2a4

a1

a2

a4

a6

a3

a5

Satisfiability via Graph Reachability

tainteda6a1a3a5a7untainted

untainted

a6a1

a7

a3=a5

a9

tainted

a8


Satisfiability in linear time
Satisfiability in Linear Time software is shipped riddled with errors ("bugs").

  • Initial program of size n

    • Fixed set of qualifiers tainted, untainted, ...

  • Constraint generation yields O(n) constraints

    • Recursive abstract syntax tree walk

  • Graph reachability takes O(n) time

    • Works for semi-lattices, discrete p.o., products


The story so far
The Story So Far... software is shipped riddled with errors ("bugs").

  • Type qualifiers as subtyping system

    • Qualifiers live on the standard types

    • Programs  constraints  graphs

  • Useful for a number of real-world problems

  • Up next: State change and type qualifiers

    • A glimpse of a more complex system

  • Followed by: Applications, experiments


Application locking
Application: Locking software is shipped riddled with errors ("bugs").

Lock x;

lock(x);

...critical section...

unlock(x);

  • x : locked Lock

  • x : unlocked Lock


Flow sensitive type qualifiers
Flow-Sensitive Type Qualifiers software is shipped riddled with errors ("bugs").

  • Standard type systems are flow-insensitive

    • Types don't change during execution

      /* x : int */ x := ...; /* x : int */

  • We need flow-sensitivity

    • Qualifiers may change during execution

      /* y : locked Lock */ y := ...; /* y : unlocked Lock */


Some challenges
Some Challenges software is shipped riddled with errors ("bugs").

  • How do we deal with aliasing?

    p = &x; *p = ...;

  • How do we make the analysis scale?

    • Too expensive to model full state at each point

  • What happens when too much is aliased?

    • How does the programmer control aliasing?


Modeling state with abstract stores
Modeling State with Abstract Stores software is shipped riddled with errors ("bugs").

  • Track each variable's type at each point

    • Abstract stores map variables to types

    • ...and types contain qualifiers

  • { x : t, y : r, z : s, ... }

  • x := ...;

  • { x : t', y : r, z : s, ... }

  • y := ...;

  • { x : t', y : r', z : s, ... }


What about aliasing
What About Aliasing? software is shipped riddled with errors ("bugs").

  • Suppose p points to x:

    { x : q int, p : ptr(q int), ... }

    *p := ...;

    { x : q int, p : ptr(q' int), ... }

    • Variable names alone are insufficient

  • Solution: Add a level of indirection

    • Stores map locations to types

    • Pointer types point to locations


Unification based alias analysis

r software is shipped riddled with errors ("bugs").

*p : ptrr(int)*x : ptrs(int)

...

/* require r = s */

Unification-Based Alias Analysis

  • Initial flow-insensitive pass computes aliasing

    • Before flow-sensitive analysis

    • Simultaneous with standard type inference

      • Types are not flow-sensitive, only qualifiers

  • Associate a location r with each pointer

    • Unify locations that may alias

p = &x;


Using locations in stores

{ software is shipped riddled with errors ("bugs").r : q int, h : ptr(r), ... }

Using Locations in Stores

  • Suppose p points to x:

*p : ptrr(int) x : ptrr(int)

{ x : q int, p : ptr(q int), ... }

  • *p := ...;

  • { r : q' int, h : ptr(r), ... }


What about scalability
What About Scalability? software is shipped riddled with errors ("bugs").

  • Stores are too big

    { r : t, h : r, n : s, ... }

    • A program of size n may have

      • n locations

      • n program points

      • n2 space to represent stores

  • We need a more compact representation

    • Idea: represent differences between stores


Constructing stores
Constructing Stores software is shipped riddled with errors ("bugs").

  • Three kinds of stores S

    S ::= e Unknown store

    | Alloc(S, r : t) Like store S, but r allocated with type t

    | Assign(S, r : t) Like store S, but update type of r with t

  • Store constraints Se

    • Control flow from S to e

  • Solution maps e to { r : t, h : r, n : s, ... }

    • Key: only write down necessary portion of soln.


Example
Example software is shipped riddled with errors ("bugs").

Lock x;

while (...) {

lock(x);

y := ...

unlock(x);

}


Example1

Alloc( software is shipped riddled with errors ("bugs").e0, r : unlocked) e1

Alloc(e0, r : unlocked) e1

Alloc(e0, r : unlocked) e1

Assn(Assn(Assn(e1, r : locked), h : q t), r : unlocked) e1

Assn(Assn(Assn(e1, r : locked), h : q t), r : unlocked) e1

Assn(Assn(Assn(e1, r : locked), h : q t), r : unlocked)e1

Assn(Assn(Assn(e1, r : locked), h : q t), r : unlocked) e1

e1 e2

e0

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock

Example

Lock xr;

while (...) {

lock(xr);

yh := ...

unlock(xr);

}


Example2

Alloc( software is shipped riddled with errors ("bugs").e0, r : unlocked) e1

Assn(Assn(Assn(e1, r : locked), h : q t), r : unlocked) e1

e1 e2

Example

e0

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Lazy constraint resolution
Lazy Constraint Resolution software is shipped riddled with errors ("bugs").

  • We don't care about most locations

    • only those that may be lockedorunlocked

    • In this case, we will only do work for r

  • Key to efficiency:

    When solving for store variables, only represent

    the minimum necessary


Constraint resolution example
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example1
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example2
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example3
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example4
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example5
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example6
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example7
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example8
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example9
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Constraint resolution example10
Constraint Resolution Example software is shipped riddled with errors ("bugs").

e0

green = { r : unlocked Lock }

red = { r : locked Lock }

Alloc r : unlocked Lock

e1

e2

Assign r : locked Lock

check e1(r) : unlocked Lock

Assign h : q t

check (r) : locked Lock

Assign r : unlocked Lock


Strong updates
Strong Updates software is shipped riddled with errors ("bugs").

  • In e2, location r has qualifier q'

    • We've replaced r's qualifier

    • This is called a strong update

    • Location r is linear

e0

Alloc r : q int

e1

Assign r : q' int

e2


Weak updates
Weak Updates software is shipped riddled with errors ("bugs").

  • What if r allocated twice?

    • Only one is actually updated

e0

Alloc r : q int

Alloc r : q int

  • In e2, location r has qualifier q q'

    • We've merged r's new and old qualifiers

    • This is called a weak update

    • Location r is non-linear

e1

Assign r : q' int

e2


Recovering linearity
Recovering Linearity software is shipped riddled with errors ("bugs").

  • What do we do when aliasing too imprecise?

    • Can't strongly update non-linear locations

  • New construct restrict

    • Programmer adds restrict to help the alias analysis

  • restrict x = e1 in e2

    • Roughly: within e2, accesses to *e1 must use x


Restrict example
Restrict Example software is shipped riddled with errors ("bugs").

Lock locks[n];

lock(&locks[i]);

...

unlock(&locks[i]);


Restrict example1
Restrict Example software is shipped riddled with errors ("bugs").

  • Within scope of restrict, only mylock used

    • Can perform strong updates

  • After restrict ends, weak update from mylock to locks[]

Lock locks[n];

restrict mylock = &locks[i] in

lock(mylock);

...

unlock(mylock);


More features
More Features software is shipped riddled with errors ("bugs").

  • Low-cost polymorphism

    • Use effects to avoid merging stores at fn calls

  • Some path-sensitivity

    • Different types on if-then-else branches


Qualifier inference architecture

restrict annotations software is shipped riddled with errors ("bugs").

Qualifier Inference Architecture

Flow-insensitive

Type qualifiers

Alias Analysis

Effect inference

Flow-sensitive

Linearity inference

Type qualifiers


Applications
Applications software is shipped riddled with errors ("bugs").

Published experiments:

const Inference[Foster, Fahndrich, Aiken, PLDI99]

Y2K bug detection[Elsman, Foster, Aiken, 1999]

Format-string vulnerabilities[Shankar, Talwar, Foster, Wagner, Usenix Sec 01]

Locking and stream operations[Foster, Terauchi, Aiken, PLDI 02]

Linux Security Modules [Zhang, Edwards, Jaeger, (IBM Watson) Usenix Sec 02]


Results format string vulnerabilities
Results: Format String Vulnerabilities software is shipped riddled with errors ("bugs").

  • Analyzed 10 popular unix daemon programs

  • Annotations shared across applications

    • One annotated header file for standard libraries

  • Found several known vulnerabilities

    • Including ones we didn’t know about

  • User interface critical


Results locking
Results: Locking software is shipped riddled with errors ("bugs").

  • Looked for simple deadlocks in Linux 2.4.9

    • Double acquires/releases

  • Analyzed 892 files in linux/drivers individually

  • Analyzed 513 modules (all linked files)

    • 14 type errors  deadlocks

    • ~41/892 fail to typecheck but appear correct

    • ~196/513 fail to typecheck

      • added restrict by hand to remove type errors due to aliasing for 64/196


Running time locking
Running Time: Locking software is shipped riddled with errors ("bugs").


Memory usage locking
Memory Usage: Locking software is shipped riddled with errors ("bugs").


Main contributions
Main Contributions software is shipped riddled with errors ("bugs").

  • Type qualifiers as specifications

    • With applications

  • Scalable flow-sensitive qualifier inference

    • Lazy, constraint-based

    • Built with alias analysis, effect inference

    • Linearities for strong/weak updates

  • restrict construct


Some related work
(Some) Related Work software is shipped riddled with errors ("bugs").

  • Dataflow Analysis

  • Bug-finding Tools

    • AST Toolkit [Weise, Crew]

    • Meta-Level Compilation [Engler et al]

  • Type Systems

    • Label flow [Mossin]

    • Typestate [Strom, Yemini, Yellin]

    • Vault [Fähndrich, DeLine]

    • Cyclone [Grossman et al]


Conclusion1
Conclusion software is shipped riddled with errors ("bugs").

  • Type qualifiers are specifications that...

    • Programmers will accept

      • Lightweight

      • Easy to use -- inference and visualization

    • Scale to large programs

    • Solve many different problems

      http://www.cs.berkeley.edu/~jfoster/cqual

      Includes source code and web demo of cqual