Results 11  20
of
20
Separation logic adapted for proofs by rewriting
"... Abstract. We present a formalisation of separation logic which, by avoiding the use of existential quantifiers, allows proofs that only use standard equational rewriting methods as found in offtheshelf theorem provers. This proof automation is sufficiently strong to free the user from dealing with ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
(Show Context)
Abstract. We present a formalisation of separation logic which, by avoiding the use of existential quantifiers, allows proofs that only use standard equational rewriting methods as found in offtheshelf theorem provers. This proof automation is sufficiently strong to free the user from dealing with lowlevel details in proofs of functional correctness. The work presented here has been implemented in HOL4 and ACL2. It is illustrated on a standard example (reversal of a linkedlist). 1
Mirrorshard: Proof by computational reflection with verified hints
 CoRR
"... We describe a method for building composable and extensible verification procedures within the Coq proof assistant. Unlike traditional methods that rely on runtime generation and checking of proofs, we use verifiedcorrect procedures with Coq soundness proofs. Though they are internalized in Coq’ ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
(Show Context)
We describe a method for building composable and extensible verification procedures within the Coq proof assistant. Unlike traditional methods that rely on runtime generation and checking of proofs, we use verifiedcorrect procedures with Coq soundness proofs. Though they are internalized in Coq’s logic, our provers support sound extension by users with hints over new domains, enabling automated reasoning about userdefined abstract predicates. We maintain soundness by developing an architecture for modular packaging, construction, and composition of hint databases, which had previously only been implemented in Coq at the level of its dynamically typed, proofgenerating tactic language. Our provers also include rich handling of unification variables, enabling integration with other tacticbased deduction steps within Coq. We have implemented our techniques in MirrorShard, an opensource framework for reflective verification. We demonstrate its applicability by instantiating it to separation logic in order to reason about imperative program verification. 1.
Final Report for AOARD Grant #FA23861114070 Formal System Verification Extension
, 2011
"... The AOARD project #FA23861114070 aims at providing a provably correct initialiser of componentised systems. Taking as input a description of the desired components and the desired authorised communication between them, the initialiser sets up the system and provides a proof that the resulting con ..."
Abstract
 Add to MetaCart
(Show Context)
The AOARD project #FA23861114070 aims at providing a provably correct initialiser of componentised systems. Taking as input a description of the desired components and the desired authorised communication between them, the initialiser sets up the system and provides a proof that the resulting concrete machine state of the system matches the desired authority state. Within the scope of this project, we provide (1) a formal specification of the initialiser, in terms of the steps needed to create the components and their communication channels; and (2) substantial progress towards a formal proof that this specification is correct in that it either fails safely or produces the desired state. This document is the final report of the project, presenting its scientific outcomes. Namely, we have completed the initialiser specification, we have created a verification framework enabling modular reasoning and proofs about the initialiser, and we have progressed substantially on the
Annual Report for AOARD Grant #FA23861114070 Formal System Verification Extension
, 2011
"... The AOARD project #FA23861114070 aims at providing a provably correct initialiser of componentised systems. Taking as input a description of the desired components and the desired authorised communication between them, the initialiser sets up the system and provides a proof that the resulting con ..."
Abstract
 Add to MetaCart
(Show Context)
The AOARD project #FA23861114070 aims at providing a provably correct initialiser of componentised systems. Taking as input a description of the desired components and the desired authorised communication between them, the initialiser sets up the system and provides a proof that the resulting concrete machine state of the system matches the desired authority state. Within the scope of this project, we provide (1) a formal specification of the initialiser, in terms of the steps needed to create the components and their communication channels; and (2) a formal proof that this specification is correct in that it either fails safely or produces the desired state. This document is an annual report of the project, presenting the status of the work to date. Namely, we have written the initialiser specification, we have set up a verification framework enabling modular reasoning and proofs, and we have progressed substantially on the proof.
A Developeroriented Hoare Logic
 PSPL 2010
