Results 1 - 10
of
22
seL4: Formal Verification of an OS Kernel
- ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES
, 2009
"... Complete formal verification is the only known way to guarantee that a system is free of programming errors. We present our experience in performing the formal, machine-checked verification of the seL4 microkernel from an abstract specification down to its C implementation. We assume correctness of ..."
Abstract
-
Cited by 72 (14 self)
- Add to MetaCart
Complete formal verification is the only known way to guarantee that a system is free of programming errors. We present our experience in performing the formal, machine-checked verification of the seL4 microkernel from an abstract specification down to its C implementation. We assume correctness of compiler, assembly code, and hardware, and we used a unique design approach that fuses formal and operating systems techniques. To our knowledge, this is the first formal proof of functional correctness of a complete, general-purpose operating-system kernel. Functional correctness means here that the implementation always strictly follows our high-level abstract specification of kernel behaviour. This encompasses traditional design and implementation safety properties such as the kernel will never crash, and it will never perform an unsafe operation. It also proves much more: we can predict precisely how the kernel will behave in every possible situation. seL4, a third-generation microkernel of L4 provenance, comprises 8,700 lines of C code and 600 lines of assembler. Its performance is comparable to other high-performance L4 kernels.
Variance analyses from invariance analyses
- In POPL’2007: Principles of Programming Languages
, 2007
"... An invariance assertion for a program location ℓ is a statement that always holds at ℓ during execution of the program. Program invariance analyses infer invariance assertions that can be useful when trying to prove safety properties. We use the term variance assertion to mean a statement that holds ..."
Abstract
-
Cited by 28 (7 self)
- Add to MetaCart
An invariance assertion for a program location ℓ is a statement that always holds at ℓ during execution of the program. Program invariance analyses infer invariance assertions that can be useful when trying to prove safety properties. We use the term variance assertion to mean a statement that holds between any state at ℓ and any previous state that was also at ℓ. This paper is concerned with the development of analyses for variance assertions and their application to proving termination and liveness properties. We describe a method of constructing program variance analyses from invariance analyses. If we change the underlying invariance analysis, we get a different variance analysis. We describe several applications of the method, including variance analyses using linear arithmetic and shape analysis. Using experimental results we demonstrate that these variance analyses give rise to a new breed of termination provers which are competitive with and sometimes better than today’s state-of-the-art termination provers.
The VeriFast Program Verifier
, 2008
"... This note describes a separation-logic-based approach for the specification and verification of safety properties of pointer-manipulating imperative programs. The programmer may declare inductive datatypes and primitive recursive functions for specification. Verification proceeds by symbolic executi ..."
Abstract
-
Cited by 23 (5 self)
- Add to MetaCart
This note describes a separation-logic-based approach for the specification and verification of safety properties of pointer-manipulating imperative programs. The programmer may declare inductive datatypes and primitive recursive functions for specification. Verification proceeds by symbolic execution using an abstract representation of memory as a separation logic assertion. Folding or unfolding abstract predicate assertions is performed through explicit ghost statements. Lemma functions enable inductive proofs of memory representation equivalences and facts about the primitive recursive functions. An SMT solver is used to solve queries over data values; an algorithm is described that prevents non-termination of the SMT solver while enabling reduction of any ground term. Since no significant search is performed by either the verifier or the SMT solver, verification time is predictable and low.
Types and Higher-Order Recursion Schemes for Verification of Higher-Order Programs
, 2009
"... We propose a new verification method for temporal properties of higher-order functional programs, which takes advantage of Ong’s recent result on the decidability of the model-checking problem for higher-order recursion schemes (HORS’s). A program is transformed to an HORS that generates a tree repr ..."
Abstract
-
Cited by 13 (3 self)
- Add to MetaCart
We propose a new verification method for temporal properties of higher-order functional programs, which takes advantage of Ong’s recent result on the decidability of the model-checking problem for higher-order recursion schemes (HORS’s). A program is transformed to an HORS that generates a tree representing all the possible event sequences of the program, and then the HORS is modelchecked. Unlike most of the previous methods for verification of higher-order programs, our verification method is sound and complete. Moreover, this new verification framework allows a smooth integration of abstract model checking techniques into verification of higher-order programs. We also present a type-based verification algorithm for HORS’s. The algorithm can deal with only a fragment of the properties expressed by modal μ-calculus, but the algorithm and its correctness proof are (arguably) much simpler than those of Ong’s game-semantics-based algorithm. Moreover, while the HORS model checking problem is n-EXPTIME in general, our algorithm is linear in the size of HORS, under the assumption that the sizes of types and specifications are bounded by a constant.
Proving That Non-Blocking Algorithms Don’t Block
"... A concurrent data-structure implementation is considered nonblocking if it meets one of three following liveness criteria: waitfreedom, lock-freedom,orobstruction-freedom. Developers of nonblocking algorithms aim to meet these criteria. However, to date their proofs for non-trivial algorithms have b ..."
Abstract
-
Cited by 8 (6 self)
- Add to MetaCart
A concurrent data-structure implementation is considered nonblocking if it meets one of three following liveness criteria: waitfreedom, lock-freedom,orobstruction-freedom. Developers of nonblocking algorithms aim to meet these criteria. However, to date their proofs for non-trivial algorithms have been only manual pencil-and-paper semi-formal proofs. This paper proposes the first fully automatic tool that allows developers to ensure that their algorithms are indeed non-blocking. Our tool uses rely-guarantee reasoning while overcoming the technical challenge of sound reasoning in the presence of interdependent liveness properties.
Proving Conditional Termination
"... Abstract. We describe a method for synthesizing reasonable underapproximations to weakest preconditions for termination—a long-standing open problem. The paper provides experimental evidence to demonstrate the usefulness of the new procedure. 1 ..."
Abstract
-
Cited by 4 (3 self)
- Add to MetaCart
Abstract. We describe a method for synthesizing reasonable underapproximations to weakest preconditions for termination—a long-standing open problem. The paper provides experimental evidence to demonstrate the usefulness of the new procedure. 1
Making Prophecies with Decision Predicates
"... We describe a new algorithm for proving temporal properties expressed in LTL of infinite-state programs. Our approach takes advantage of the fact that LTL properties can often be proved more efficiently using techniques usually associated with the branchingtime logic CTL than they can with native LT ..."
Abstract
-
Cited by 4 (4 self)
- Add to MetaCart
We describe a new algorithm for proving temporal properties expressed in LTL of infinite-state programs. Our approach takes advantage of the fact that LTL properties can often be proved more efficiently using techniques usually associated with the branchingtime logic CTL than they can with native LTL tools. The caveat is that, in certain instances, nondeterminism in the system’s transition relation can cause CTL methods to report counterexamples that are spurious with respect to the original LTL formula. To address this problem we describe an algorithm that, as it attempts to apply CTL proof methods, finds and then removes problematic nondeterminism via an analysis on the potentially spurious counterexamples. Problematic nondeterminism is characterized using decision predicates, and removed using a partial and symbolic determinization procedure that introduces new prophecy variables to predict the future outcome of these decisions. We demonstrate—using examples taken from the PostgreSQL database server, Apache web server, and Windows OS kernel—that our method can yield enormous performance improvements in comparison to known tools, allowing us to automatically prove properties of programs where we could not prove them before. 1.
Hard-to-Answer Questions about Code
"... To build new tools and programming languages that make it easier for professional software developers to create, debug, and understand code, it is helpful to better understand the questions that developers ask during coding activities. We surveyed professional software developers and asked them to l ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
To build new tools and programming languages that make it easier for professional software developers to create, debug, and understand code, it is helpful to better understand the questions that developers ask during coding activities. We surveyed professional software developers and asked them to list hard-to-answer questions that they had recently asked about code. 179 respondents reported 371 questions. We then clustered these questions into 21 categories and 94 distinct questions. The most frequently reported categories dealt with intent and rationale – what does this code do, what is it intended to do, and why was it done this way? Many questions described very specific situations – e.g., what does the code do when an error occurs, how to refactor without breaking callers, or the implications of a specific change on security. These questions revealed opportunities for both existing research tools to help developers and for developing new languages and tools that make answering these questions easier.
Automatically proving program termination
- In CAV
, 2007
"... Our goal in this book is to build sofware tools that automatically search for proofs of program termination in mathematical logic. However, before delving directly into strategies for automation, we must first introduce some notation and establish a basic foundation in the areas of program semantics ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
Our goal in this book is to build sofware tools that automatically search for proofs of program termination in mathematical logic. However, before delving directly into strategies for automation, we must first introduce some notation and establish a basic foundation in the areas of program semantics, logic and set theory. We must also discuss how programs can be proved terminating using manual techniques. The concepts and notation introduced in this chapter will be used throughout the remainder of the book. 1.1 Program termination and well-founded relations For the purpose of this book it is convenient to think of the text of a computer program as representing a relation that specifies the possible transitions that the program can make between configurations during execution. We call this the program’s transition relation. Program executions can be thought of as traversals starting from a starting configuration and then moving from configuration to configuration as allowed by the transition relation. A program is called terminating if all the executions allowed by the transition relation are finite. We call a program non-terminating if the transition relation allows for at least one infinite execution. Treating programs as relations is conveinant for our purpose, as in this setting proving program termination is equivliant to proving the program’s transition relation well-founded — thus giving us access to the numerous well established techniques from mathematical logic used to establish well-foundedness. In the next few sections we define some notation, discuss our representation for program configurations, and give some basic results related 3 4
Proving stabilization of biological systems
"... Abstract. We describe an efficient procedure for proving stabilization of biological systems modeled as qualitative networks or genetic regulatory networks. For scalability, our procedure uses modular proof techniques, where state-space exploration is applied only locally to small pieces of the syst ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
Abstract. We describe an efficient procedure for proving stabilization of biological systems modeled as qualitative networks or genetic regulatory networks. For scalability, our procedure uses modular proof techniques, where state-space exploration is applied only locally to small pieces of the system rather than the entire system as a whole. Our procedure exploits the observation that, in practice, the form of modular proofs can be restricted to a very limited set. For completeness, our technique falls back on a non-compositional counterexample search. Using our new procedure, we have solved a number of challenging published examples, including: a 3-D model of the mammalian epidermis; a model of metabolic networks operating in type-2 diabetes; a model of fate determination of vulval precursor cells in the C. elegans worm; and a model of pair-rule regulation during segmentation in the Drosophila embryo. Our results show many orders of magnitude speedup in cases where previous stabilization proving techniques were known to succeed, and new results in cases where tools had previously failed. 1

