ACM Home Page
Please provide us with feedback. Feedback
Using model checking to debug device firmware
Source Operating Systems Design and Implementation archive
Proceedings of the 5th symposium on Operating systems design and implementation

Due to copyright restrictions we are not able to make the PDFs for this conference available for downloading

table of contents
Boston, Massachusetts
SESSION: Robustness table of contents
Pages: 61 - 74  
Year of Publication: 2002
ISSN:0163-5980
Authors
Sanjeev Kumar  Princeton University
Kai Li  Princeton University
Sponsor
SIGOPS: ACM Special Interest Group on Operating Systems
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): n/a,   Downloads (12 Months): n/a,   Citation Count: 3
Additional Information:

abstract   references   cited by   collaborative colleagues  

Tools and Actions: Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/1060289.1060296
What is a DOI?

ABSTRACT

Device firmware is a piece of concurrent software that achieves high performance at the cost of software complexity. They contain subtle race conditions that make them difficult to debug using traditional debugging techniques. The problem is further compounded by the lack of debugging support on the devices. This is a serious problem because the device firmware is trusted by the operating system.Model checkers are designed to systematically verify properties of concurrent systems. Therefore, model checking is a promising approach to debugging device firmware. However, model checking involves an exponential search. Consequently, the models have to be small to allow effective model checking.This paper describes the abstraction techniques used by the ESP compiler to extract abstract models from device firmware written in ESP. The abstract models are small because they discard some of the details in the firmware that is irrelevant to the particular property being verified. The programmer is required to specify the abstractions to be performed. The ESP compiler uses the abstraction specification to extract models conservatively. Therefore, every bug in the original program will be present in the extracted model.This paper also presents our experience with using Spin model checker to develop and debug VMMC firmware for the Myrinet network interfaces. An earlier version of the ESP compiler yielded models that were too large to check for system-wide properties like absence of deadlocks. The new version of the compiler generated abstract models that were used to identify several subtle bugs in the firmware. So far, we have not encountered any bugs that were not caught by Spin.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

1
 
2
 
3
A. Basu, T. von Eicken, and G. Morrisett. Promela++: A Language for Correct and Efficient Protocol Construction. In Infocom, 1998.
 
4
5
6
 
7
8
9
10
11
12
 
13
 
14
C. Dubnicki, A. Bilas, Y. Chen, S. Damianakis, and K. Li. VMMC-2: Efficient Support for Reliable, Connection-Oriented Communication. In Hot Interconnects, 1997.
 
15
G. Duval and J. Julliand. Modeling and verification of the RUBIS μ-Kernel with Spin. In International Spin Workshop, 1995.
 
16
D. Engler, B. Chelf, A. Chou, and S. Hallem. Checking System Rules Using System-Specific, Programmer-Written Compiler Extensions. In Operating Systems Design and Implementation, 2000.
17
 
18
K. Havelund and T. Pressburger. Model checking Java programs using Java PathFinder. In International Journal on Software Tools for Technology Transfer, 1999.
19
 
20
 
21
22
23
 
24
S. Kumar and K. Li. Performance Impact of Using ESP to Implement VMMC Firmware. In Workshop on Novel Uses of System Area Networks (SAN-1), 2002.
25
26
 
27
R. Pike, D. Pressoto, K. Thompson, and G. Holzmann. Process sleep and wakeup on shared-memory multiprocessors. In EurOpen Conference, 1991.
28
 
29
F. Tip. A Survey of Program Slicing Techniques. Journal of Programming Languages, 3:121--189, 1995.
 
30
 
31
M. Weiser. Program slicing. IEEE Transactions on Software Engineering, 10:352--357, 1984.