1. Data-flow Analysis for Interrupt- driven Microcontroller Software Nathan Cooprider Advisor: John Regehr Dissertation defense School of Computing University of Utah

2. 2 A whole program analysis Targeting embedded C programs Suitable for use in a compiler Data-flow Analysis for Interrupt- driven Microcontroller Software

3. 3 Microcontrollers (MCUs) 10 billion units / year $12.5 billion market in 2006 Cheap Resource constrained e.g. Wireless sensor networks –Mica2 mote ATmega 128L (4 MHz 8-bit MCU) 128 kB code, 4 kB data SRAM

4. 4 Problem Resources are constrained Software outlives hardware –Code reuse leads to bloat Low-level code confuses analysis –Interrupt-driven concurrency –Device register access

5. 5 Solution Traditional data-flow analysis –Not adequate precision for MCU software New techniques to increase precision –Deal with concurrency –Track volatile data Use in code transformations –Optimizations Thesis statement

6. 6 Contributions Analysis techniques –Interatomic concurrent data-flow (ICD) –Tracking data through volatile variables Tool – cXprop Applications –Practical memory safety – Safe TinyOS –Offline RAM Compression

7. 7 Open-source OS for WSNs Written in nesC –Dialect of C Concurrency –Tasks and interrupts –No threads –Atomic sections main task Interrupt task

8. 8 Abstract interpretation Safe TinyOS RAM compression ICD Conditional x propagation Pointer analysis Volatile tracking cXpropcXprop