, 2010
"... Even with current automated reasoning technology, full functional verification requires human interaction to guide the proof: assignments to ghost variables (e.g. [1]) or intermediate assertions (e.g. [17]) need to be provided, and sometimes the prover’s deductions need to be examined in detail (e.g ..."
Abstract
 Add to MetaCart
(Show Context)
Even with current automated reasoning technology, full functional verification requires human interaction to guide the proof: assignments to ghost variables (e.g. [1]) or intermediate assertions (e.g. [17]) need to be provided, and sometimes the prover’s deductions need to be examined in detail (e.g. [1, §7],[13]). Indeed, some authors have argued that the developer’s understanding will be necessary regardless of advances in automation (e.g. [17, §7.2][8, §4.3][2, §1.2]). For effective interaction, the user has to understand the generated verification conditions. While it is possible to relate them back to the source code by suitable highlights and annotations (e.g. [4, 9]), this approach does not cover the verification conditions themselves. For instance, the conditions usually express sideeffects in the program by substitutions (e.g. [4, §4.2]), which in a weakest precondition calculus relate only loosely to a developer’s view on the code. We therefore propose to design the Hoare logic and verification environment itself to increase the developer’s understanding of the verification process. Taking lightweight separation [5, 6, 7] as the basis, this paper presents a suite of verification tools developed around that method and their application to case studies. Although the language treated is a C dialect with a finite byteaddressed
Mostly Sound Type System Improves a Foundational Program Verifier
"... Abstract. We integrate a verified typechecker with a verified program logic for the C language, proved sound with respect to the operational semantics of the CompCert verified optimizing C compiler. The C language is known to not be typesafe but we show the value of a provably mostly sound type sys ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract. We integrate a verified typechecker with a verified program logic for the C language, proved sound with respect to the operational semantics of the CompCert verified optimizing C compiler. The C language is known to not be typesafe but we show the value of a provably mostly sound type system: integrating the typechecker with the program logic makes the logic significantly more usable. The computational nature of our typechecker (within Coq) makes program proof much more efficient. We structure the system so that symbolic execution—even tactical (nonreflective) symbolic execution—can keep the type context and typechecking always in reified form, to avoid expensive rereification. 1
ECEASST Highlevel Proofs about Lowlevel Programs
"... Abstract: Functional verification of lowlevel code requires abstractions over the memory model to be effective, since the number of sideconditions induced by byteaddressed memory is prohibitive even with modern automated reasoners. We propose a flexible solution to this challenge: assertions con ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract: Functional verification of lowlevel code requires abstractions over the memory model to be effective, since the number of sideconditions induced by byteaddressed memory is prohibitive even with modern automated reasoners. We propose a flexible solution to this challenge: assertions contain explicit memory layouts which carry the necessary sideconditions as invariants. The memoryrelated proof obligations arising during verification can then be solved using specialized automatic proof procedures. The remaining verification conditions about the content of data structures directly reflect a developer’s understanding. The development is formalized in Isabelle/HOL.
Formal Specification with JML
, 2014
"... This text is a general, self contained, and tool independent introduction into the Java Modeling Language, JML. It is a preview of a chapter planned to appear in a book about the KeY approach and tool to the verification of Java software. JML is the dominating starting point of KeY style Java verifi ..."
Abstract
 Add to MetaCart
This text is a general, self contained, and tool independent introduction into the Java Modeling Language, JML. It is a preview of a chapter planned to appear in a book about the KeY approach and tool to the verification of Java software. JML is the dominating starting point of KeY style Java verification. However, this paper does not in any way depend on any tool nor verification methodology. Other chapters in this book talk about the usage of JML in KeY style verification. Here, we only refer to KeY in very few places, without relying on it. This introduction is written for all readers with an interest in formal specification of software in general, and anyone who wants to learn about the JML approach to specification in particular. The authors appreciate any comments or questions that help to improve