Safe CLevel Programming: Cyclone and Beyond

1
Safe C-Level ProgrammingCyclone and Beyond

• Dan Grossman
• University of Washington
• 26 February 2004
• The faculty member, not the graduate student

2
C is not memory safe

• void f(int p,
• int i,
• int v)
• pi v
• Address pi might hold important data or code
• could be any data in the application
• many other ways to misuse f
• Memory safety is crucial for reasoning about
  programs

0 i n
...
p
i
v
3
A question of trust

• We rely on our C-level software infrastructure
  to
• not crash (or crash gracefully)
• preserve data, restrict access, ...
• serve customers, protect valuables, ...
• Infrastructure is enormous
• careful humans not enough
• One safety violation breaks all isolation
• Memory safety is necessary for trustworthy systems

4
Safe low-level systems

• For a safety guarantee today, use YFHLL
• Your Favorite High Level Language
• YFHLL provides safety in part via
• hidden data fields and run-time checks
• automatic memory management
• Data representation and resource management are
  essential aspects of low-level systems
• Write or extend your O/S with YFHLL?
• There are strong reasons for C-like languages

5
Some insufficient approaches

• Compile C with extra information
• type fields, size fields, live-pointer table,
• treats C as a higher-level language
• Use static analysis
• very difficult
• less modular
• Ban unsafe features
• there are many
• you need them

6
Cyclone a combined approach

• Cyclone is a safe C-level language
• Advanced type system for safety-critical
  invariants
• Flow analysis for tracking state changes
• Exposed run-time checks where appropriate
• Modern language features for common idioms
• Joint work with Greg Morrisett (Harvard),
• Trevor Jim (ATT),
• Michael Hicks (Maryland)

7
The plan from here

• Example NULL-pointer dereferences
• Brief mention of other cool stuff
• Status
• Future directions
• Beyond memory safety and C

8
Not-NULL pointers
/

• Subtyping t_at_ lt t but t_at__at_ lt t_at_?
• Downcast via run-time check, often avoided via
  flow analysis

9
Example

• FILE fopen(const char_at_, const char_at_)
• int fgetc(FILE _at_)
• int fclose(FILE _at_)
• void g(char c)
• FILE f fopen(foo, r)
• while((cfgetc(f)) ! EOF)
• fclose(f)
• Gives warning and inserts one null-check
• Encourages a hoisted check

10
A classic moral

• FILE fopen(const char_at_, const char_at_)
• int fgetc(FILE _at_)
• int fclose(FILE _at_)

• Richer types make interface stricter
• Stricter interfaces make implementations
  easier/faster
• Exposing checks to user lets them optimize
• Cant check everything statically (e.g.,
  close-once)

11
Fancier stuff

• Array lengths USENIX2001
• Size known statically int17
• Size-place known statically struct MyArrltigt
• tag_tltigt sz
• inti arr
• Fat pointers int?
• Region-based memory management PLDI2001
• Dangling-pointer dereferences a compile-time
  error
• Integrates with optional garbage collection
• C things (varargs, unions, casts, )

12
The plan from here

• Example NULL-pointer dereferences
• Brief mention of other cool stuff
• Status
• Future directions
• Beyond memory safety and C

13
Status

• Cyclone really exists
• gt130K lines of Cyclone code, including the
  compiler
• gcc back-end (Linux, Cygwin, OSX, FreeBSD,
  Mindstorm, )
• Users manual, mailing lists,
• More features exceptions, datatypes,
• Still a research vehicle

14
Experience

• Scalable
• compiler libraries (65K lines) build in lt30sec
• Static safety helps exploit the C-level
• I use x more than in C
• Ported many small benchmarks from C
• usually change 5-10 of lines
• usually 1x to 2x slowdown (less for systems apps)
• changing a little more helps a lot (and still
  safe!)
• discovered unknown bugs

15
Other projects

• STP Patel et al., SOSP2003
• upgrade transport protocols with untrusted code
• RBClick Patel/Lepreau, OPENARCH2003
• resource-bounded extensible routers
• FPGA synthesis Manohar et al., FPGA2004
• MediaNet Hicks et al, OPENARCH2003
• multimedia overlay-network with quick packet
  filtering
• Open Kernel Environment Bos/Samwel,
  OPENARCH2002
• runs partially trusted code in a kernel, but
  shares data
• Windows device driver (6K lines)
• 100 lines in C (vs. 2500 in Vault
  Fähndrich/DeLine)
• unclear what to do when a run-time check fails
• still many ways to crash a kernel (fewer with
  Vault)

16
Onward directions

• Modules
• Encapsulate low-level data assumptions
• Enforce application-level interface protocols
• Error messages
• Advanced type systems with inference a known
  problem
• Can search at human-time for small corrections
  without complicating the checker
• Tractable models
• Beautiful language theory informs the design
• A formal model assures me of soundness (painful
  lessons)
• But the (simplified) models are at the edge of
  tractability

17
Longer term

• What I think an O/S implementation wants
• high-level control, low-level data
• C-level with less historical baggage
• smoother interoperability with assembly and HLLs
• rich, principled compile-time tools for modern
  systems programming
• Broad PL design/implementation interests
• garbage collection, functional languages,
  accurate profiling, temporal properties, type
  systems,

18
Summary

• Memory safety is essential, but the world relies
  on C
• Cyclone is a safe C-level language
• Today
• A language for user-controlled C-level safety
• Sophisticated data and lifetime invariants
• Tomorrow
• Modularity, not just safety
• High-level control, low-level data
• To learn more
• http//www.cs.cornell.edu/projects/cyclone
• write some code!