210 likes | 324 Views
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. WSN Reliability is Important.
E N D
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
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 !
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
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)
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
Outline • Background • Lazy preemption models • Path-based fault detector
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
Faults Taxonomy From the most-severe-bug-pool of the TinyOS bug repository
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
Outline • Background • Lazy preemption models • Path-based fault detector
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
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
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
Outline • Background • Lazy preemption models • Path-based fault detector
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
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
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
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
Conclusion • Static analysis in the WSN domain • Satisfy both coverage and precision • Two lazy preemption models • Demand-driven, path-based • Implementation in progress