Model checking concurrent linux device drivers

Witkowski, Thomas; Blanc, Nicolas; Kroening, Daniel; Weißenbacher, Georg

doi:10.1145/1321631.1321719

Cited by 79 publications

(46 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A similar study of the cost of such a fixed point iteration has recently been undertaken by Miné [16], and our experiments confirm his results: we use three sets of benchmarks that were previously used as case studies on the analysis of concurrent software: (1) concurrency bug patterns from the Apache web server as used in [26] (atom001, atom001a, atom002, atom002a, banking/av, banking/no av, banking/some av), (2) the banking and indexer examples from [27] (banking and indexer), and (3) several Linux device drivers together with nondeterministic environments as generated by DDVerify [28]. The detailed results and the source code of all experiments together with our implementation of Rugina and Rinard's points-to analysis is available at http://www.cprover.org/wmm/.…”

Section: Specification Vs Implementations Of the Repair Loopmentioning

confidence: 99%

Soundness of Data Flow Analyses for Weak Memory Models

Alglave

Kroening

Lugton

et al. 2011

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

Abstract. Modern multi-core microprocessors implement weak memory consistency models; programming for these architectures is a challenge. This paper solves a problem open for ten years, and originally posed by Rinard: we identify sufficient conditions for a data flow analysis to be sound w.r.t. weak memory models. We first identify a class of analyses that are sound, and provide a formal proof of soundness at the level of trace semantics. Then we discuss how analyses unsound with respect to weak memory models can be repaired via a fixed point iteration, and provide experimental data on the runtime overhead of this method.

show abstract

Section: Specification Vs Implementations Of the Repair Loopmentioning

confidence: 99%

Soundness of Data Flow Analyses for Weak Memory Models

Alglave

Kroening

Lugton

et al. 2011

Programming Languages and Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…In [12] several case studies are reported and among them are checks of two versions of the Linux kernel, with confirmed errors found. A predicate abstraction approach to concurrent Linux device drivers analysis is presented in [36]. The tool DDVerify described there can generate a driver harness from a driver source code, which can further be analysed by a pre-/post condition checking tool SatAbs.…”

Section: Related Workmentioning

confidence: 99%

Behavioural Analysis of an I2C Linux Driver

Bošnački

Mathijssen

Usenko

2009

Formal Methods for Industrial Critical Systems

View full text Add to dashboard Cite

Abstract. We present an analysis of the behaviour of an I 2 C Linux driver, by means of model checking with the mCRL2 toolset and static analysis with UNO. We have reverse engineered the source code to obtain the structure and interactions of the driver. Based on these results, we have semi-automatically created an mCRL2 model of the behaviour of the driver, on which we have checked mutual exclusion properties. This revealed non-trivial potential errors, like unprotected usage of shared memory variables due to inconsistent locking and disabling/enabling of interrupts. We also applied UNO on the instrumented source code and were able to find the same errors. These defects were confirmed by the developers.

show abstract

“…Nowadays CEGAR principles of program verification are implemented in 3 systems for program analysis -BLAST (Berkley Lazy Abstraction Software verification Tool) [7], [8], [9], [17], SDV (Static Driver Verifier) [1], [2], [3], [4], [5], [6], and DDVerify [22]. These systems differ in the techniques used for checking the feasibility of trace and computing abstraction refinement.…”

Section: Formal Analysis Of Programsmentioning

confidence: 99%

How to Cook an Automated System for Linux Driver Verification

Хорошилов¹,

Mutilin²,

Shcherbina³

et al. 2008

Proceedings of the Spring/Summer Young Researchers' Colloquium on Software Engineering

View full text Add to dashboard Cite

Abstract-We present the preliminary results of our work on designing an automatic toolset for verification of Linux kernelspace drivers. By now the toolset includes three components:• a library of verification models; each model is a formal description of some safety property to be checked; • a preprocessor unit; it is intended for simulating an environment of a driver; • a verification unit BLAST; it is a general-purpose toolkit intended for automatic program verification based on Boolean abstraction and counter-example guided abstraction refinements techniques. We discuss in some details how our system operates and outline the directions for future work.Operating system (OS) is the key component of every computer system including automatic control system of power station, bank information system, or just a cheap cell phone. The faults occurred in OS may result in fatal consequences: damage of the objects under the control of computer, material losses, data leakage. For the most part program errors do not exceed the bounds of erroneous software components; they can be easily localized, checked and corrected. But if a software component operates in a kernel mode then its erroneous behaviour has far-reaching implications and tends to failure many other elements of computer system. The empirical data indicate (see [10], [21]) that bugs in kernel-space device drivers cause 85% of the system crashes. Therefore verification of OS drivers is the topical problem in software designing.The most generally employed approach to detecting bugs in application programs is testing. But in the case of OS testing encounter with a number of limitations that drastically deteriorate its effectiveness. When testing OS components one checks the correctness of their behaviour only on some specific configurations depending on the state of main and peripheral hardware, distribution of internal and external events, etc. The number of such configurations in incredibly large and even small difference in configurations may cause in significant variances in OS behaviour. That is why no reasonable test set could cover a high proportion of traces in OS code to detect all possible errors. Certainly, a highly skilled expert is able to reveal the most critical parts of OS code and thus guide the detection of errors, but in this case the reliability of a driver becomes a subject to human factor.In this paper we report on the attempts to implement a new approach to driver verification which would be able to cope pure automatically with checking the most common errors occurred in OS drivers. When verification of drivers is concerned, it should be noticed that the most important issue which need to be checked is the safety of interaction between a driver and the other components of OS. A vast amount of drivers employ only some bounded set of conventional means for interacting with the environment. Close inspection of means and templates that are used by designers of drivers makes its possible to settle in formal terms the requirements (rules) that sho...

show abstract

Model checking concurrent linux device drivers

Cited by 79 publications

References 25 publications

Soundness of Data Flow Analyses for Weak Memory Models

Soundness of Data Flow Analyses for Weak Memory Models

Behavioural Analysis of an I2C Linux Driver

How to Cook an Automated System for Linux Driver Verification

Contact Info

Product

Resources

About