MetaCartSign in to MyCiteSeer

Include Citations | Advanced Search | Help

Include Citations | Advanced Search | Help

  Measuring operating system robustness [1 citations — 0 self]

Download:
Download as a PDF
by John Devale
http://www.ices.cmu.edu/koopman/thesis/devale.pdf
Add To MetaCart

Abstract:

Robustness is becoming more important as critical software increasingly affects our daily lives. Success in building robust software requires understanding and improving the robustness of the operating system API, but to date there has been no accurate, reproducible way to measure robustness. This paper presents the first full-scale, quantitative measurements of operating system robustness. Each of 15 different operating system’s robustness is measured by automatically testing up to 233 POSIX functions and system calls with exceptional parameter values. The work identifies repeatable ways to crash operating systems with a single call, ways to cause task hangs within OS code, ways to cause task core dumps within OS code, failures to implement defined POSIX functionality for unusual conditions, and false indications of successful completion in response to exceptional input parameter values. Overall, only 55 % to 76 % of tests performed were handled robustly, depending on the operating system being tested. Approximately 6 % to 19 % of tests failed to generate any indication of error in the presence of exceptional inputs. Approximately 1 % to 3 % of calls tested failed to implement defined POSIX functionality for unusual, but specified, conditions. Between 18 % and 33 % of calls tested dumped core from within a POSIX function or system call, and five operating systems were completely crashed by individual user mode system calls with exceptional parameter values. The most prevalent sources of robustness failures were illegal pointer values, numeric overflows, and end-of-file overruns. The results indicate that there is significant opportunity for increasing robustness within current operating systems. However, the role of signals vs. error return codes is both controversial and the source of divergent implementation philosophies, forming a potential barrier to writing portable, robust applications.

Citations

188 The N-Version Approach to Fault-Tolerant Software – AviZienis - 1985
131 Exception handling: Issues and a proposed notation – Goodenough - 1975
78 Glossary of Software Engineering Terminology (ANSI/IEEE Std 729-1983 – Standard - 1983
65 FERRARI: A tool for validation of system dependability properties – Kanawati, Kanawati, et al. - 1992
49 Fault injection experiments using FIAT – Barton, Czeck, et al. - 1990
48 Flight 501 Failure Report by the Inquiry Board – Lions - 1996
43 Black-Box Testing – Beizer - 1995
40 Exception Handling and Tolerance of Software Faults – Cristian - 1995
36 Automated robustness testing of off-the-shelf software components – Kropp, Koopman, et al. - 1998
29 Comparing operating systems using robustness benchmarks – Koopman, Sung, et al. - 1997
21 Measuring fault tolerance with the ftape fault injection tool – Tsai, Iyer - 1995
19 for Information Technology. Portable Operating System Interface (POSIX – Standard - 1995
16 Xept:A software instrumentation method for exception handling – Vo, Wang, et al. - 1997
11 Exceptional C or C with Exceptions – Gehani - 1992
10 Fuzz Revisited: A Re-Examination of the Reliability – Miller, Koski, et al. - 2000
3 An empirical study of the reliability of operating system utilities – Miller, Fredriksen, et al. - 1989
2 CRASHME: Random input testing," (no formal publication available) http:// peple'delphi'cn/gjc/crashne'htnl accessed July 6 – Carrette - 1998
2 Faults in functions, in ALGOL and FORTRAN – Hill - 1971