DOCSLIB.ORG

Separation Logic and Concurrency (OPLSS 2016) Draft of July 22, 2016

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Separation Logic and Concurrency (OPLSS 2016) Draft of July 22, 2016 Separation Logic and Concurrency (OPLSS 2016) Draft of July 22, 2016 Aleks Nanevski IMDEA Software Institute [email protected] 2 Contents 1 Separation logic for sequential programs7 1.1 Motivating example.........................................7 1.2 Splitting the heap and definition of separation connectives.................... 10 1.3 Separation Hoare Logic: properties and rules........................... 13 1.4 Functional programming formulation................................ 17 1.5 Pointed assertions and Partial Commutative Monoids (PCMs).................. 22 2 Concurrency and the Resource Invariant Method 25 2.1 Parallel composition and Owicki-Gries-O'Hearn resource invariants............... 25 2.2 Auxiliary state............................................ 29 2.3 Subjective auxiliary state...................................... 31 2.4 Subjective proof outlines....................................... 35 2.5 Example: coarse-grained set with disjoint interference...................... 39 3 Fine-grained Concurrent Data Structures 43 3.1 Treiber's stack............................................ 43 3.2 Method specification......................................... 45 3.3 The resource definition: resource invariant and transition.................... 49 3.4 Stability................................................ 51 3.5 Auxiliary code and primitive actions................................ 52 3.6 New rules............................................... 56 4 Non-Linearizable Structures and Structures with Sharing 61 4.1 Exchanger............................................... 61 4.1.1 Auxiliary state and exchanger specification........................ 63 4.1.2 Resource invariant, transitions, atomics.......................... 64 4.1.3 Proof outline......................................... 69 4.2 Spanning tree............................................. 71 4.2.1 Auxiliary state and span specification............................ 73 4.2.2 Resource invariant, transitions, atomics.......................... 75 4.2.3 Proof outline......................................... 77 3 4 CONTENTS Introduction Separation logic, developed by O'Hearn, Reynolds and collaborators [15,23,28], has emerged as an effective logical framework for specifying and verifying pointer-manipulating programs. This course will cover the basic sequential separation logic, and then build on it to explain some of the main ideas behind the recent results in the verification of shared-memory concurrency. We first introduce separation logic in its standard formulation, to give the reader a foundation for inde- pendent study of this broad and active research field. We then proceed to reformulate this standard, to set us up for introducing ideas from cutting edge research on verification of shared-memory concurrent software. Though some of these cutting-edge ideas are highly experimental and still in their infancy, learning them will be beneficial to a reader who is looking to enter the research field of verification, concurrency, or a related topic. Through many examples, we will illustrate the specification and verification patterns that provide effective reasoning about lock-based and lock-free concurrent programs over pointer-based data structures and pro- grams, including linearizable and non-linearizable pointer structures and programs, and pointer structures with so-called "deep sharing", such as graphs. The presentation will be heavily bent towards showing how to carry out concrete proofs of concrete programs. The emphasis will be on analyzing the mathematical structure of the underlying problem that a program is trying to solve, and then translating the obtained insights into language and logic designs that enable effective program correctness proofs. We will not spend time on meta theory; proofs of soundness and/or completeness of the various presented formal systems are in the literature. Along the way, we will point out the many high-level connections between separation logic and type theory. In fact, the author believes that Separation Logic is essentially a type theory (of state), even though it was not actually discovered as such. For, if you start constructing a type theory for effects of state, and then continue to concurrency, your hand will be guided in a fairly straightforward path towards a formulation of separation logic. These notes will cover precisely a path of this form, almost exactly in the way that the author has traveled it, with collaborators: for sequential separation logic, Greg Morrisett, Lars Birkedal, Amal Ahmed, and for concurrency, Ruy Ley-Wild, Ilya Sergey, Anindya Banerjee and German Delbianco. 5 6 CONTENTS Chapter 1 Separation logic for sequential programs 1.1 Motivating example Separation logic is a form of Hoare logic, intended for reasoning about programs with pointers. Let us introduce it by means of an in-place list reversal example, a classic example taken from Reynolds [28]. The example begins with a singly-linked list in the heap, which it reverts in place by swinging, in order, the next pointer of each node to point not to the next, but to the previous node. reverse “ done Ð null; while pi ‰ nullq do t k Ð !pi ` 1q; i ` 1 :“ done; done Ð i; i Ð k; u Pictorially, revert modifies the first list below, into the second one. done i . done i We want to prove that if initially i points to a list whose contents is the sequence α0, then in the end, done points to rev α0. Here α0 is a mathematical list, i.e., an element of the inductive type list in ML or Haskell, defined with the constructors nil and :: (read cons): list “ nil | :: of nat ˆ list Thus, we use purely-functional lists to specify programs that manipulate pointer-based lists. In particular, 7 8 CHAPTER 1. SEPARATION LOGIC FOR SEQUENTIAL PROGRAMS to specify this program, we need the function rev, defined inductively on the size of the list: rev nil “ nil rev px :: xsq “ rev xs `` px :: nilq where `` is concatenation of lists, which is also easily defined by induction on xs, as follows. nil `` ys “ ys px :: xsq `` ys “ x :: pxs `` ysq To formally write the precondition that in the beginning i points to a list storing α0, and the postcondition that in the end done points to a list storing rev α0, we need a way to describe the state (or the heap) occupied by a singly-linked list storing some given mathematical sequence. We use a predicate is list with two input arguments: p and α. The first input argument, p, is the pointer heading the list, and the second input argument, α is the mathematical sequence that is being stored. is list p α We keep this predicate undefined for now, but will define it soon to say precisely that the current heap (which will remain implicit in the definition), stores a singly-linked list whose contents is α, starting from the pointer p. Then we would like to prove the following Hoare triple specification for reverse: tis list i αou reverse tis list done prev α0qu Now, i stores the initial head of the list and done stores the ending head of the list. But, if one looks a bit deeper into the loop of the program, rather than just the beginning and the ending state, then the variable i identifies the sub-list that remains to be reversed (i.e., pointer to the list node at which we currently are), and done identifies the sub-list that has already been reversed. What each iteration of the loop does, is move the next node from sub-list i to sub-list done. done i In program verification, one formally describes the behavior of loops by so-called loop invariants, i.e., properties that hold throughout the loop execution. In our particular case, the loop invariant should say something like the following (which is not quite right, but is close enough for a start). Dα β: is list i α ^ is list done β ^ rev α0 “ prev αq `` β Here, α and β are again purely-functional lists, describing the contents of the singly-linked lists headed at i and done. When we are at the beginning of the loop, then α “ α0 and β “ nil, as we didn't invert anything yet. So, we can see that the equation from the loop invariant trivially holds: rev α0 “ prev α0q `` nil: Moreover, the whole loop invariant can be trivially inferred from the precondition is list i α0 and the knowledge that done points to an empty list (i.e., done “ null). When we are at the end of the loop, then α “ nil and β “ rev α0, as we have inverted everything. So, the equation holds again: rev α0 “ prev nilq `` prev α0q: Moreover, from the loop invariant, and α “ nil, we can derive the postcondition is list done prev α0q. 1.1. MOTIVATING EXAMPLE 9 We also need to show that the above proposition is indeed a loop invariant; that is, it holds from one loop iteration to the next. Specifically, in this particular case, we should prove that the loop body satisfies the following property: if we start with i storing x::xs, and done stores ys, then when the iteration finishes, we have i storing xs and done storing x::ys. That is: tis list i px :: xsq ^ is list done ys ^ rev α0 “ rev px :: xsq `` ysu k Ð !pi ` 1q; i ` 1 :“ done; done Ð i; i Ð k; tis list i xs ^ is list done px :: ysq ^ rev α0 “ rev xs `` px :: ysqu Obviously, the equation about rev α0 in the postcondition will be easy. This equation, and the similar equation from the precondition, talk only about immutable mathematical entities αo, x, xs and ys. Thus, the equation from the precondition remains invariant under all the mutations of the program, and eventually, proves the equation from the postcondition, since we know, just from purely-functional properties of lists that rev px :: xsq `` ys “ rev xs `` px :: ysq: The difficulty in verifying this program is in establishing the other components of the postcondition, namely, is list i xs and is list done px :: ys, from the initial is list i px :: xsq that we have in the precondition. In fact, the difficulty, resolved by the main insights of separation logic, is in defining is list p α in such a way that we can work with these other component effectively.
Load more

