automated tactics for separation logic veriml reconstruct z3 proof safe incremental type checker

Post on 23-Feb-2016

52 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Automated tactics for separation logic VeriML Reconstruct Z3 Proof Safe incremental type checker Certifying code transformation Proof carrying hardware IP. Automated tactics for separation logic. Version 1 Certified verifier for a fragment of separation logic in Coq - PowerPoint PPT Presentation

TRANSCRIPT

• Automated tactics for separation logic• VeriML

• Reconstruct Z3 Proof • Safe incremental type checker• Certifying code transformation

• Proof carrying hardware IP

Automated tactics for separation logic• Version 1

• Certified verifier for a fragment of separation logic in Coq• Without predicates ( list, tree … )

• Prover written in SML handle these predicates and output proof trace

• Tactic to reconstruct proof from these proof trace in Coq• Version 2

• Hard coded list and tree into the certified verifier• Use a forked version Coq which supports native arrays to speed up

the verifier• Version 3 ( Ongoing )

• More generic way to support user defined predicates

Reconstruct Z3 Proof• Reconstruct proof in VeriML using output from Z3

Start from SAT Solvers• Decide propositional satisfiablity of sets of clauses:

• Proof Witness from SAT solver:• If satisfiable: assignment of all the variables• If unsatisfiable: proof by resolution of the empty clause

• Resolution rule:

𝑥∨ 𝐴𝑥∨𝐵𝐴∨𝐵

Example• Satisfiable:

• Unsatisfiable:

𝑥1∨¬𝑥2∨𝑥3¬𝑥3𝑥1∨¬𝑥2

𝑥1∨ 𝑥2𝑥1

¬𝑥1∨𝑥3¬ 𝑥3¬𝑥1

SAT Modulo Theories(SMT solver)• Atoms can be formulas from other theories

• Congruence Closure(EUF)• Linear Arithmetic(LIA)• ….

• Proof witness• If satisfiable: assignment of all the variables• If unsatisfiable: proof by resolution of the empty clause while some

leaves are now lemmas from theories

Example• Satisfiable :

• Unsatisfiable:

𝑥≠ 𝑦∨ 𝑓 (𝑥 )= 𝑓 (𝑦 ) 𝑥=𝑦𝑓 (𝑥 )= 𝑓 (𝑦 )

𝑓 (𝑥 )≠ 𝑓 (𝑦 )

Interaction between SAT and SMT

• With boolean abstraction:

• • First try: A:true, B:true, C:true, D:true, E:false

• Unsat by a multi-theory solver, thus we add a theory:

• Repeat until sat or no more model can be found

A B C D E

Reconstruct proof• If sat: apply the assignment and check the result is true

• If unsat: check the resolution tree• Checking resolution step (SAT solver)• Checking theory lemmas (SMT solver)• Combination of theories

What we need• resolution checker • checker for each theory• checker for the resolution tree which calls these two kinds of checkers at each step

Example𝑥1∨¬𝑥2∨𝑥3¬𝑥3

❑ 𝑥1∨ 𝑥2❑

¬𝑥1∨𝑥3¬ 𝑥3❑

Example𝑥1∨¬𝑥2∨𝑥3¬𝑥3

𝑥1∨¬𝑥2𝑥1∨ 𝑥2

❑¬𝑥1∨𝑥3¬ 𝑥3

❑❑

Example𝑥1∨¬𝑥2∨𝑥3¬𝑥3

𝑥1∨¬𝑥2𝑥1∨ 𝑥2

𝑥1¬𝑥1∨𝑥3¬ 𝑥3

❑❑

Example𝑥1∨¬𝑥2∨𝑥3¬𝑥3

𝑥1∨¬𝑥2𝑥1∨ 𝑥2

𝑥1¬𝑥1∨𝑥3¬ 𝑥3

¬𝑥1❑

Example𝑥1∨¬𝑥2∨𝑥3¬𝑥3

𝑥1∨¬𝑥2𝑥1∨ 𝑥2

𝑥1¬𝑥1∨𝑥3¬ 𝑥3

¬𝑥1∎

Encoding in VeriML• Only consider CNF clause• Variable

• Assignment: Nat-> Bool• Literal :

• Clause: List Literal• State: List ( clauseID * Clause )

• get : S -> clauseID -> C set: S -> clauseID -> C -> S• Proof trace: ??• A realistic Checker: State -> Trace -> Bool

