Type Qualifiers

1. Type Qualifiers CS 6340

2. 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

3. Conclusion? Software is buggy

4. So What? • 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

5. Common Techniques for Software Quality • 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

6. Tools Need Specifications • 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

7. const 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)

8. Application: Format String Vulnerabilities • 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); ?

9. Format String Attacks • 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

10. Using Tainted and Untainted • 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

11. tainted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

12. Framework • Pick some qualifiers • and relation (partial order) among qualifiers • Add a few explicit qualifiers to program • Infer remaining qualifiers • and check consistency

13. Type Qualifier Inference • 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

14. int  ptr( FILE) open a0  a1 int a2 ptr ptr( char) tainted open FILE a ptr tainted char Adding Qualifiers to Types

15. f 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)

16. untainted 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

17. a0 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

18. a0 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

19. a0 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

20. Satisfiability in Linear Time • 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

21. The Story So Far... • 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

22. Application: Locking Lock x; lock(x); ...critical section... unlock(x); • x : locked Lock • x : unlocked Lock

23. Flow-Sensitive Type Qualifiers • 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 */

24. Some Challenges • 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?

25. Modeling State with Abstract Stores • 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, ... }

26. What About Aliasing? • 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

27. r *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;

28. { 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), ... }

29. What About Scalability? • 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

30. Constructing Stores • 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.

31. Example Lock x; while (...) { lock(x); y := ... unlock(x); }

32. Alloc(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); }

33. Alloc(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

34. Lazy Constraint Resolution • 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

35. Constraint Resolution Example 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

36. Constraint Resolution Example 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

37. Constraint Resolution Example 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

38. Constraint Resolution Example 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

39. Constraint Resolution Example 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

40. Constraint Resolution Example 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

41. Constraint Resolution Example 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

42. Constraint Resolution Example 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

43. Constraint Resolution Example 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

44. Constraint Resolution Example 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

45. Constraint Resolution Example 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

46. Strong Updates • 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

47. Weak Updates • 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

48. Recovering Linearity • 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

49. Restrict Example Lock locks[n]; lock(&locks[i]); ... unlock(&locks[i]);

50. Restrict Example • 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);