Title: Lazy Preemption to Enable Path-Based Analysis of Interrupt-Driven Code
1Lazy 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
- SESENA11
- May 22, Waikiki, Honolulu, Hawaii
2WSN 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 !
3Testing 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
Deployment
Simulation
Real environments
Scale
EmStar
ICE
Realism
Controlled environments
4A 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)
5A Complementary Static Analysis
Task
Interrupt Handler
1, 5, (23), 4 1, 2, 5, 4 1, 3, 5, 4 1, (23), 4,
5 Total 6 paths
1
5
1, (23), 4, 5 Total 2 paths
3
2
4
6Outline
- Background
- Lazy preemption models
- Path-based fault detector
7Execution 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
8Faults Taxonomy
Bug Types Bug Types Number of Bugs
Interrupt Related Bugs Deadlock 4
Interrupt Related Bugs Race Condition 2
Interrupt Related Bugs Atomicity Violation 1
Interrupt Related Bugs Task Queue Overflow 2
Interrupt Related Bugs Stack Overflow 1
Logic violation bugs Logic violation bugs 5
From the most-severe-bug-pool of the TinyOS bug
repository
9Requirements 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
10Outline
- Background
- Lazy preemption models
- Path-based fault detector
11Fully Preemptive Model
Task
Interrupt Handler
1, 5, (23), 4 1, 2, 5, 4 1, 3, 5, 4 1, (23), 4,
5 Total 6 paths
1
5
3
2
4
12Size of Atomic Sections
13Size of Tasks and Interrupt Handlers
14Non Preemptive Model
Task
Interrupt Handler
1
5
1, (23), 4, 5 Total 2 paths
3
2
4
Only preempt at the end of tasks
15Restricted Preemptive Model
Task
Interrupt Handler
1
5
1, (23), 4, 5 Total 2 paths
1, (23), 4, 5 1, 3, 5, 4 Total 3 paths
3
2
Preempt when necessary
4
Only preempt at the end of tasks
16Outline
- Background
- Lazy preemption models
- Path-based fault detector
17Framework 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
18Static 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
19Demand-Driven, Path-Based Fault Detection
Task
Interrupt Handler
Q5 Len(input)lt32Vul
Q1 Len(b)lt32
b input
strcpy(a, b)
1
5
Q4 4 lt 32 Safe
Q3 Len(b)lt32
b test
2
3
4
Q2 Len(b)lt32
20Runtime 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
21Conclusion
- Static analysis in the WSN domain
- Satisfy both coverage and precision
- Two lazy preemption models
- Demand-driven, path-based
- Implementation in progress