David Evans The Bugs and the Bees Research in Programming Languages and Security University of Virginia Department of Computer Science

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)

Menu The Bugs The Bees - “Programming the Swarm” LCLint 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?

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

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

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

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);

Example 1int dummy (void) { 2 int *ip= (int *) malloc (sizeof (int)); 3 *ip = 3; 4 return *ip; 5 } extern only null void *malloc (int); in library 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

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

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

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

Untrusted Program Safe Program

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!

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

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

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

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

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?

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: IEEE Security & Privacy `99, my PhD thesis

Programming the Swarm

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

Programming the Swarm: Long-Range Goal Cement 10 GFlop

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?

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

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

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

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