David Evansevans@cs.virginia.eduhttp://www.cs.virginia.edu/~evans

The Bugs and the Bees

Research in Programming Languages and Security

University of VirginiaDepartment 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”

LCLintHow 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 RequiredLow Unfathomable

Formal Verifiers

Bug

s D

etec

ted

none

all

Compilers

LCLintLCLint

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

1 int 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 nulldummy.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.eduPATV ‘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

UntrustedProgram

SafeProgram

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

SafetyPolicy

Naccio Overview

ProblemUser’s View

Files

Resources

PolicyPolicy

System View

WriteFile (fHandle, …)

Disk

ProgramProgram

System LibrarySystem Library

OS KernelOS Kernel

tar cf *

Pla

tform

Inte

rfa

ce

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 fileApplicationApplication transformertransformer

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 classesWin32 – program is Win32 executable and DLLs

Per application

Policy Policy compilercompiler

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 secureFor more information:

http://naccio.cs.virginia.eduIEEE Security & Privacy `99, my PhD thesis

Programming the Swarm

1950s: Programming in the small...Programmable computersLearned the programming is hardBirth of higher-order languagesTools for reasoning about trivial programs

Really Brief History of Computer Science

1970s: Programming in the large...Abstraction, objectsMethodologies for developmentTools for reasoning about

component-based systems

2000s: Programming in the Swarm!

Programming the Swarm: Long-Range Goal

Cement10 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

smar

ter

beha

vior

Bee house-hunting

Stadium Wave

Jazz Octet

Ant RoutingCanada 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?

NoNo

Yes

Programming the Swarm

No

?

Sign up for meetingtimes (form going around).