INRIA Saclay – ˆ Universit´ e de Paris-Sud 11 Ile-de-France Centre d’Orsay Equipe ProVal V´ erification de programmes avec pointeurs ` a l’aide de r´ egions et de permissions Romain Bardou pr´ esent´ ee le 14 octobre 2011 devant le jury compos´ e de : MM. Peter M¨ uller Fran¸ cois Pottier Jean Goubault-Larrecq Burkhart Wolff Claude March´ e 1 / 51
There are two ways to write error-free programs; only the third one works. — Alan J. Perlis 2 / 51
Program Verification programming needs thinking verification is tedious human machine thinking good bad repetition bad good parts of verification are repetitive = ⇒ let the human program and the machine verify Introduction Program Verification 3 / 51
Trade-Off: Automation vs. Expressiveness properties: “ x is always an integer” automated (typing) “ x is always an odd integer” requires reasoning (annotations) “for all i , a [ i ] is prime” requires more reasoning (proofs) Introduction Program Verification 4 / 51
Deductive Program Verification program + specification verification conditions automatic theorem provers proof assistants (Alt-Ergo, Simplify, Z3, CVC3, ...) (Coq, Isabelle, ...) Introduction Deductive Program Verification 5 / 51
Deductive Program Verification expressiveness: ◮ mainstream programming languages (C, Java...) ◮ (at least) first-order logic for specifications automation: ◮ specification written by hand ◮ automatic provers for simple verification conditions ◮ proof assistants for difficult verification conditions Introduction Deductive Program Verification 6 / 51
Deductive Verification: Example void max( int i, int j) /*@ ensures \result >= i && \result >= j */ { if (i > j) return i; else return j; } verification conditions: i > j ⇒ i ≥ i ∧ i ≥ j ¬ ( i > j ) ⇒ j ≥ i ∧ j ≥ j Introduction Deductive Program Verification 7 / 51
Pointers pointer = variable containing a location pointed value = value stored at location x loc · · · · · · 42 loc Introduction Pointers 8 / 51
Pointer Aliasing *p = 42; *q = 69; /*@ assert *p = 42; */ what if p = q ? verification conditions? Introduction Pointers 9 / 51
Data Invariants: Examples handy specification tool “this array is always sorted” “this tree is a search tree” “this tree is well-balanced” “rocket speed is always positive” Introduction Data Invariants 10 / 51
Related Work ownership ◮ Data Groups [Leino 1998] ◮ Ownership Types [Clarke, Potter, Noble 1998] ◮ Spec# Methodology [Barnett et al. 2004] ◮ Universe Types [Dietl, Muller 2005] ◮ Considerate Reasoning [Summers, Drossopoulou 2010] alias control ◮ Separation Logic [Reynolds 2002] ◮ Regional Logic [Banerjee, Naumann, Rosenberg 2008] ◮ (implicit) Dynamic Frames [Kassios 2006; Smans et al. 2009] Regions, Permissions / Capabilities, Alias Types... Introduction Contributions 11 / 51
Main Contribution A type system using regions and permissions to structure the heap in a modular fashion, control pointer aliasing and data invariants and produce proof obligations where pointers are separated. implemented as a tool called Capucine Introduction Contributions 12 / 51
Contents Introduction The Capucine Language Classes Regions Permissions Operations Ownership Coherence Preservation Conclusion Computing Verification Conditions Conclusion The Capucine Language 13 / 51
Classes class = record + invariant + owned regions class Pair { fst : int ; snd : int ; invariant fst < snd ; } The Capucine Language Classes 14 / 51
Pointer Types and Regions region = set of locations memory structured using regions the type of a pointer [ ρ ] gives its region ρ fun incrPair [ r : Pair ] ( p : [ r ]): unit { p . fst ← p . fst + 1; p . snd ← p . snd + 1; } The Capucine Language Regions 15 / 51
Life Cycle of Pointers ◮ allocation ◮ initialization of fields ◮ verification of the invariant ◮ insertion into a data structure ◮ update + invariant preservation permissions track the state of objects The Capucine Language Permissions 16 / 51
Permissions permission = type-level information about a region permissions evolve during execution: statements consume and produce permissions permissions cannot be duplicated The Capucine Language Permissions 17 / 51
Allocation and Initialization operation let region r : C ◮ produces r ∅ operation let x = new C [ ρ ] ◮ consumes ρ ∅ ◮ produces ρ ◦ { f 1 , · · · , f k } and owned permissions operation x . f ← e when x : [ ρ ] ◮ consumes ρ ◦ { g } ◮ produces ρ ◦ { g − f } The Capucine Language Operations 18 / 51
Allocation: Example r ∅ let region r : Pair ; r ◦ { fst , snd } let p = new Pair [ r ]; r ◦ { snd } p . fst ← 42; r ◦ p . snd ← 69; The Capucine Language Operations 19 / 51
Permission Diagram (so far) let region r ∅ new r ◦ {· · ·} ← r ◦ The Capucine Language Operations 20 / 51
Packing and Unpacking if y : [ ρ ] operation pack y ◮ consumes ρ ◦ and owned permissions ◮ produces ρ × ◮ requires the invariant of y as a pre-condition operation unpack y ◮ consumes ρ × ◮ produces ρ ◦ and owned permissions note: ρ ◦ required to modify y . f ⇒ if ρ × available, then the invariant of y holds = The Capucine Language Operations 21 / 51
Example: Incrementing a Pair fun incrPair [ r : Pair ] ( p : [ r ]): unit consumes r × produces r × { r ◦ unpack p ; r ◦ p . fst ← p . fst + 1; r ◦ p . snd ← p . snd + 1; r × pack p ; (* invariant must hold *) } The Capucine Language Operations 22 / 51
Permission Diagram (so far) let region r ∅ new r ◦ {· · ·} ← unpack r ◦ r × r × pack The Capucine Language Operations 23 / 51
Adoption: From Singleton to Group if x : [ σ ] operation adopt x : σ as ρ ◮ consumes σ × and ρ G ◮ produces ρ G ◮ type of x becomes [ ρ ] x is then both in σ and ρ region σ is disabled The Capucine Language Operations 24 / 51
Permission Diagram let region r ∅ new r ◦ {· · ·} ρ G ρ G ← adopt unpack r ◦ r × r × pack The Capucine Language Operations 25 / 51
Focus: From Group to Singleton operation focus x : ρ as σ when x : [ ρ ] ◮ consumes ρ G and σ ∅ ◮ produces σ −◦ ρ and σ × ◮ type of x becomes [ σ ] x is then both in σ and ρ region ρ is temporarily disabled operation unfocus x : σ as ρ when x : [ σ ] ◮ consumes σ −◦ ρ and σ × ◮ produces ρ G ◮ type of x becomes [ ρ ] region ρ is re-enabled region σ is disabled The Capucine Language Operations 26 / 51
Aliased or Not Aliased? p and q may be aliased: fun f [ r : Pair ] ( p : [ r ] , q : [ r ]): unit consumes r G produces r G p and q cannot be aliased: fun f [ r p : Pair , r q : Pair ] ( p : [ r p ] , q : [ r q ]): unit consumes r pG r qG produces r pG r qG The Capucine Language Operations 27 / 51
Ownership locations may own regions class LongPairOwn { single r 1 : Long ; single r 2 : Long ; fst : [ r 1 ]; snd : [ r 2 ]; invariant fst . value < snd . value ; } invariant can only mention owned objects (enforced by typing) The Capucine Language Ownership 28 / 51
Allocation With Ownership r ∅ let region r : LongPairOwn ; r ◦ { fst , snd } p . r 1 ∅ p . r 2 ∅ let p = new LongPairOwn [ r ]; r ◦ { fst , snd } p . r 1 ◦ { value } p . r 2 ∅ let fst = new Long [ p . r 1 ]; r ◦ { fst , snd } p . r 1 ◦ p . r 2 ∅ fst . value ← 42; r ◦ { fst , snd } p . r 1 × p . r 2 ∅ pack fst ; r ◦ { fst , snd } p . r 1 × p . r 2 ◦ { value } let snd = new Long [ p . r 2 ]; r ◦ { fst , snd } p . r 1 × p . r 2 ◦ snd . value ← 69; r ◦ { fst , snd } p . r 1 × p . r 2 × pack snd ; r ◦ { snd } p . r 1 × p . r 2 × p . fst ← fst ; r ◦ p . r 1 × p . r 2 × p . snd ← snd ; r × pack p ; The Capucine Language Ownership 29 / 51
Ownership: Summary allows invariants to depend on owned fields ◮ need to unpack p to modify p . fst . value structures the heap using an ownership tree The Capucine Language Ownership 30 / 51
Heap Coherence we define a memory model and semantics for Capucine we define coherence of a heap w.r.t. available permissions ◮ empty regions are empty ◮ singleton regions have exactly one location ◮ locations in closed regions verify their invariant ◮ ... The Capucine Language Coherence Preservation 31 / 51
Coherence Preservation Theorem (Coherence Preservation) Coherence of the heap is preserved through execution of a well-typed program. The Capucine Language Coherence Preservation 32 / 51
Summary and Contributions take the existing notion of regions and permissions ◮ control aliasing my contributions ◮ use permissions to control invariants ◮ add ownership ◮ add region parameters to classes ◮ add region polymorphism ◮ use inference to guess some operations ◮ pack, unpack, adoption, focus, unfocus The Capucine Language Conclusion 33 / 51
Contents Introduction The Capucine Language Computing Verification Conditions Use Regions to Separate Pointers Prefix Trees Experiments Progress Conclusion Conclusion Computing Verification Conditions 34 / 51
Recommend
More recommend
