Post on 06-Jul-2020
Deductive Verificationof State-space Algorithms
Frédéric Gava and Jean Fortin and Michael Guedj
Laboratory of Algorithms, Complexity and Logic (LACL)University of Paris-East
Evry 2013 1 / 1
Outline
Evry 2013 2 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Verification and parallelism
Explicit model-checking of a security protocol
ProblemCompute all possible attacks:
1 Many computations2 Astronomical number of possibilities
Possible solutionDesign distributed algorithms to benefit from:
1 More computation units2 More memory3 But, correctness of the algorithms?
Evry 2013 3 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Quis custodiet ipsos custodes ?
Who will watch the watchmen? “the Satires” of JuvenalDifferent solutions:• Writing “formal hand proofs”• Generating certificates (“fPCC” approach)• Extracting programs from proof assistants
Proposed solution, annotating our programs/algorithms:• Deductive verification• Can be limited to partial correcteness• Generation of proof obligations
This presentation:We will verifying 3 traditional sequential state-space algorithmsand then our own parallel algorithm.
Evry 2013 4 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Background
A need to prove parallel programs:Different solutions:• Model-Checking: MPI-SPIN, ISP• Symbolic execution: TASS• Concurrent Separation Logic: VCC, Heap-hop• Owicki-Gries proof system• Logical derivation (from specifications to programs)
Problems:• Not for send/received algorithms• Bound number of processors⇒ scalability issue• No dedicated tools for mechanized verification
Chosen solution: syntaxic extension of a VCG called WHY• Annotated programs• Generation of proof obligations
BSP programming: BSPlib, PUB, BSPGPU, Ct, · · · (C);Hamma, JBSP, JPUB, · · · (Java); MPI collective operations
Evry 2013 5 / 1
Bridging model: Bulk Synchronous Parallelism (BSP)
The BSP computerDefined by:
p pairs CPU/memoryCommunication networkSynchronisation unit
Properties:“Confluent”“Deadlock-free”PredictableperformancesSuper-steps execution
localcomputations
p0 p1 p2 p3
communication
barriernext super-step
......
......
Evry 2013 6 / 1
Bridging model: Bulk Synchronous Parallelism (BSP)
The BSP computerDefined by:
p pairs CPU/memoryCommunication networkSynchronisation unit
Properties:“Confluent”“Deadlock-free”PredictableperformancesSuper-steps execution
localcomputations
p0 p1 p2 p3
communication
barriernext super-step
......
......
Evry 2013 6 / 1
Bridging model: Bulk Synchronous Parallelism (BSP)
The BSP computerDefined by:
p pairs CPU/memoryCommunication networkSynchronisation unit
Properties:“Confluent”“Deadlock-free”PredictableperformancesSuper-steps execution
localcomputations
p0 p1 p2 p3
communication
barriernext super-step
......
......
Evry 2013 6 / 1
Bridging model: Bulk Synchronous Parallelism (BSP)
The BSP computerDefined by:
p pairs CPU/memoryCommunication networkSynchronisation unit
Properties:“Confluent”“Deadlock-free”PredictableperformancesSuper-steps execution
localcomputations
p0 p1 p2 p3
communication
barriernext super-step
......
......
Evry 2013 6 / 1
Bridging model: Bulk Synchronous Parallelism (BSP)
The BSP computerDefined by:
p pairs CPU/memoryCommunication networkSynchronisation unit
Properties:“Confluent”“Deadlock-free”PredictableperformancesSuper-steps execution
localcomputations
p0 p1 p2 p3
communication
barriernext super-step
......
......
Evry 2013 6 / 1
Bridging model: Bulk Synchronous Parallelism (BSP)
The BSP computerDefined by:
p pairs CPU/memoryCommunication networkSynchronisation unit
Properties:“Confluent”“Deadlock-free”PredictableperformancesSuper-steps execution
localcomputations
p0 p1 p2 p3
communication
barriernext super-step
......
......
Evry 2013 6 / 1
Bridging model: Bulk Synchronous Parallelism (BSP)
The BSP computerDefined by:
p pairs CPU/memoryCommunication networkSynchronisation unit
Properties:“Confluent”“Deadlock-free”PredictableperformancesSuper-steps execution
localcomputations
p0 p1 p2 p3
communication
barriernext super-step
......
......
Evry 2013 6 / 1
Outline
Evry 2013 7 / 1
The Why tool
Why-ML: an intermediate languageFor deductive verification of algorithmsAnnotated ML-like programs (pre- post- conditions)Several back-end provers (Coq, Alt-ergo, Simplify, Z3, . . . )Need axiomatisation for set, list, etc.“Invariant” and “variant” for each loopSome provers can generate certificates (Isabelle/Coq)
Evry 2013 8 / 1
The Why tool
Why-ML: an intermediate languageFor deductive verification of algorithmsAnnotated ML-like programs (pre- post- conditions)Several back-end provers (Coq, Alt-ergo, Simplify, Z3, . . . )Need axiomatisation for set, list, etc.“Invariant” and “variant” for each loopSome provers can generate certificates (Isabelle/Coq)
Evry 2013 8 / 1
The Why tool
Why-ML: an intermediate languageFor deductive verification of algorithmsAnnotated ML-like programs (pre- post- conditions)Several back-end provers (Coq, Alt-ergo, Simplify, Z3, . . . )Need axiomatisation for set, list, etc.“Invariant” and “variant” for each loopSome provers can generate certificates (Isabelle/Coq)
Evry 2013 8 / 1
The Why tool
Why-ML: an intermediate languageFor deductive verification of algorithmsAnnotated ML-like programs (pre- post- conditions)Several back-end provers (Coq, Alt-ergo, Simplify, Z3, . . . )Need axiomatisation for set, list, etc.“Invariant” and “variant” for each loopSome provers can generate certificates (Isabelle/Coq)
Evry 2013 8 / 1
The Why tool
Why-ML: an intermediate languageFor deductive verification of algorithmsAnnotated ML-like programs (pre- post- conditions)Several back-end provers (Coq, Alt-ergo, Simplify, Z3, . . . )Need axiomatisation for set, list, etc.“Invariant” and “variant” for each loopSome provers can generate certificates (Isabelle/Coq)
Evry 2013 8 / 1
The Why tool
Why-ML: an intermediate languageFor deductive verification of algorithmsAnnotated ML-like programs (pre- post- conditions)Several back-end provers (Coq, Alt-ergo, Simplify, Z3, . . . )Need axiomatisation for set, list, etc.“Invariant” and “variant” for each loopSome provers can generate certificates (Isabelle/Coq)
Evry 2013 8 / 1
A Why-ML example
logic v : intfunction mean(x:int, y:int):int = (x+y)/2axiom mean : ∀x,y:int. x≤ y→ x≤ mean(x,y)≤ ypredicate Present(t:int farray, l:int, u:int) = ∃i:int. l≤ i≤ u and t[i]=vparameter t : int array...
let binary_search () ={ array_length(t) ≥ 1 and sorted_array(t,1,array_length(t)−1) }begin
l←1; u←(array_length t)−1; p←0;while !l ≤ !u do
{ invariant 1≤ l and u≤ array_length(t)−1 and ...and (p=0→ Present(t,1,array_length(t)−1)→ Present(t,l,u))
variant 2+u−l }...assert { l≤ m and m≤ u };if t[!m]<v then l←!m+1 else ...
doneend{(1 ≤ p ≤ array_length(t)−1 and t[p]=v) or (p=0 and ¬Present(t,1,array_length(t)−1)) }
Evry 2013 9 / 1
The BSP-Why tool
GeneralitiesBSP-WhyML extends WhyML with:• Additional instructions for parallel operations• Additional notations in assertions about parallelism
Automatic transformation to Why code (sequentialisation)
Main idea
SYNC SYNC
P1 P2 P3
Evry 2013 10 / 1
The BSP-Why tool
GeneralitiesBSP-WhyML extends WhyML with:• Additional instructions for parallel operations• Additional notations in assertions about parallelism
Automatic transformation to Why code (sequentialisation)
Main idea
SYNC SYNC
P1 P2 P3
Evry 2013 10 / 1
The BSP-Why tool
GeneralitiesBSP-WhyML extends WhyML with:• Additional instructions for parallel operations• Additional notations in assertions about parallelism
Automatic transformation to Why code (sequentialisation)
Main idea
SYNC SYNC
P1 P2 P3
Evry 2013 10 / 1
The BSP-Why tool
GeneralitiesBSP-WhyML extends WhyML with:• Additional instructions for parallel operations• Additional notations in assertions about parallelism
Automatic transformation to Why code (sequentialisation)
Main idea
SYNC SYNC
P1 P2 P3
Evry 2013 10 / 1
The BSP-Why tool
GeneralitiesBSP-WhyML extends WhyML with:• Additional instructions for parallel operations• Additional notations in assertions about parallelism
Automatic transformation to Why code (sequentialisation)
Main idea
SYNC SYNC
P1 P2 P3
Evry 2013 10 / 1
The BSP-Why tool
GeneralitiesBSP-WhyML extends WhyML with:• Additional instructions for parallel operations• Additional notations in assertions about parallelism
Automatic transformation to Why code (sequentialisation)
Main idea
SYNC SYNC
P1 P2 P3
Evry 2013 10 / 1
The BSP-Why tool
GeneralitiesBSP-WhyML extends WhyML with:• Additional instructions for parallel operations• Additional notations in assertions about parallelism
Automatic transformation to Why code (sequentialisation)
Main idea
SYNC SYNC
P1 P2 P3
Evry 2013 10 / 1
The BSP-Why tool (2)
Language definition
BSPWhy ::= Why| sync synchronisation and parameters| send(v ,pid) Message passing| rcv(pid ,n) Reception| ... RMA, Collective operations
Logic extensions
x , to represent the value of x on the current processorx < i >, to represent the value of x on the processor i<x >, to represent the parallel variable x as an array
Evry 2013 11 / 1
The BSP-Why tool (2)
Language definition
BSPWhy ::= Why| sync synchronisation and parameters| send(v ,pid) Message passing| rcv(pid ,n) Reception| ... RMA, Collective operations
Logic extensions
x , to represent the value of x on the current processorx < i >, to represent the value of x on the processor i<x >, to represent the parallel variable x as an array
Evry 2013 11 / 1
The BSP-Why tool (2)
Language definition
BSPWhy ::= Why| sync synchronisation and parameters| send(v ,pid) Message passing| rcv(pid ,n) Reception| ... RMA, Collective operations
Logic extensions
x , to represent the value of x on the current processorx < i >, to represent the value of x on the processor i<x >, to represent the parallel variable x as an array
Evry 2013 11 / 1
The BSP-Why tool (2)
Language definition
BSPWhy ::= Why| sync synchronisation and parameters| send(v ,pid) Message passing| rcv(pid ,n) Reception| ... RMA, Collective operations
Logic extensions
x , to represent the value of x on the current processorx < i >, to represent the value of x on the processor i<x >, to represent the parallel variable x as an array
Evry 2013 11 / 1
The BSP-Why tool (2)
Language definition
BSPWhy ::= Why| sync synchronisation and parameters| send(v ,pid) Message passing| rcv(pid ,n) Reception| ... RMA, Collective operations
Logic extensions
x , to represent the value of x on the current processorx < i >, to represent the value of x on the processor i<x >, to represent the parallel variable x as an array
Evry 2013 11 / 1
Outline
Evry 2013 12 / 1
State-space constructionDefinition
Initial state s0 and successor s′ ∈ succ(s) ≡ s → s′
Inductive definition⇒ a set of reachable states (or graph)
Several security properties (secrecy, authentification, etc.)
let seq_succ () =...while todo 6= ∅ dolet s = pick todo inknown←!known ⊕ s;todo←!todo ∪ (succ(s) \ !known)
done
Parallelization
Main idea• cpu assigns states to nodes
• Each processor i computes s′∈succ(s)iff cpu(s′) = i ; otherwise sends s′
• Stops when no new states
let naive_par_state_space () =...while total>0 dolet tosend = (seq_succ known todo pastsend) inexchange todo total known pastsend tosend
done
Evry 2013 13 / 1
State-space constructionDefinition
Initial state s0 and successor s′ ∈ succ(s) ≡ s → s′
Inductive definition⇒ a set of reachable states (or graph)
Several security properties (secrecy, authentification, etc.)
let seq_succ () =...while todo 6= ∅ dolet s = pick todo inknown←!known ⊕ s;todo←!todo ∪ (succ(s) \ !known)
done
Parallelization
Main idea• cpu assigns states to nodes
• Each processor i computes s′∈succ(s)iff cpu(s′) = i ; otherwise sends s′
• Stops when no new states
let naive_par_state_space () =...while total>0 dolet tosend = (seq_succ known todo pastsend) inexchange todo total known pastsend tosend
done
Evry 2013 13 / 1
State-space constructionDefinition
Initial state s0 and successor s′ ∈ succ(s) ≡ s → s′
Inductive definition⇒ a set of reachable states (or graph)
Several security properties (secrecy, authentification, etc.)
let seq_succ () =...while todo 6= ∅ dolet s = pick todo inknown←!known ⊕ s;todo←!todo ∪ (succ(s) \ !known)
done
Parallelization
Main idea• cpu assigns states to nodes
• Each processor i computes s′∈succ(s)iff cpu(s′) = i ; otherwise sends s′
• Stops when no new states
let naive_par_state_space () =...while total>0 dolet tosend = (seq_succ known todo pastsend) inexchange todo total known pastsend tosend
done
Evry 2013 13 / 1
State-space constructionDefinition
Initial state s0 and successor s′ ∈ succ(s) ≡ s → s′
Inductive definition⇒ a set of reachable states (or graph)
Several security properties (secrecy, authentification, etc.)
let seq_succ () =...while todo 6= ∅ dolet s = pick todo inknown←!known ⊕ s;todo←!todo ∪ (succ(s) \ !known)
done
Parallelization
Main idea• cpu assigns states to nodes
• Each processor i computes s′∈succ(s)iff cpu(s′) = i ; otherwise sends s′
• Stops when no new states
let naive_par_state_space () =...while total>0 dolet tosend = (seq_succ known todo pastsend) inexchange todo total known pastsend tosend
done
Evry 2013 13 / 1
Sequential algorithms
let random () =let known = ref ∅ inlet todo = ref {s0} inwhile todo 6= ∅ do
let s = pick todo inknown←!known ⊕ s;todo←!todo ∪ (succ(s) \ !known)
done;!known
let main_dfs () =let known = ref ∅inlet rec dfs (s:state) : unit =
known←!known ⊕ s;for s’ in (succ(s) \ !known) do
if (new_s 6∈ known) then dfs(new_s)done
indfs(s0);!known
Evry 2013 14 / 1
Correctness of the sequential “random” algorithm
axiom contain_state_space: ∀ss:state set. StSpace ⊆ ss↔ (s0 ∈ ss and (∀ s:state. s ∈ ss→ s ∈ StSpace→ succ(s) ⊆ ss))
let random () =let known = ref ∅ inlet todo = ref {s0} inwhile todo 6= ∅ do{invariant (1) (known ∪ todo) ⊆ StSpace
and (2) (known ∩ todo)=∅and (3) s0 ∈(known ∪ todo)and (4) (∀ e:state. e ∈known→ succ(e) ⊆ (known ∪ todo))
variant |StSpace \ known|}
let s = pick todo inknown←!known ⊕ s;todo←!todo ∪ (succ(s) \ !known)
done;!known{StSpace=result}
The DFS algorithm need many annotations ...Evry 2013 15 / 1
Correctness of the “dfs” algorithm
let main_dfs () =let known = ref ∅inlet nofinish = ref ∅in (∗ ghost ∗)let rec dfs (s:state) : unitvariant |Stspace \ known|={
(1) s ∈StSpaceand (2) known ⊆ StSpaceand (3) s 6∈ knownand (4) s 6∈ nofinishand (5) (∀ e:state. e ∈known→ ¬(e ∈nofinish)→ succ(e) ⊆ known)and (6) nofinish ⊆ known
}...
Evry 2013 16 / 1
“Benchmarks”
algo/SMT Total Alt-Ergo Simplify Z3 CVC3 Yices VampireNormal 11 2 10 11 7 3 3Breadth 31 9 31 28 21 10 10Dfs 49 22 48 47 40 23 26
Few seconds for each goalNear 5 days of work
Evry 2013 17 / 1
“Benchmarks”
algo/SMT Total Alt-Ergo Simplify Z3 CVC3 Yices VampireNormal 11 2 10 11 7 3 3Breadth 31 9 31 28 21 10 10Dfs 49 22 48 47 40 23 26
Few seconds for each goalNear 5 days of work
Evry 2013 17 / 1
Main BSP loop
while total>0 do{invariant
⋃(<known>) ∪
⋃(<todo>) ⊆ StSpace
and (⋃
(<known>) ∩⋃
(<todo>))=∅and GoodPar(<known>) and GoodPart(<todo>)and (∀ i,j:int. isproc(i)→ isproc(j)→ total<i> = total<j>)and total<0> ≥ |
⋃(<todo>)|
and s0 ∈(⋃
(<known>) ∪⋃
(<todo>))and (∀ e:state. e ∈
⋃(<known>)→ succ(e) ⊆ (
⋃(<known>) ∪
⋃(<todo>)))
and⋃
(<pastsend>) ⊆ StSpaceand (∀ i:int. isproc(i)→ ∀e:state. e ∈pastsend<i>→ cpu(e)6= i)and
⋃(<pastsend>) ⊆ (
⋃(<known>) ∪
⋃(<todo>))
variant pair(paccess(total,0),| S \⋃
(known) |) for lexico_order}let tosend=(seq_succ known todo pastsend) inexchange todo total !known !tosend
done;!known{StSpace=
⋃(<result>) and GoodPart(<result>)}
GoodPar(<known>)↔ well distributed using cpu⋃(<known>)↔
⋃pi=0 knowni
Evry 2013 18 / 1
“Benchmarks”
part/SMT Total Alt-Ergo Simplify Z3 CVC3 Yices Vampiremain 106 74 98 101 0 54 78successor 46 16 42 41 24 14 32exchange 24 20 22 23 0 16 15
With sometime 10 minutes for each goalTakes 2 hours of computationMade with the help of a master student2 months of work
Evry 2013 19 / 1
“Benchmarks”
part/SMT Total Alt-Ergo Simplify Z3 CVC3 Yices Vampiremain 106 74 98 101 0 54 78successor 46 16 42 41 24 14 32exchange 24 20 22 23 0 16 15
With sometime 10 minutes for each goalTakes 2 hours of computationMade with the help of a master student2 months of work
Evry 2013 19 / 1
“Benchmarks”
part/SMT Total Alt-Ergo Simplify Z3 CVC3 Yices Vampiremain 106 74 98 101 0 54 78successor 46 16 42 41 24 14 32exchange 24 20 22 23 0 16 15
With sometime 10 minutes for each goalTakes 2 hours of computationMade with the help of a master student2 months of work
Evry 2013 19 / 1
“Benchmarks”
part/SMT Total Alt-Ergo Simplify Z3 CVC3 Yices Vampiremain 106 74 98 101 0 54 78successor 46 16 42 41 24 14 32exchange 24 20 22 23 0 16 15
With sometime 10 minutes for each goalTakes 2 hours of computationMade with the help of a master student2 months of work
Evry 2013 19 / 1
Outline
Evry 2013 20 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Conclusion
The Why and BSP-Why toolsWhy for deductive verification of algorithmsBSP-Why is an extension of the WHY for BSP algorithmsBSP-Why programs are transformed into WHY programsThe proof obligations are generated by Why
Application: verification of state-space algorithms
Correctness:3 traditional sequential algorithmsA traditional parallel BSP algorithm
Evry 2013 21 / 1
Perspectives (ongoing/future work)
Coq proof of the BSP-Why transformation (ongoing work)Generating a BSP-Why code from a BSP-Java programLTL/CTL* machine-checked model-checking algorithmsProof of a realistic implementation
Evry 2013 22 / 1
Perspectives (ongoing/future work)
Coq proof of the BSP-Why transformation (ongoing work)Generating a BSP-Why code from a BSP-Java programLTL/CTL* machine-checked model-checking algorithmsProof of a realistic implementation
Evry 2013 22 / 1
Perspectives (ongoing/future work)
Coq proof of the BSP-Why transformation (ongoing work)Generating a BSP-Why code from a BSP-Java programLTL/CTL* machine-checked model-checking algorithmsProof of a realistic implementation
Evry 2013 22 / 1
Perspectives (ongoing/future work)
Coq proof of the BSP-Why transformation (ongoing work)Generating a BSP-Why code from a BSP-Java programLTL/CTL* machine-checked model-checking algorithmsProof of a realistic implementation
Evry 2013 22 / 1
Merci !