Results 1  10
of
29
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, machinechecked verification of the seL4 microkernel from an abstract specification down to its C implementation. We assume correctness of ..."
Abstract

Cited by 147 (33 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, machinechecked 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, generalpurpose operatingsystem kernel. Functional correctness means here that the implementation always strictly follows our highlevel 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 thirdgeneration microkernel of L4 provenance, comprises 8,700 lines of C code and 600 lines of assembler. Its performance is comparable to other highperformance 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 37 (11 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 stateoftheart termination provers.
The VeriFast Program Verifier
, 2008
"... This note describes a separationlogicbased approach for the specification and verification of safety properties of pointermanipulating imperative programs. The programmer may declare inductive datatypes and primitive recursive functions for specification. Verification proceeds by symbolic executi ..."
Abstract

Cited by 33 (5 self)
 Add to MetaCart
This note describes a separationlogicbased approach for the specification and verification of safety properties of pointermanipulating 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 nontermination 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 HigherOrder Recursion Schemes for Verification of HigherOrder Programs
, 2009
"... We propose a new verification method for temporal properties of higherorder functional programs, which takes advantage of Ong’s recent result on the decidability of the modelchecking problem for higherorder recursion schemes (HORS’s). A program is transformed to an HORS that generates a tree repr ..."
Abstract

Cited by 32 (7 self)
 Add to MetaCart
We propose a new verification method for temporal properties of higherorder functional programs, which takes advantage of Ong’s recent result on the decidability of the modelchecking problem for higherorder 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 higherorder 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 higherorder programs. We also present a typebased 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 gamesemanticsbased algorithm. Moreover, while the HORS model checking problem is nEXPTIME 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 NonBlocking Algorithms Don’t Block
"... A concurrent datastructure implementation is considered nonblocking if it meets one of three following liveness criteria: waitfreedom, lockfreedom,orobstructionfreedom. Developers of nonblocking algorithms aim to meet these criteria. However, to date their proofs for nontrivial algorithms have b ..."
Abstract

Cited by 14 (5 self)
 Add to MetaCart
A concurrent datastructure implementation is considered nonblocking if it meets one of three following liveness criteria: waitfreedom, lockfreedom,orobstructionfreedom. Developers of nonblocking algorithms aim to meet these criteria. However, to date their proofs for nontrivial algorithms have been only manual pencilandpaper semiformal proofs. This paper proposes the first fully automatic tool that allows developers to ensure that their algorithms are indeed nonblocking. Our tool uses relyguarantee 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 longstanding open problem. The paper provides experimental evidence to demonstrate the usefulness of the new procedure. 1 ..."
Abstract

Cited by 11 (3 self)
 Add to MetaCart
Abstract. We describe a method for synthesizing reasonable underapproximations to weakest preconditions for termination—a longstanding open problem. The paper provides experimental evidence to demonstrate the usefulness of the new procedure. 1
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 10 (2 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 wellfounded 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 nonterminating 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 wellfounded — thus giving us access to the numerous well established techniques from mathematical logic used to establish wellfoundedness. In the next few sections we define some notation, discuss our representation for program configurations, and give some basic results related 3 4
Making Prophecies with Decision Predicates
"... We describe a new algorithm for proving temporal properties expressed in LTL of infinitestate 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 7 (7 self)
 Add to MetaCart
We describe a new algorithm for proving temporal properties expressed in LTL of infinitestate 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.
HardtoAnswer 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 6 (3 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 hardtoanswer 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.
Modular ranking abstraction
"... Predicate abstraction has become one of the most successful methodologies for proving safety properties of programs. Recently, several abstraction methodologies have been proposed for proving liveness properties. This paper studies “ranking abstraction” where a program is augmented by a nonconstrai ..."
Abstract

Cited by 6 (3 self)
 Add to MetaCart
Predicate abstraction has become one of the most successful methodologies for proving safety properties of programs. Recently, several abstraction methodologies have been proposed for proving liveness properties. This paper studies “ranking abstraction” where a program is augmented by a nonconstraining progress monitor based on a set of ranking functions, and further abstracted by predicateabstraction, to allow for automatic verification of progress properties. Unlike many liveness methodologies, the augmentation does not require a complete ranking function that is expected to decrease with each helpful step. Rather, adequate userprovided inputs are component rankings from which a complete ranking function may be automatically formed. The premise of the paper is an analogy between the methods of ranking abstraction and predicate abstraction, one ingredient of which is refinement: When predicate abstraction fails, one can refine it. When ranking abstraction fails, one must determine whether the predicate abstraction, or the ranking abstraction, needs be refined. The paper presents