Recommended publications
  • Lemma Functions for Frama-C: C Programs As Proofs
    Lemma Functions for Frama-C: C Programs as Proofs Grigoriy Volkov Mikhail Mandrykin Denis Efremov Faculty of Computer Science Software Engineering Department Faculty of Computer Science National Research University Ivannikov Institute for System Programming of the National Research University Higher School of Economics Russian Academy of Sciences Higher School of Economics Moscow, Russia Moscow, Russia Moscow, Russia [email protected] [email protected] [email protected] Abstract—This paper describes the development of to additionally specify loop invariants and termination an auto-active verification technique in the Frama-C expression (loop variants) in case the function under framework. We outline the lemma functions method analysis contains loops. Then the verification instrument and present the corresponding ACSL extension, its implementation in Frama-C, and evaluation on a set generates verification conditions (VCs), which can be of string-manipulating functions from the Linux kernel. separated into categories: safety and behavioral ones. We illustrate the benefits our approach can bring con- Safety VCs are responsible for runtime error checks for cerning the effort required to prove lemmas, compared known (modeled) types, while behavioral VCs represent to the approach based on interactive provers such as the functional correctness checks. All VCs need to be Coq. Current limitations of the method and its imple- mentation are discussed. discharged in order for the function to be considered fully Index Terms—formal verification, deductive verifi- proved (totally correct). This can be achieved either by cation, Frama-C, auto-active verification, lemma func- manually proving all VCs discharged with an interactive tions, Linux kernel prover (i. e., Coq, Isabelle/HOL or PVS) or with the help of automatic provers.
    [Show full text]
  • A Program Logic for First-Order Encapsulated Webassembly
    A Program Logic for First-Order Encapsulated WebAssembly Conrad Watt University of Cambridge, UK [email protected] Petar Maksimović Imperial College London, UK; Mathematical Institute SASA, Serbia [email protected] Neelakantan R. Krishnaswami University of Cambridge, UK [email protected] Philippa Gardner Imperial College London, UK [email protected] Abstract We introduce Wasm Logic, a sound program logic for first-order, encapsulated WebAssembly. We design a novel assertion syntax, tailored to WebAssembly’s stack-based semantics and the strong guarantees given by WebAssembly’s type system, and show how to adapt the standard separation logic triple and proof rules in a principled way to capture WebAssembly’s uncommon structured control flow. Using Wasm Logic, we specify and verify a simple WebAssembly B-tree library, giving abstract specifications independent of the underlying implementation. We mechanise Wasm Logic and its soundness proof in full in Isabelle/HOL. As part of the soundness proof, we formalise and fully mechanise a novel, big-step semantics of WebAssembly, which we prove equivalent, up to transitive closure, to the original WebAssembly small-step semantics. Wasm Logic is the first program logic for WebAssembly, and represents a first step towards the creation of static analysis tools for WebAssembly. 2012 ACM Subject Classification Theory of computation Ñ separation logic Keywords and phrases WebAssembly, program logic, separation logic, soundness, mechanisation Acknowledgements We would like to thank the reviewers, whose comments were valuable in improving the paper. All authors were supported by the EPSRC Programme Grant ‘REMS: Rigorous Engineering for Mainstream Systems’ (EP/K008528/1).
    [Show full text]
  • Dafny: an Automatic Program Verifier for Functional Correctness K
    Dafny: An Automatic Program Verifier for Functional Correctness K. Rustan M. Leino Microsoft Research [email protected] Abstract Traditionally, the full verification of a program’s functional correctness has been obtained with pen and paper or with interactive proof assistants, whereas only reduced verification tasks, such as ex- tended static checking, have enjoyed the automation offered by satisfiability-modulo-theories (SMT) solvers. More recently, powerful SMT solvers and well-designed program verifiers are starting to break that tradition, thus reducing the effort involved in doing full verification. This paper gives a tour of the language and verifier Dafny, which has been used to verify the functional correctness of a number of challenging pointer-based programs. The paper describes the features incorporated in Dafny, illustrating their use by small examples and giving a taste of how they are coded for an SMT solver. As a larger case study, the paper shows the full functional specification of the Schorr-Waite algorithm in Dafny. 0 Introduction Applications of program verification technology fall into a spectrum of assurance levels, at one extreme proving that the program lives up to its functional specification (e.g., [8, 23, 28]), at the other extreme just finding some likely bugs (e.g., [19, 24]). Traditionally, program verifiers at the high end of the spectrum have used interactive proof assistants, which require the user to have a high degree of prover expertise, invoking tactics or guiding the tool through its various symbolic manipulations. Because they limit which program properties they reason about, tools at the low end of the spectrum have been able to take advantage of satisfiability-modulo-theories (SMT) solvers, which offer some fixed set of automatic decision procedures [18, 5].
    [Show full text]
  • Separation Logic: a Logic for Shared Mutable Data Structures
    Separation Logic: A Logic for Shared Mutable Data Structures John C. Reynolds∗ Computer Science Department Carnegie Mellon University [email protected] Abstract depends upon complex restrictions on the sharing in these structures. To illustrate this problem,and our approach to In joint work with Peter O’Hearn and others, based on its solution,consider a simple example. The following pro- early ideas of Burstall, we have developed an extension of gram performs an in-place reversal of a list: Hoare logic that permits reasoning about low-level impera- tive programs that use shared mutable data structure. j := nil ; while i = nil do The simple imperative programming language is ex- (k := [i +1];[i +1]:=j ; j := i ; i := k). tended with commands (not expressions) for accessing and modifying shared structures, and for explicit allocation and (Here the notation [e] denotes the contents of the storage at deallocation of storage. Assertions are extended by intro- address e.) ducing a “separating conjunction” that asserts that its sub- The invariant of this program must state that i and j are formulas hold for disjoint parts of the heap, and a closely lists representing two sequences α and β such that the re- related “separating implication”. Coupled with the induc- flection of the initial value α0 can be obtained by concate- tive definition of predicates on abstract data structures, this nating the reflection of α onto β: extension permits the concise and flexible description of ∃ ∧ ∧ † †· structures with controlled sharing. α, β. list α i list β j α0 = α β, In this paper, we will survey the current development of this program logic, including extensions that permit unre- where the predicate list α i is defined by induction on the stricted address arithmetic, dynamically allocated arrays, length of α: and recursive procedures.
    [Show full text]
  • Pointer Programs, Separation Logic
    Chapter 6 Pointer Programs, Separation Logic The goal of this section is to drop the hypothesis that we have until now, that is, references are not values of the language, and in particular there is nothing like a reference to a reference, and there is no way to program with data structures that can be modified in-place, such as records where fields can be assigned directly. There is a fundamental difference of semantics between in-place modification of a record field and the way we modeled records in Chapter 4. The small piece of code below, in the syntax of the C programming language, is a typical example of the kind of programs we want to deal with in this chapter. typedef struct L i s t { i n t data; list next; } ∗ l i s t ; list create( i n t d , l i s t n ) { list l = (list)malloc( sizeof ( struct L i s t ) ) ; l −>data = d ; l −>next = n ; return l ; } void incr_list(list p) { while ( p <> NULL) { p−>data++; p = p−>next ; } } Like call by reference, in-place assignment of fields is another source of aliasing issues. Consider this small test program void t e s t ( ) { list l1 = create(4,NULL); list l2 = create(7,l1); list l3 = create(12,l1); assert ( l3 −>next−>data == 4 ) ; incr_list(l2); assert ( l3 −>next−>data == 5 ) ; } which builds the following structure: 63 7 4 null 12 the list node l1 is shared among l2 and l3, hence the call to incr_list(l2) modifies the second node of list l3.
    [Show full text]
  • Automating Separation Logic with Trees and Data
    Automating Separation Logic with Trees and Data Ruzica Piskac1, Thomas Wies2, and Damien Zufferey3 1Yale University 2New York University 3MIT CSAIL Abstract. Separation logic (SL) is a widely used formalism for verifying heap manipulating programs. Existing SL solvers focus on decidable fragments for list-like structures. More complex data structures such as trees are typically un- supported in implementations, or handled by incomplete heuristics. While com- plete decision procedures for reasoning about trees have been proposed, these procedures suffer from high complexity, or make global assumptions about the heap that contradict the separation logic philosophy of local reasoning. In this pa- per, we present a fragment of classical first-order logic for local reasoning about tree-like data structures. The logic is decidable in NP and the decision proce- dure allows for combinations with other decidable first-order theories for reason- ing about data. Such extensions are essential for proving functional correctness properties. We have implemented our decision procedure and, building on earlier work on translating SL proof obligations into classical logic, integrated it into an SL-based verification tool. We successfully used the tool to verify functional correctness of tree-based data structure implementations. 1 Introduction Separation logic (SL) [30] has proved useful for building scalable verification tools for heap-manipulating programs that put no or very little annotation burden on the user [2,5,6,12,15,40]. The high degree of automation of these tools relies on solvers for checking entailments between SL assertions. Typically, the focus is on decidable frag- ments such as separation logic of linked lists [4] for which entailment can be checked efficiently [10, 31].
    [Show full text]
  • Automatic Verification of Embedded Systems Using Horn Clause Solvers
    IT 19 021 Examensarbete 30 hp Juni 2019 Automatic Verification of Embedded Systems Using Horn Clause Solvers Anoud Alshnakat Institutionen för informationsteknologi Department of Information Technology Abstract Automatic Verification of Embedded Systems Using Horn Clause Solvers Anoud Alshnakat Teknisk- naturvetenskaplig fakultet UTH-enheten Recently, an increase in the use of safety-critical embedded systems in the automotive industry has led to a drastic up-tick in vehicle software and code complexity. Failure Besöksadress: in safety-critical applications can cost lives and money. With the ongoing development Ångströmlaboratoriet Lägerhyddsvägen 1 of complex vehicle software, it is important to assess and prove the correctness of Hus 4, Plan 0 safety properties using verification and validation methods. Postadress: Software verification is used to guarantee software safety, and a popular approach Box 536 751 21 Uppsala within this field is called deductive static methods. This methodology has expressive annotations, and tends to be feasible even on larger software projects, but developing Telefon: the necessary code annotations is complicated and costly. Software-based model 018 – 471 30 03 checking techniques require less work but are generally more restricted with respect Telefax: to expressiveness and software size. 018 – 471 30 00 This thesis is divided into two parts. The first part, related to a previous study where Hemsida: the authors verified an electronic control unit using deductive verification techniques. http://www.teknat.uu.se/student We continued from this study by investigating the possibility of using two novel tools developed in the context of software-based model checking: SeaHorn and Eldarica. The second part investigated the concept of automatically inferring code annotations from model checkers to use them in deductive verification tools.
    [Show full text]
  • Formal Verification of C Systems Code
    J Autom Reasoning (2009) 42:125–187 DOI 10.1007/s10817-009-9120-2 Formal Verification of C Systems Code Structured Types, Separation Logic and Theorem Proving Harvey Tuch Received: 26 February 2009 / Accepted: 26 February 2009 / Published online: 2 April 2009 © Springer Science + Business Media B.V. 2009 Abstract Systems code is almost universally written in the C programming language or a variant. C has a very low level of type and memory abstraction and formal reasoning about C systems code requires a memory model that is able to capture the semantics of C pointers and types. At the same time, proof-based verification demands abstraction, in particular from the aliasing and frame problems. In this paper we present a study in the mechanisation of two proof abstractions for pointer program verification in the Isabelle/HOL theorem prover, based on a low-level memory model for C. The language’s type system presents challenges for the multiple independent typed heaps (Burstall-Bornat) and separation logic proof techniques. In addition to issues arising from explicit value size/alignment, padding, type-unsafe casts and pointer address arithmetic, structured types such as C’s arrays and structs are problematic due to the non-monotonic nature of pointer and lvalue validity in the presence of the unary &-operator. For example, type-safe updates through pointers to fields of a struct break the independence of updates across typed heaps or ∧∗-conjuncts. We provide models and rules that are able to cope with these language features and types, eschewing common over-simplifications and utilising expressive shallow embeddings in higher-order logic.
    [Show full text]
  • A Separation Logic for Concurrent Randomized Programs
    A Separation Logic for Concurrent Randomized Programs JOSEPH TASSAROTTI, Carnegie Mellon University, USA ROBERT HARPER, Carnegie Mellon University, USA We present Polaris, a concurrent separation logic with support for probabilistic reasoning. As part of our logic, we extend the idea of coupling, which underlies recent work on probabilistic relational logics, to the setting of programs with both probabilistic and non-deterministic choice. To demonstrate Polaris, we verify a variant of a randomized concurrent counter algorithm and a two-level concurrent skip list. All of our results have been mechanized in Coq. CCS Concepts: • Theory of computation → Separation logic; Program verification; Additional Key Words and Phrases: separation logic, concurrency, probability ACM Reference Format: Joseph Tassarotti and Robert Harper. 2019. A Separation Logic for Concurrent Randomized Programs. Proc. ACM Program. Lang. 3, POPL, Article 64 (January 2019), 31 pages. https://doi.org/10.1145/3290377 1 INTRODUCTION Many concurrent algorithms use randomization to reduce contention and coordination between threads. Roughly speaking, these algorithms are designed so that if each thread makes a local random choice, then on average the aggregate behavior of the whole system will have some good property. For example, probabilistic skip lists [53] are known to work well in the concurrent setting [25, 32], because threads can independently insert nodes into the skip list without much synchronization. In contrast, traditional balanced tree structures are difficult to implement in a scalable way because re-balancing operations may require locking access to large parts of the tree. However, concurrent randomized algorithms are difficult to write and reason about. The useof just concurrency or randomness alone makes it hard to establish the correctness of an algorithm.
    [Show full text]
  • Arxiv:2102.00329V1 [Cs.LO] 30 Jan 2021 Interfering Effects
    A Quantum Interpretation of Bunched Logic for Quantum Separation Logic Li Zhou Gilles Barthe Max Planck Institute for Security and Privacy Max Planck Institute for Security and Privacy; IMDEA Software Institute Justin Hsu Mingsheng Ying University of Wisconsin–Madison University of Technology Sydney; Institute of Software, Chinese Academy of Sciences; Tsinghua University Nengkun Yu University of Technology Sydney Abstract—We propose a model of the substructural logic of Quantum computation is another domain where the ideas Bunched Implications (BI) that is suitable for reasoning about of separation logic seem relevant. Recent work [10], [11] quantum states. In our model, the separating conjunction of suggests that reasoning about resources (in particular, entan- BI describes separable quantum states. We develop a program glement – a resource unique in the quantum world) can bring logic where pre- and post-conditions are BI formulas describing similar benefits to quantum computing and communications. quantum states—the program logic can be seen as a counter- Motivated by this broad perspective, we propose a quan- part of separation logic for imperative quantum programs. We tum model of BI and develop a novel separation logic for exercise the logic for proving the security of quantum one-time quantum programs. Our development is guided by concrete pad and secret sharing, and we show how the program logic examples of quantum algorithms and security protocols. can be used to discover a flaw in Google Cirq’s tutorial on the Motivating Local Reasoning for Quantum Programs: Variational Quantum Algorithm (VQA). Quantum Machine Learning [12], [13] and VQAs (Vari- ational Quantum Algorithms) [14], [15] are new classes 1.
    [Show full text]
  • Steel: Proof-Oriented Programming in a Dependently Typed Concurrent Separation Logic
    Steel: Proof-Oriented Programming in a Dependently Typed Concurrent Separation Logic AYMERIC FROMHERZ, Carnegie Mellon University, USA ASEEM RASTOGI, Microsoft Research, India NIKHIL SWAMY, Microsoft Research, USA SYDNEY GIBSON, Carnegie Mellon University, USA GUIDO MARTÍNEZ, CIFASIS-CONICET, Argentina DENIS MERIGOUX, Inria Paris, France TAHINA RAMANANANDRO, Microsoft Research, USA Steel is a language for developing and proving concurrent programs embedded in F¢, a dependently typed programming language and proof assistant. Based on SteelCore, a concurrent separation logic (CSL) formalized in F¢, our work focuses on exposing the proof rules of the logic in a form that enables programs and proofs to be effectively co-developed. Our main contributions include a new formulation of a Hoare logic of quintuples involving both separation logic and first-order logic, enabling efficient verification condition (VC) generation and proof discharge using a combination of tactics and SMT solving. We relate the VCs produced by our quintuple system to solving a system of associativity-commutativity (AC) unification constraints and develop tactics to (partially) solve these constraints using AC-matching modulo SMT-dischargeable equations. Our system is fully mechanized and implemented in F¢. We evaluate it by developing several verified programs and libraries, including various sequential and concurrent linked data structures, proof libraries, and a library for 2-party session types. Our experience leads us to conclude that our system enables a mixture of automated and interactive proof, making it productive to build programs foundationally verified against a highly expressive, state-of-the-art CSL. CCS Concepts: • Theory of computation ! Separation logic; Program verification; • Software and its engineering ! Formal software verification.
    [Show full text]
  • Introduction to C Program Proof with Frama-C and Its WP Plugin
    Allan Blanchard Introduction to C program proof with Frama-C and its WP plugin July 1, 2020 0 Contents 1. Introduction 4 2. Program proof and our tool for this tutorial: Frama-C 6 2.1. Program proof . 6 2.1.1. Ensure program reliability . 6 2.1.2. A bit of context . 8 2.1.3. Hoare triples . 10 2.1.4. Weakest precondition calculus . 11 2.2. Frama-C . 11 2.2.1. Frama-C? WP? . 12 2.2.2. Installation . 13 2.2.3. Verify installation . 15 2.2.4. (Bonus) Some more provers . 17 3. Function contract 21 3.1. Contract definition . 21 3.1.1. Postcondition . 22 3.1.2. Precondition . 29 3.1.3. Exercises . 33 3.2. Well specified function . 36 3.2.1. Correctly write what we expect . 36 3.2.2. Inconsistent preconditions . 37 3.2.3. Pointers . 38 3.2.4. Writing the right contract . 45 3.2.5. Exercises . 46 3.3. Behaviors . 49 3.3.1. Exercises . 51 3.4. WP Modularity . 54 3.4.1. Exercises . 56 4. Basic instructions and control structures 61 4.0.1. Inference rules . 61 4.0.2. Hoare triples . 62 4.1. Basic concepts . 63 4.1.1. Assignment . 63 4.1.2. Composition of statements . 67 4.1.3. Conditional rule . 68 4.1.4. Bonus Stage - Consequence rule . 70 4.1.5. Bonus Stage - Constancy rule . 71 4.1.6. Exercices . 72 1 Contents 4.2. Loops . 74 4.2.1. Induction and invariant . 74 4.2.2. The assigns clause … for loops .
    [Show full text]