David Evans evans@cs.virginia cs.virginia/~evans

1. The Bugs and the Bees Research in Programming Languages and Security David Evans evans@cs.virginia.edu http://www.cs.virginia.edu/~evans University of Virginia Department of Computer Science

2. Background • Joined UVA, November 1999 • BS/MS ‘94, and PhD ‘2000 from MIT • Funding for three new students (but will probably only accept 1 or 2) • Courses • Security (CS551) • Grad. Programming Languages (CS655)

3. LCLint Menu • The Bugs • The Bees - “Programming the Swarm” How do we help good people write better programs? How do we prevent bad programs from doing bad things? How can we program large collections of devices?

4. A Gross Oversimplification all Formal Verifiers Bugs Detected LCLint Compilers none Low Unfathomable Effort Required

5. Requirements • No interaction required – as easy to use as a compiler • Fast checking – as fast as a compiler • Gradual Learning/Effort Curve • Little needed to start • Clear payoff relative to user effort

6. Approach • Programmers add annotations (formal specifications) • Simple and precise • Describe programmers intent: • Types, memory management, data hiding, aliasing, modification, null-ity, etc. • LCLint detects inconsistencies between annotations and code • Simple (fast!) dataflow analyses

7. Sample Annotation: only extern only char *gptr; extern only out null void *malloc (int); • 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 *);

8. Example • extern only null void *malloc (int); in library 1 int dummy (void) { 2 int *ip= (int *) malloc (sizeof (int)); 3 *ip = 3; 4 return *ip; 5 } LCLint output: dummy.c:3:4: Dereference of possibly null pointer ip: *ip dummy.c:2:13: Storage ip may become null dummy.c:4:14: Fresh storage ip not released before return dummy.c:2:43: Fresh storage ip allocated

9. LCLint Status • Public distribution since 1993 • Effective checking >100K line programs (checks about 1K lines per second) • Detects lots of real bugs in real programs (including itself, of course) • Thousands of users, Linux Journal, etc. • Checks include type abstractions, modifications, globals, memory leaks, dead storage, naming conventions, undefined behavior, incomplete definition...

10. Where do we go from here? • Extensible Checking • Allow users to define new annotations and associated checking • Integrate run-time checking • Combine static and run-time checking to enable additional checking and completeness guarantees • Generalize framework • Support static checking for multiple source languages in a principled way

11. LCLint • More information: lclint.cs.virginia.edu PATV ‘2000, PLDI ’96, FSE’94 • Students: David Larochelle, Chris Barker, Vic Ludwig • Current Funding: NASA (joint with John Knight) • Previous funding: DARPA, NSF, ONR, DEC

12. Untrusted Program Naccio Safe Program

13. Naccio Motivation • Weaknesses in existing code safety systems: • Limited range of policies • Policy definition is ad hoc and platform dependent • Enforcement is tied to a particular architecture • Can we solve them without sacrificing efficiency or convenience? Yes!

14. Naccio Overview Program • General method for defining policies • Abstract resources • Platform independent • System architecture for enforcing policies • Prototypes for JavaVM classes, Win32 executables Naccio Safety Policy Safe Program

15. Problem User’s View System View Program tar cf * WriteFile (fHandle, …) System Library Policy Platform Interface OS Kernel Resources Files Disk

16. Safety Policy Definition • Resource descriptions: abstract operational descriptions of resources (files, network, threads, display, …) • Platform interface: mapping between system events (e.g., Java API calls, Win32 API calls) and abstract resources • Resource use policy: constraints on manipulating those resources

17. Naccio Architecture Per policy Per application Safety policy definition Program Application transformer Policy compiler Policy description file • Version of program that: • Uses policy-enforcing system library • Satisfies low-level code safety Policy-enforcing system library Current Platforms: JavaVM– program is collection of Java classes Win32 – program is Win32 executable and DLLs

18. Open Issues • Low-Level Code Safety for Win32 • How can you prevent malicious programmer from tampering with checking code? • Policy Development • What is the correct policy for different environments? • User Interface • How can you present policy violations to naive users in a sensible way?

19. Naccio Summary • Method for defining large class of policies • Using abstract resources • General architecture for code safety • Encouraging results so far • Win32 (Andrew Twyman, MIT MEng’99): need to implement low-level safety • JavaVM: believed to be secure • For more information: • http://naccio.cs.virginia.edu • IEEE Security & Privacy `99, my PhD thesis

20. Programming the Swarm

21. Really Brief History of Computer Science 1950s: Programming in the small... Programmable computers Learned the programming is hard Birth of higher-order languages Tools for reasoning about trivial programs 1970s: Programming in the large... Abstraction, objects Methodologies for development Tools for reasoning about component-based systems 2000s: Programming in the Swarm!

22. Programming the Swarm: Long-Range Goal Cement 10 GFlop

23. What’s Changing • Execution Platforms • Not computers (98% of microprocessors sold this year) • Small and cheap • Execution environment • Interact with physical world • Unpredictable, dynamic • Programs • Old style of programming won’t work • Is there a new paradigm?

24. Swarm Programming • Primitives describe group behaviors • What are the primitives? • How are they specified? • Important to understand both functional (how the state changes) and non-functional (power use, robustness, efficiency, etc.) properties • Construct complex behaviors by composing primitives • Predict behavior of result • Pick the right primitives based on description of desired non-functional properties

25. Group Behavior Manchester United Bee house-hunting Jazz Octet smarter behavior Concrete Bridge CS IM Team Canada Geese Ant Routing Stadium Wave Disperse (demo) smarter devices

26. Finding an Advisor • Don’t rely on the matching process • This is the last resort! • Find someone with whom you can well • Can’t tell this from one breakout session • Meet at least twice with potential advisors before matching forms

27. No Yes People are basically evil? No No Yes LCLint People are basically crazy? Annotation-Assisted Lightweight Static Checking No Yes Policy-Directed Code Safety ? Programming the Swarm Summary – Project Decision Tree People are basically good? Sign up for meeting times (form going around).