Lazy Preemption to Enable Path-Based Analysis of Interrupt-Driven Code

1. Lazy Preemption to Enable Path-Based Analysis of Interrupt-Driven Code Wei Le, Jing Yang, Mary Lou Soffa, and Kamin Whitehouse Department of Computer Science University of Virginia SESENA’11 May 22, Waikiki, Honolulu, Hawaii

2. WSN Reliability is Important $25 million for a 100,000 node volcano monitoring network Large money loss if it mistakenly reports a non-existing eruption Severe vulnerability and human casualty if it fails to report a real eruption However, traditional techniques and tools for software reliability are handicapped in the WSN domain !

3. Testing and Debugging? • Limited by the large range of possible input sequences • Real deployment environments are difficult to emulate • Resource constraints limit the use of runtime techniques • Continuous debugging and reprogramming is hard due to remote node deployments Simulation Deployment Real environments Scale EmStar ICE Realism Controlled environments

4. A Complementary: Static Analysis • Interrupt-driven code • Exponential growth of the state space • Path selection: sacrificing coverage • Path merging: sacrificing precision • Our contribution • Insight: physical world changes much slower than software execution • Solution: run interrupt handlers when necessary (based on timing) or convenient (end of functions)

5. A Complementary: Static Analysis Task Interrupt Handler 1, 5, (2|3), 4 1, 2, 5, 4 1, 3, 5, 4 1, (2|3), 4, 5 Total: 6 paths 1 5 1, (2|3), 4, 5 Total: 2 paths 3 2 4

6. Outline • Background • Lazy preemption models • Path-based fault detector

7. Execution Model • TinyOS • Tasks, interrupt handlers, and atomic sections • Task • In-order execution from the task queue • Interrupt • Generated by hardware or environments • Can preempt the current execution • Atomic section • Interrupts are disabled

8. Faults Taxonomy From the most-severe-bug-pool of the TinyOS bug repository

9. Requirements for A Fault Detector • Both detecting and reporting faults should be based on program paths • The interactions between interrupts and tasks should be modeled • Timing analysis should be performed

10. Outline • Background • Lazy preemption models • Path-based fault detector

11. Fully Preemptive Model Task Interrupt Handler 1, 5, (2|3), 4 1, 2, 5, 4 1, 3, 5, 4 1, (2|3), 4, 5 Total: 6 paths 1 5 3 2 4

12. Size of Atomic Sections

13. Size of Tasks and Interrupt Handlers

14. Non Preemptive Model Task Interrupt Handler 1 5 1, (2|3), 4, 5 Total: 2 paths 3 2 4 Only preempt at the end of tasks

15. Restricted Preemptive Model Task Interrupt Handler 1 5 1, (2|3), 4, 5 Total: 2 paths 1, (2|3), 4, 5 1, 3, 5, 4 Total: 3 paths 3 2 Preempt when necessary 4 Only preempt at the end of tasks

16. Outline • Background • Lazy preemption models • Path-based fault detector

17. Framework and Workflow Static Timing Analysis Runtime Enforcement nesC Compiler WSN App in nesC C program CFGs IICFG Execution based on IICFG Demand-Driven Analysis Faults Fix Bugs

18. Static Timing Analysis to Build IICFG • Input • Source code • Arrival frequency for each interrupt • Required response time for each interrupt • Output • Inter-procedural control flow graph (IICFG) • Preemption points on IICFG

19. Demand-Driven, Path-Based Fault Detection Task Interrupt Handler Q5 Len(input)<32:Vul Q1 Len(b)<32 b = input strcpy(a, b) 1 5 Q4 4 < 32: Safe Q3 Len(b)<32 b = “test” 2 3 4 Q2 Len(b)<32

20. Runtime Preemption Enforcement • Record handler • Invoked whenever an interrupt arrives • Records the data at the hardware port • Action handler • Invoked only at preemption points • Switches the context • Executes the original interrupt handler

21. Conclusion • Static analysis in the WSN domain • Satisfy both coverage and precision • Two lazy preemption models • Demand-driven, path-based • Implementation in progress