An Open Framework for Foundational Proof-Carrying Code Xinyu Feng Yale University Joint work with...

Post on 15-Jan-2016

222 views 0 download

transcript

An Open Framework for Foundational Proof-Carrying Code

Xinyu FengYale University

Joint work with Zhaozhong Ni (Yale, now at MSR), Zhong Shao (Yale) and

Yu Guo (USTC)

Motivation

How to build fully certified software systems?Source-level code Libraries and runtime+

References with weak upd.Dynamic mem. alloc.

Functions, exceptions, …

Concurrency

I/O

Garbage collectors

malloc() (strong update)

Stacks, code pointers

Context switching & SchedulerDevice drivers

Motivation All concurrency verification

assumes built-in concurrency Assume-Guarantee (A-G) reasoning Concurrent Separation logic (CSL) …

Context switching, scheduler Too low-level to be certified

in these logics

[Yu&Shao, ICFP’04]

H

RC1

pc1

T1

{(A1, G1)}

Cn

pcn

Tn

{(An, Gn)}

i

. . .

H

RC1 Cn

. . .

. . .

CS

pc

ctxt

1

ctxt

n

TQ

Threads & schedulers have never been modularly certified!

Motivation Certify all code in a single type system/program logic?

Hard to combine all features weak vs. strong update, functions/exceptions vs. goto’s, threa

ds vs. thread contexts May not be modular Very complex, hard to use Don’t know how to design such a logic

Certify modules using the most appropriate logic!

Modules do not use all the features at the same time It is simpler to use specialized logic for each module

An Open Framework

Certify different modules using different verification systems!

Proof ofSP

C1

C2

C1L1 k Ck

LkCk

CC1C2

Ck

. . .C2:L2

Challenges Extensibility and openness

not designed for certain specific interoperationsBut can we just use MLFs, e.g. Coq?

Expressiveness type safety, concurrency properties, partial correctness, …

A general and uniform model of control flow Allow functions certified in different systems to call each other the key for modularity: separate verification & proof reuse

Principled interoperation with clear meta-property properties of the whole system composed of modules

Not readily supported in Coq!

Our contributions OCAP: an open framework

Embedding of different systems TAL, non-CPS Hoare-logic, A-G reasoning, …

Open & Extensible Modularity with first-class code pointers [Ni&Shao POPL’06] Soundness

Type safety, & preservation of invariants in foreign systems

Applications TAL + memory allocation libs. Threads + Scheduler

The first time to modularly certify both sides …

Outline

OCAP Framework

Certifying Threads & Schedulers

OCAP Rules

Ln…

OCAP : Overview

OCAPSoundness

Mechanized Meta-Logic (CiC)

Modeling of the machineTCB

Sound

L1

( )L1 ( )LnSound

Mechanized Meta-Logic (CiC)

Modeling of the machine

…C1 Cn

The Machine

I1f1:

I2f2:

I3f3:

(code heap) C

0

r1

1 2 …

r2 r3 … rn

(data heap) H

(register file) R

(state) S

addu … lw … sw … … j f

(instr. seq.) I

(program) P::=(C,S,pc)

::=(H,R)::={f I}*

pc

The OCAP Logic : Overview

Hoare-style program logic for assembly

CPS-style reasoning Assign a precondition to each basic block

Similar to TAL [Morrisett et al. POPL’98]

The OCAP Logic : Overview

I1f1:

I2f2:

I3f3:

(code heap) C

0

r1

1 2 …

r2 r3 … rn

(data heap) H

(register file) R

(state) S

addu … lw … sw … … j f

(instr. seq.) I

(program) P::=(C,S,pc)

::=(H,R)::={f I}*

pc

a1

a2

a3

(spec) ::= {f a}*

a

OCAP: Code pointers

codeptr(f,a) (f) = a (Spec) ::= {f a}*

acodeptr

Not well-founded!

Support of first-class code pointers:

OCAP: Code Pointers

A generic specification:

(CdSpec) ::= …

(Assert) a Spec State Prop

(Spec) ::= {f }*

() ,S. …

No interoperation between multiple systems…

acodeptr

a

codeptr

()

OCAP: Foreign Languages

(LangTy) L ::= CiC Terms Type

(CodeSpec) ::= CiC Terms L

Inductive TalType : Type :=

T_int : TalType

T_pair: TalType -> TalType-> TalType

Inductive Tal2Type : Type :=

T2_int : TalType

T2_pair: TalType -> TalType-> TalType

L ::= TalType | Tal2Type | …1 ::= T_int | T_pair 1 1 | … TalType

2 ::= T2_int | T2_pair 2 2 | … Tal2Type

