Ensuring Code Safety Without Run-time Checks for Real-time Control Systems

1. Ensuring Code Safety Without Run-time Checks for Real-time Control Systems -Presented by Sumant Kowshik Joint Work With Dinakar Dhurjati and Vikram Adve. University of Illinois at Urbana-Champaign Supported by NSF U. Illinois

2. Motivation • Reliable online upgrade of control software. • Control code upgrade can have • Timing errors • Logical errors • Runtime software faults • Violate memory safety. • Bugs or attacks due to memory errors. • Platforms with limited address protection • Malicious upgrades compromise system and the framework for reliable upgrade. • Insider attacks: SANS/FBI report.

3. Motivation • Reliable online upgrade of control software. • Control code upgrade can have • Timing errors • Logical errors • Runtime software faults • Violate memory safety. • Attacks disguised as upgrades. • Platforms with limited address protection • Malicious upgrades compromise system and the framework for reliable upgrade. • Insider attacks: SANS/FBI report. Simplex

4. Motivation II • Memory safety: static checking? • Avoid run-time overhead • Early bug detection • Static checking for general languages difficult. • Impose restrictions on the language – Control-C • Rationale: Structure of control code • Computationally intensive, use dense arrays • Simple data structures, dynamic memory. • Mostly in C.

5. Related work • What’s wrong with existing solutions? • Java, RT-Java, Ccured, Safe-C etc. • Runtime checks • Garbage collection • Current Alternatives • Vault [PLDI01], Cyclone[PLDI02] • Target general applications • Annotations: cumbersome. • Runtime checks. • Complementary techniques • Proof carrying code: compiler untrusted. • Vault, Engler et al [OSDI00], Wagner et al. • Checking library code.

6. Contributions of control-C • Targets embedded/control code. • 100% static checking to guarantee safety. • Easy portability: As close to C as possible. • Novel language features • Region-based dynamic memory: single region active at a time. • Array sizes, index expressions and loop bounds affine expressions. Trade-off : expressiveness for control codes vs. safety checking compiler technology vs. portability.

7. Outline of Talk • Introduction • Context • System assumptions • Attacks. • Language rules • Implementation • Results

8. The system • http://www-rtsl.cs.uiuc.edu/drii/download • Catch runtime, logical and timing errors • Kicks out the offending controller. • Stack overflow detected. • Accesses to a range of reserved addresses • Eg. Linux – high gigabyte (1GB of 4GB) reserved upgrade output Safety cont. Decision logic Simplex input

9. Unsafe code • Fatal memory errors can be due to • Variable referencing memory outside the bounds of its data type. • Bad casting, pointer arithmetic, uninitialized pointers • Array bounds violation • Use of pointer to freed memory. • Example: char killcode[] = “\x55\x89…\xc3\x90”; void controlFunc(float a, float b) { int *ret = (int *)&ret + 2; *ret = killcode; } • Jumps in the code to data areas/non-code areas. • Calls to unknown functions.

10. Control-C – Basic Issues • Start with C • No syntactic changes, only usage changes. • Basic issues. • Type safety. • No casts involving pointers. • No pointer arithmetic. • Scalar pointers need to be initialized explicitly before being dereferenced or before taking their address.

11. Control-C – Dynamic Memory • Problem : Pointers to freed memory. • Solution : Region-based memory allocation • Define RInit, RFree, RMalloc • No explicit free call • Single region active at a time. • All local and global scalar pointers dead at region free.

12. Multiple regions active Pointer p not dead after RFree Potentially Example – Region Usage Legal Code if(cond) { RInit(); t = 4; } else { RInit(); t = 8; } p = RMalloc(t); RFree(); Illegal Code … int *p, **t; RInit(); p = RMalloc(4 * sizeof(int)); RInit(); … RFree(); RFree(); t = &p; func(**t);

13. Control-C – Array indexing. • Problem : Checking for array bounds • Index expression must evaluate to a value within array bounds • Difficulty: Analysis of constraints on symbolic integer expressions. • Solution: • Loop bounds affine w.r.t. array size • Index expression affine w.r.t loop index variables or the size of array.

14. Interprocedural propagation Array sizes not constant. Symbolic constant M cancels out Example – Legal Array Usage extern M, N; main() { … if (( N > 0) && (N < 5)) { B = (int *)RMalloc(N * 30); intialize(B); C = generate(B, 20); } } int * generate(int *B, int n) { int *A,i,j,k,; if (B[n] > 0) { A = (int *) RMalloc(5 * B[n] + 10); for (i=M; i < B[n]+M ; ++i) { j = i - M; k = j * 4; A[k] = j ; } … }

15. Control-C : Aggregate Types • Problem : Analysis of pointers in aggregate types (structs, arrays). • Solution : Use of pointers to freed memory • Structs or arrays containing pointers must be allocated dynamically using malloc or alloca. • Solution : Initialization • Initializing pointers to base of reserved address range. Thus, we can have arbitrary pointer-based data structures and arrays.

16. Outline of Talk • Introduction • Context • System assumptions • Attacks. • Language rules • Implementation • Results

17. Implementation • LLVM compiler framework • http://llvm.cs.uiuc.edu • Things gotten for free • Source language independence • Type safety (except for cast) • Jumps to code locations only. • Link-time interprocedural analysis + separate compilation. • SSA.

18. Control-C Compiler Features • Pointers • Global dataflow analysis ensuring that all pointers are initialized • Array bounds analysis • Interprocedural constraint propagation for bounds checking. • Regions • Liveness analysis of pointers upon RFree.

19. Results • Language expressive enough for control? • How easy is it to port from C? • Pointer arithmetic replaced by index variable array traversal • Dynamic memory: use regions • Unions with pointers need to be split

20. Results II • Restrictions detect all potential attacks? • Simplex: Inverted pendulum • Uninitialized pointers • Pointer arithmetic • Illegal casts • Array overflow.

21. Conclusions and Future Work • Control-C aims at guaranteeing absolute safety using static checking alone • The language is close to C and is expressive enough for control/embedded applications • Future work • Expand the scope of the language • Detect illegal system calls/illegal sequences of system calls • Formally verifying that control-C guarantees memory safety

22. Merci Beaucoup!