1 / 22

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

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

keaton
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related