Interpretation• Given assignment • Var: v• Literal: • Clause: • Valid state

• Soundness of checker:

Start from SAT solver• Resolution Chain: List Nat• Resolve : Clause->Clause->Clause

• resolution between clause C1 and C2. • Resolution checker: Resolution Chain-> Clause

• for resolution chain [n1,n2,…n] and state S,• R(..(R( S[n1], S[n2]),…),S[n])

• Proof trace: List (clauseID*Resolution Chain)• Reconstruct the proof:

• List.fold (fun (id,rc) => set s (resolution_checker rc) id) trace• After this, we have the empty clause in state which indicates the

state is not valid

Example𝑥1∨¬𝑥2∨𝑥3¬𝑥3

𝑥1∨¬𝑥2𝑥1∨ 𝑥2

𝑥1¬𝑥1∨𝑥3¬ 𝑥3

¬𝑥1∎

Initial State: [ [2,4], [2,5,6], [3,6], [7] ]Resolutions: [ (5,[1,3,0]) , (6,[2,3] ) , (7,[5,6]) ]Resolve two clause: [2,4] [2,5,6] [2,6] ( a modified merge sort )

Naïve framework for SMT solver• Certificate from different theories• Inductive cert:

• | sat_solver sat_cert• | euf_solver euf_cert• | lia_solver lia_cert• ….

• Trace might be like: List (clauseID*cert)• Checkers for each theory• And finally the checker for SMT solver

• checker s trace = • List.fold (fun (id,cert) => set s (cert_checker cert) id

Problem Witness

SMT

Resolution

CNF

EUF

LIA

VeriML Checker

Z3 Proof• Example

• 34 Axiom• 19 core rules : mostly are propositional reasoning• 5 equality rules : refl, symm, trans, …• 7 quantifier rules : quant-inst, quant-intro, …• 3 theory rules : rewrite, inconsistent, …

Reconstruction• Overall approach:

• one proof method for every Z3 inference rule• depth-first traversal of Z3 proof

Conclusion• A prototype to reconstruct zChaff(SAT solver) proof• Very slow in performance

• Ongoing with Z3 reconstruction

Safe Incremental Type Checker• Type checking is more and more an interaction between the programmer and the type-checker

• The richer the type system is, the more expensive type checking gets

• Example• Type inference ( unification)• Dependent types • Very large term ( proof term )• Complex language ( C++ )

Goal • Reuse already-computed results• Recheck only the modified part and where it affects

• Example

let f x = x + 1 in (f 2)

let f x = 2 * (x + 1) in (f 2)

let f x = (let y = true in x + 1) in (f 2)

let f x = x > 1 in (f 2)

• Benefit• fast type checking modified code

• this could also be used to tactic language, and refinement?• typed version control as we always have well-typed

program and its type derivations• “undo” for free

• If we simply use memorization• We can only do syntactic comparison• We can’t do

• weakening: let x = 1 and let y = 2 in x let x = 1 and let y = 2 in x

• -equivalence• other possible user extensible conversions

• it’s outside typing rule

Difficulties• A language to describe delta between different versions

• Slice the code into each typing step• A language to store typing derivations

• Higher order terms with meta variables• Build it up

• Repository : store type derivations• Delta: describe difference between two versions of code• Incremental checker: check : repo -> delta -> repo

• try to reduce the complexity to

• A language to store typing derivations• VeriML support contextual terms in computation language, thus

possible to present typing derivations• How to make it generic?

• A language to describe delta between different versions• Got stuck here

Scratch

• Given signature: • t1 = g a

• t2 = g (g a)

Certifying Code Transformation• How to certify code transformation?

• Verified Compiler• Translation Validation

• VeriML approach

Verified Compiler

Translation Validation

Approach with VeriML

Naïve Example

Scratch

• ImplementationLogical language• Heap implementation• Language definition and semantics

• Computation language• Symbolic execution(VCGen)• Tacitc to proof Hoare Triple• Practical Code transformation examples

Conclusion• The thing we need to proof isn't less than translation

validation• we can do it in a single lanuguage which easier to write proof with

and we get more proof• The whole picture is still vague

Proof Carrying Hardware• Current work

• A formalization of Intel 8051 microcontroller in Coq• RC5 hash algorithm • Proof certain ports won’t “leak” secret

top related