OCAP: Specifications

(OCdSpec) ::= <L,( )L,> L.(L Assert)*L

(Spec) ::= {(f1,1), … (fn,n)}

(Assert) a Spec State Prop

(Interp) ( )L L Assert

(LangTy) L ::= CiC Terms Type

(CodeSpec) ::= CiC Terms L

Not well-founded:

( )L

a

OCAP: Specifications

(OCdSpec) ::= <,L,( )L,>

(Spec) ::= {(f1,1), … (fn,n)}

(Assert) a Spec State Prop

(Interp) ( )L L Assert

(LangTy) L ::= CiC Terms Type(CodeSpec) ::= CiC Terms L

(LangID) ::= n nat

(LangDict) D ::= {1<L1,( )L1>,…, n<Ln,( )Ln>}

LangID (L.L Assert)

( )L

a

Selected OCAP Rules

D1D2; 12┝ C1C2 : 1’2’

D1;1┝ C1:1’ (link)D2;2┝ C2:2’ …

D┝ {a}jr r

,S.a S .(codeptr(S.R(r),)a’) S

(jr)a’ = [[[ ]]]D

codeptr(f,) ,S. (f)=

[[[ ]]]D ,S. ( )L.(D()=<L, ( )L>)(()L S)

= <,L,>

Outline

OCAP Framework

Certifying Threads & Schedulers

Threads and Scheduler

Thread code C1,…,Cn

Certified following CCAP [Yu&Shao, ICFP’04]

Assume-Guarantee reasoning Thread modularity Do not know about thread queue

H

RC1

pc1

T1

{(A1, G1)}

Cn

pcn

Tn

{(An, Gn)}

i

. . .

H

RC1 Cn

. . .

. . .

CS

pc

ctxt

1

ctxt

n

TQ

SCAPCCAP +

Scheduler CS

Certified in SCAP [Feng et al. PLDI’06]

as sequential code Manages thread queue TQ Do not touch H

Scheduler in SCAP

yield:

pick one word (pci) from TQ

swap pci and r31

jr r31

H1 pc

1

pcn…

TQ

r31

r0

H1 pc

1

pcn…

TQ

r31

r0

jal yield

ct: …

Thread code:

ct

ct

Scheduler in SCAP

yield: (ps, gs)

pick one word (pci) from TQ

swap pci and r31

jr r31

gs

gs (r{r1,…,r30}.[r]=[r]’) Q, Q’.

p’.

Q{[r31]} = Q’{[r31]’}

WFTQ(Q)*p’WFTQ(Q’)*p’

H1 pc

1

pcn…

TQ

r31

r0

H1 pc

1

pcn…

TQ

r31

r0

ct

ct

ps Q.WFTQ(Q) * True

Embedding SCAP

((p,g))Dscap …

jr $ra

g

p

D

Soundness:

scap┝scap C:’scap

(scap)Dscap D Dscap,┝ C:

’’ (’scap)Dsc

ap

Dscap {scap <Lscap, (_)scap> }

Threads: Assume-Guarantee

S

p1 p2

S’

Spec. for threads: (p, A, G)p: State Prop

p’1 p2 ?

A, G: State State Prop

Stability of p:

pi S Ai S S’ pi S’

G1 A2

A1, G1 A2, G2

CCAP embedding

ccap┝ccap Ci:’ccap

Dall {ccap <Lccap, (_)ccap>,

scap <Lscap, (_)scap> }

Dall; cy┝ Ci: ’c

y {yield <scap ,Lscap,(ps, gs)>}

c (ccap) ccap ’c (’ccap) c

cap

((p,A,G))ccap ,S. …

Certify the code

H

RC1 Cn

. . .

. . .

CS

pc

ctxt

1

ctxt

n

TQ

ccap┝ccap Ci:’ccapscap┝scap Cs:’scap

Dall {ccap <Lccap, (_)ccap>,

scap <Lscap, (_)scap> }

Dall; y┝ Cs: ’y Dall; cy┝ Ci: ’c

SCAPCCAP

the “link” rule

Dall; cy┝ Ci Cs : ’c ’y

Summary It is simpler and natural to certify different module

s using different logics OCAP: framework for interoperation Embedding

TAL: type system SCAP: non-cps logic for assembly CCAP: Assume-guarantee reasoning

Interoperation TAL + newpair Threads + Scheduler TAL + GC (ongoing work by Lin, McCreight, et al.)

Future work

Explore the applicability of OCAP

Interoperation of different languages Currently just for assembly language

But logics are at different levels (TAL, CCAP, …)

May support C + inlined assembly

Thank you!