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 1, 5, (2|3), 4 1, 2, 5, 4 1, 3, 5, 4 1, (2|3), 4, 5 Total: 6 paths 1, (2|3), 4, 5 Total: 2 paths 3 2 4

Outline Background Lazy preemption models Path-based fault detector

Execution Model TinyOS Task Interrupt Atomic section 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

From the most-severe-bug-pool of the TinyOS bug repository Faults Taxonomy Bug Types Number of Bugs Interrupt Related Bugs Deadlock 4 Race Condition 2 Atomicity Violation 1 Task Queue Overflow Stack Overflow Logic violation bugs 5 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 1, 5, (2|3), 4 1, 2, 5, 4 1, 3, 5, 4 1, (2|3), 4, 5 Total: 6 paths 3 2 4

Size of Atomic Sections

Size of Tasks and Interrupt Handlers

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 1, 3, 5, 4 Total: 3 paths 1, (2|3), 4, 5 Total: 2 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 nesC Compiler Static Timing Analysis Runtime Enforcement 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 1 b = input strcpy(a, b) 5 Q4 4 < 32: Safe Q3 Len(b)<32 2 b = “test” 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