9. 9 switch (x) {... break; case 42: case 7: case -1: if (x < 0) x *= -1; x++; if (x == 0) assert(0); break;... Abstract interpretation Abstract domain –Abstract values –Form poset Subset relation (  ) –Lattice Undefined () Unknown ( ⊥ ) x={42,7,-1} {42,7,-1} or ⊥ {42,7} {7} {7,-1}{42,-1} {42} {-1} {} or

10. 10 switch (x) {... break; case 42: case 7: case -1: if (x < 0) x *= -1; x++; if (x == 0) assert(0); break;... Abstract interpretation Abstract domain –Abstract values –Form poset Subset relation (  ) –Lattice Undefined () Unknown ( ⊥ ) Data-flow analysis –Transfer functions –Merging (  ) –Fixed point x={42,7,-1}

11. 11 Τ Τ Τ Τ Τ Τ Τ Abstract interpretation Abstract domain –Abstract values –Form poset Subset relation (  ) –Lattice Undefined () Unknown ( ⊥ ) Data-flow analysis –Transfer functions –Merging (  ) –Fixed point x<0 x++; x==0 assert(0); x*=-1; {42,7,-1} {-1} {42,7,1} Τ {1} {42,7} Τ {43,8,2}   *= < ++ ==

12. 12 Abstract interpretation Safe TinyOS RAM compression ICD Conditional x propagation Pointer analysis Volatile tracking cXpropcXprop

13. 13 Interrupt-driven concurrency Problems –C statements not necessarily atomic x = 0x4242; ldi r24, 0x42 ldi r25, 0x42 Interrupt

14. 14 Interrupt-driven concurrency Problems –C statements not necessarily atomic –Preempts sequential control flow Complicated control flow Synchronization –One flow does not “break” another –Bad synchronization happens Difficult or impossible to reason about Must deal with conservatively ( ⊥ ) A race

15. 15 Related work Thread-based concurrency –M. B. Dwyer, L. A. Clarke, J. M.Cobleigh, and G. Naumovich. Flow analysis for verifying properties of software systems. TOSEM 2004. –M. C. Rinard. Analysis of multithreaded programs. SAS 2001. Leveraging race detection –R. Chugh, J. W. Voung, R. Jhala, and S. Lerner. Dataflow analysis for concurrent programs using datarace detection. PLDI 2008. Formal semantics –X. Feng, Z. Shao, Y. Dong, Y. Gho. Certifying low-level programs with hardware interrupts and preemptive threads. PLDI 2008.

16. 16 Race detection Lockset analysis - standard technique –Lock status = interrupt enable bit status –Only one lock – no lock aliasing –nesC uses lexical nesting Data classification –Unshared – accessed only from main –Shared – accessed from interrupts

17. 17 Race detection Data classification –Unshared – accessed only from main –Shared – accessed from interrupts  Accessed without locking  Written in shared or unlocked unshared code  Accessed in shared code RACERACE

18. 18 Not racing Race detection case analysis Interrupt or task Atomic section Use Interrupt ReadWrite Racing Access Read Write

19. 19 Data classification Data Static (Global) Stack Heap SharedUnshared Racing Not racing ⊥ Concurrent Sequential 6%44% 50%

20. 20 Atomic interleaving main Atomic section Atomic section Interrupt Atomic section Interatomic Concurrent Data-flow Published at LCTES 2006

21. 21 Volatile C type qualifier – volatile int Special case of C’s memory model –Read value may change “randomly” –Write may affect system state E.g., racing data, device registers Behavior opaque at C level Prevents compiler optimizations

22. 22 Tracking volatile RAM Locate variables backed by RAM Introduce concurrency information –Interatomic concurrent dataflow Have sound approximation of mutators –Behavior not opaque at system level Safely analyze volatile variables in RAM

23. 23 Tracking volatile device registers Hardware registers –Memory mapped I/O –Hardware not actually random (volatile) Can track using MCU-specific information –OK to track individual bits Instead of whole register Interrupt bit of status register Volatile tracking

24. 24 Pointer analysis Points-to sets – must and may alias –Two pluggable domains –Subtleties from context-insensitivity Targets: –Device registers –Scalars –Structs –Arrays –not-NULL –Heap Pointer analysis

25. 25 Conditional X propagation Pluggable abstract domains –From conditional constant propagation Clean domain interface –Transfer functions –Abstract interpretation utility functions Analysis Abstract domain Conditional X propagation

26. 26 Constant Bitwise Interval Value set Domains Conditional X propagation

27. 27 Abstract interpretation Safe TinyOS RAM compression ICD Conditional x propagation Pointer analysis Volatile tracking cXpropcXprop

28. 28 Struct splitter Inliner Cleaner Fixed point computation Value-flowPointer-flow ICDVolatile tracking Cleaner Transformations Constant propagation Dead code elimination Dead data elimination Implemented as a CIL extension

29. 29 Suppose we have a WSN…

30. 30 What happened? –State got corrupted – array out-of-bounds –Hard to debug Limited visibility into executing systems Difficult to replicate complex bugs Memory safety can –Catch all pointer and array bounds errors Before they corrupt state –Provide a choice of recovery action Display error message or reboot Suppose we have a WSN… Memory safety error

31. 31 Safe TinyOS Published at SenSys 2007 Expand into system safety Modify TinyOS to work with Deputy Enforce Deputy’s safety model under concurrency Reduce overhead cXprop Deputy: existing solution for making C safe

32. 32 int post(val_t* COUNT(n) buf, int n); cXprop whole-program optimization whole-program optimization compress error messages compress error messages deal with concurrency deal with concurrency enforce safety using Deputy enforce safety using Deputy Safe TinyOS toolchain run modified nesC compiler Annotate Safe TinyOS code TinyOS code run modified nesC compiler Modify TinyOS to work with Deputy Enforce Deputy’s safety model under concurrency Reduce overhead Safe TinyOS app int post(val_t* buf, int n);

33. 33 Concurrency Deputy enforces safety in sequential code cXprop avoids extraneous protection –Only racing variables need protection Potentially unsafe read If () Deputy check Interrupt Potentially unsafe read to local Read local Atomic block

34. 34 Transition notes (hidden) Results AVR atmega128 code –TinyOS 2 – wireless sensor networks Metrics –code size Down is good

35. 35 Code size

36. 36 Code size 35% 13% -11% Safe TinyOS

37. 37 A closer look at RAM usage On-chip RAM for MCUs expensive –Kilobytes, not megabytes or gigabytes –Data in SRAM – 6 transistors / bit –SRAM can dominate power consumption of a sleeping chip

38. 38 A closer look at RAM usage On-chip RAM for MCUs expensive –Kilobytes, not megabytes or gigabytes –Data in SRAM – 6 transistors / bit –SRAM can dominate power consumption of a sleeping chip Is RAM used efficiently? –Performed value profiling for MCU apps Apps already heavily tuned for RAM usage –Result: Average byte stores four values! On-chip RAM is persistently scarce in tiny MCU-based systems

39. 39 Offline RAM compression Automated sub-word packing for statically allocated scalars, pointers, structs, arrays –No heap on targeted MCUs –Trades ROM and CPU cycles for RAM Published at PLDI 2007

40. 40 Method x ≝ variable that occupies n bits V x ≝ conservative estimate of value set  log 2 |V x |  < n ⇒ RAM compression possible C x ≝ another set such that |C x | = |V x | f x ≝ bijection between V x and C x n -  log 2 |C x |  ⇒ bits saved through compression of x

41. 41 Example Compression void (*function_queue[8])(void);

42. 42 Example Compression x n = size of a function pointer = 16 bits void (*function_queue[8])(void);

43. 43 Example Compression &function_A &function_B &function_C NULL VxVx x

44. 44 Example Compression |V x | = 4 VxVx x n = 16 bits  log 2 |V x |  < n 2 < 16

45. 45 Example Compression VxVx x CxCx 0 1 2 3 f x ≝ V x to C x ≝ compression f x -1 ≝ C x to V x ≝ decompression

46. 46 Example Compression V x = {,,, } x CxCx 0 1 2 3 ROM f x ≝ compression table scan f x -1 ≝ decompression table lookup

47. 47 Example Compression V x = {,,, } x CxCx 0 1 2 3 128 bits reduced to 16 bits 112 bits of RAM saved ROM

48. 48 Transition notes (hidden) Results AVR atmega128 code –TinyOS 1 – wireless sensor networks –Other benchmarks Metrics – duty cycle, code size, data size Simulator – cycle accurate Down is good

49. 49 RAM compression results

50. 50 RAM compression results Compression 22% RAM reduction 3.6% ROM reduction 29% duty cycle increase cXprop (no compression) 10% RAM reduction 20% ROM reduction 5.9% duty cycle reduction Tradeoffs

51. 51 Abstract interpretation Safe TinyOS RAM compression ICD Conditional x propagation Pointer analysis Volatile tracking cXpropcXprop

52. 52 Conclusion Interatomic concurrent data-flow Volatile data may be tracked Better analysis  more optimizations –Safe TinyOS – practical memory safety –RAM compression – 22% RAM reduction http://www.cs.utah.edu/~coop/research/cxprop/ http://www.cs.utah.edu/~coop/safetinyos/ http://www.cs.utah.edu/~coop/research/ccomp/ Thank you

53. 53

54. 54 S u ≝ original size S c ≝ compressed size C ≝ access profile V ≝ cardinality of value set A,B ≝ platform-specific costs Cost/Benefit Ratio

55. 55 Turning the RAM Knob 0%

56. 56 Turning the RAM Knob 10%

57. 57 Turning the RAM Knob 20%

58. 58 Turning the RAM Knob 30%

59. 59 Turning the RAM Knob 40%

60. 60 Turning the RAM Knob 50%

61. 61 Turning the RAM Knob 60%

62. 62 Turning the RAM Knob 70%

63. 63 Turning the RAM Knob 80%

64. 64 Turning the RAM Knob 90%

65. 65 Turning the RAM Knob 100%

66. 66 Turning the RAM Knob 95%

67. 67 Future work Triggering and sequencing Caching compressed values Timer interrupt handler Sense Data ready interrupt handler Data Fire Trigger read x decompress x

68. 68 More related work Safe TinyOS –R. K. Rengaswamy, E. Kohler, and M. Srivastava. Software- based memory protection in sensor nodes. EmNets 2006. –B. L. Titzer. Virgil: Objects on the head of a pin. OOPSLA 2006. –S. Kowshik, D. Dhurjati, and V. Adve. Ensuring code safety without runtime checks for real-time control systems. CASES 2002. Offline RAM compression –Y. Zhang and R. Gupta. Compressing heap data for improved memory performance. Software—Practice and Experience 2006. –L. S. Bai, L. Yang, and R. P. Dick. Automated compile-time and run-time techniques to increase usable memory in MMU-less embedded systems. CASES 2006.

69. 69 PAG Program Analysis Generator –Domain specific language input describes Domain lattice Transfer functions Language-describing grammar Fixed point solution method –Data-flow analyzer as output Does not deal with concurrency Used to evaluate fixed point solutions

70. 70 Feature comparison 12% 5.5%

71. 71 Domain comparison

72. 72 Resource reduction 12% 8.3% 2.5% 1.8%

73. 73 Atomic interleaving main Atomic section Atomic section Interrupt Atomic section Interrupt Atomic section Interatomic Concurrent Data-flow Published at LCTES 2006

74. 74 goo(int *z) *z = 42; a = *z; a = {27} z = {&x} a = {7,27,42} z = {&x} Context insensitivity foo int x = 7; bar(int *y) a is a global variable a = {27} y = {&x} a = {27} x = {7} bar(&x); goo(y); a = {27} x = {7,42}

75. 75 Benchmark descriptions AVR ATmega128 code TinyOS 3,000-26,000 lines of C code Analysis times - seconds to an hour Metrics –Duty cycle % of time processor is on Obtained from Avrora –Cycle-accurate simulator for WSNs –Code size and data size

76. 76 Wireless sensor networks 10 billion units / year $12.5 billion market in 2006 Cheap Resource constrained e.g. Wireless sensor networks –Mica2 mote ATmega 128L (4 MHz 8-bit MCU) 128 KB code, 4 KB data SRAM