Cyclone: A safe dialect of C

1. Cyclone: A safe dialect of C Trevor Jim Greg Morrisett Dan Grossman Michael Hicks James Cheney Yanling Wang

2. Overview • Introduction • From C to Cyclone • Implementation • Design History • Conclusion/Questions

3. Introduction “Common errors that cause vulnerabilities — buffer overflows, poor handling of unexpected types and amounts of data — are well understood. Unfortunately, features still seem to be valued more highly among manufacturers than reliability.”

4. Introduction • Safety violations that occur in C • Buffer overflows in C can be caused by bad pointer arithmetic • C uses Null-terminating strings • Out-of-bounds pointers are commonplace in C

5. Introduction • Cyclone allows for safety while retaining C’s syntax and semantics • Has been in development for 2 years • Designed from the ground up for: • Prevention of buffer overflows • Format string attacks • Memory management errors • 110,000 lines • 35,000 for the compiler • 15,000 for supporting libraries • Looking at safety violations enabled by C and how Cyclone avoids them

6. From C to Cyclone • Similarities • It uses C processor • Follows C’s lexical convention and grammar • Same data representation as C • Differences • Cyclone performs a static analysis on code • Inserts run-time checks • Rejects some programs that C might compile

7. From C to Cyclone • Restrictions • Null checks are inserted to prevent segmentation faults • Pointer arithmetic is restricted • Dangling pointers are prevented through region analysis and limitations on free • Only “safe casts’ and unions are allowed • Setjmp and longjmp are not supported • Switch labels in different scopes are disallowed

8. From C to Cyclone • Extensions • Never-Null pointers do not require Null checks • Tagged unions support type-varying arguments • Injections help automate the use of tagged unions for programmers • Polymorphism replaces some use of void * • Exceptions replace some uses of setjmp and longjmp

9. From C to Cyclone • The free function in C can create dangling pointers • The following is a code example Region h { int *x = rmalloc(h.sizeof(int)); int ?y = rnew(h) {1, 2, 3}; char ?z = rprintf(h, “hello”); }

10. From C to Cyclone • Rmalloc – works like malloc but allocates into a region of the handle • Rnew – allocates and initializes a single step • Rprintf – creates a buffer then prints formatted information to that buffer • Handles can be passes to library functions

11. Implementation • Cyclone compiler implemented 35,000 lines of Cyclone • Consists of a parser • Static analysis phase • And a simple translator • Uses gcc as a backend • Have built in utilities • Memory profiler

12. Implementation • Benchmarks • Table shows that much of a significant difference between C and Cyclone • Ease of Porting • Created cyclone so existing C code can be easily ported • Fewer than 10% of the lines needed to be changed to port the benchmarks

13. Implementation • Performance • Non-web benchmarks • Mean and median same • Standard deviation was at most 2% of the mean • Near zero over-head for I/O bound applications • Factor of three slower than C for computationally-intensive benchmarks • Safety • Found array bound violations in three benchmarks when C was ported to Cyclone

14. Design History • Began as an offshoot of TAL • Designed Popcorn to use with it • Cyclone a rework of Popcorn • From learning’s made some notable mistakes and changes • Supported arrays with a type array<t> not a fat pointer • Didn’t understand the importance of Null-terminated strings

15. Conclusion • Cyclone a dialect of C that provides safety • Cyclone uses static analysis and run-time checks to prevent safety violations • Tries to accommodate C’s style of low-level programming Questions ?