Data-flow Analysis for Interruptdriven Microcontroller Software

Transcription

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

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

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 3

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

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 5

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 6

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

8 ICD Volatile tracking c X p r o p Abstract interpretation Safe TinyOS RAM compression Conditional x propagation Pointer analysis 8

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

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

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

12 ICD Volatile tracking c X p r o p Abstract interpretation Safe TinyOS RAM compression Conditional x propagation Pointer analysis 12

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

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

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 M. C. Rinard. Analysis of multithreaded programs. SAS Leveraging race detection R. Chugh, J. W. Voung, R. Jhala, and S. Lerner. Dataflow analysis for concurrent programs using datarace detection. PLDI Formal semantics X. Feng, Z. Shao, Y. Dong, Y. Gho. Certifying low-level programs with hardware interrupts and preemptive threads. PLDI

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 16

17 Race detection Accessed without locking Written in shared or unlocked unshared code Accessed in shared code Data classification Unshared accessed only from main Shared accessed from interrupts R A C E 17

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

19 Data classification Data Heap Static (Global) Stack Sequential Shared Concurrent Racing Not racing 6% 44% Unshared 50% 19

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

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 21

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 22

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 23

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 24

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

26 Domains Constant Bitwise Value set Interval Conditional X propagation 26

27 ICD Volatile tracking c X p r o p Abstract interpretation Safe TinyOS RAM compression Conditional x propagation Pointer analysis 27

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

29 Suppose we have a WSN 29

30 Suppose we have a WSN What happened? State got corrupted array Memory out-of-bounds safety error 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 30

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

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

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

34 Code size 35

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

36 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 37

37 A closer look at RAM usage On-chip RAM for MCUs expensive Kilobytes, not megabytes or gigabytes On-chip RAM is persistently scarce in tiny MCU-based systems 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! 38

38 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

39 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 40

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

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

42 Example Compression x V x &function_a &function_b &function_c NULL 43

43 Example Compression x V x n = 16 bits V x = 4 log 2 V x < n 2 < 16 44

44 Example Compression x V x C x f x V x to C x compression f x -1 C x to V x decompression 3 45

45 Example Compression ROM x C x V x = {,,, } f x compression table scan f x -1 decompression table lookup 46

46 Example Compression ROM x C x V x = {,,, } bits reduced to 16 bits 112 bits of RAM saved 47

47 RAM compression results 49

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

49 ICD Volatile tracking c X p r o p Abstract interpretation Safe TinyOS RAM compression Conditional x propagation Pointer analysis 51

50 Conclusion Interatomic concurrent data-flow Volatile data may be tracked Better analysis more optimizations Safe TinyOS practical memory safety RAM compression 22% RAM reduction Thank you 52

51 53

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

53 Turning the RAM Knob 0% 55

54 Turning the RAM Knob 10% 56

55 Turning the RAM Knob 20% 57

56 Turning the RAM Knob 30% 58

57 Turning the RAM Knob 40% 59

58 Turning the RAM Knob 50% 60

59 Turning the RAM Knob 60% 61

60 Turning the RAM Knob 70% 62

61 Turning the RAM Knob 80% 63

62 Turning the RAM Knob 90% 64

63 Turning the RAM Knob 100% 65

64 Turning the RAM Knob 95% 66

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

66 More related work Safe TinyOS R. K. Rengaswamy, E. Kohler, and M. Srivastava. Softwarebased memory protection in sensor nodes. EmNets B. L. Titzer. Virgil: Objects on the head of a pin. OOPSLA S. Kowshik, D. Dhurjati, and V. Adve. Ensuring code safety without runtime checks for real-time control systems. CASES Offline RAM compression Y. Zhang and R. Gupta. Compressing heap data for improved memory performance. Software Practice and Experience 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

67 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 69

68 Feature comparison 12% 5.5% 70

69 Domain comparison 71

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

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

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

73 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 75

74 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 76