Under the Hood of the Open Verifier

transcript

Under the Hood of the Open Under the Hood of the Open VerifierVerifier

Bor-Yuh Evan Chang, Adam Chlipala, Kun Gao,George Necula, and Robert Schneck

October 21, 2003OSQ Group Meeting

10/21/2003 2

Issues with PCC and FPCCIssues with PCC and FPCC

• Flexibility– Can the code producer use a different (or

multiple) safety enforcement mechanism(s)?• e.g., various type systems, vcgen proofs

More FlexibleLess Flexible

10/21/2003 3

• Scalability– Can the proof obligations for the code producer

be simplified?

More ScalableLess Scalable

10/21/2003 4

• Amount of Trusted Code– Can the amount of trusted code in the

verification infrastructure be lessened while maintaining flexibility and scalability?

Less Trusted CodeMore Trusted Code

FPCCOVPCC

10/21/2003 5

An Untrusted VerifierAn Untrusted Verifier• The code producer supplies the verifier along with the code

– flexibility: code producer can provide a verifier to handle particular enforcement mechanism– scalability: specialized reasoning for the enforcement mechanism encoded in executable form– amount of trusted code: verifier extension with specialized reasoning is not trusted

• Too hard to prove correctness of the verifier

• Embed the untrusted verifier as an extension in a trusted infrastructure (the Open Verifier)

untrusted trusted

verifierextension

OpenVer

verifierextension

10/21/2003 6

OutlineOutline

• Motivation

• Architecture Overview

• Simple Local Invariants– Decoder– Extension– Coverage

• Complete Local Invariants– Coverage

• Summary

10/21/2003 7

The Open VerifierThe Open Verifier

Decoder

• instruction at locinv II safe if PP holds

• next locinvs DD

Director

Extension

trusteduntrusted

locinv II

• a proof of PP• a proof that EE covers DD

next locinvsEE

10/21/2003 8

Decoder Director

Extension

trusteduntrusted

locinv II

next locinvsEE

StandardStandardCoolCool

VerifierVerifier

Cool Extension

DefinitionsDefinitionsandand

LemmasLemmas

10/21/2003 9

Decoder Director

Extension

trusteduntrusted

locinv II

next locinvsEE

Proof ExtractorProof Extractorforfor

Traditional PCCTraditional PCC

Generic Extension

10/21/2003 10

An ExampleAn Exampleclass S {

S next() { … };

class R extends S {

S next() { … }

void f(S x) {

x = this;

while (x != null) {

x = x.next();

rTHIS : R, rTHIS 0, rx : S

1 Rf: rx := rTHIS

rx : R, rx 0

2 L2: if rx=0 jump L9

rx : R, rx 0

3 L3: load rt from rx + 4rt : vm(rx,4), rx : R, rx 0

4 L4: rTHIS := rx

rTHIS = rx, rt : vm(rx,4),rx : R, rx 0

5 L5: rRA := L7

rRA = L7, rTHIS = rx, rt : vm(rx,4),rx : R, rx 0

6 L6: ijump rt

rRV : S

7 L7: rx := rRV rx : S

8 L8: jump L2

9 L9: ijump rRA

20 Snext: … 30 Rnext: …

10/21/2003 11

Local Invariants (Locinvs) - Part 1Local Invariants (Locinvs) - Part 1

• Language of discoursein the Open Verifier

• Should be– simple, natural

– sufficiently powerful,

“complete”

A predicate about the machine state at a specific instruction

Decoder

• next locinvs DD

Director

Extension

trusteduntrusted

locinvII

• a proof of PP• a proof that EEcovers DD

next locinvsEE

10/21/2003 12

Local Invariants - Part 1Local Invariants - Part 1

• Informal:At rPC = 1, the memory is laid out according to the Cool specification, rTHIS has type R, rTHIS is non-null, and rx has type S.

• (More) Formal:rPC = 1

Æ (cinv rM) ; mem ok

Æ rTHIS : R

Æ rTHIS 0

Æ rx : S

1 Rf: rx := rTHIS

3 L3: load rt from rx + 4

4 L4: rTHIS := rx

5 L5: rRA := L7

6 L6: ijump rt

7 L7: rx := rRV

8 L8: jump L2

9 L9: ijump rRA

10/21/2003 13

DecoderDecoder• Encodes the semantics of

machine instructions and the safety policy

• Essentially, a strongest-postcondition generator

Decoder

• next locinvs DD

Director

Extension

trusteduntrusted

locinvII

next locinvsEE

decoder(I) = (P,D)I: rPC = 1 Æ (cinv rM) Æ rTHIS : R Æ rTHIS 0 Æ rx : SP: TrueD: [9tx. rPC = 2 Æ rx = rTHIS Æ (cinv rM) Æ rTHIS : R

Æ rTHIS 0 Æ tx : S]

1 Rf: rx := rTHIS

10/21/2003 14

• Existentially quantified predicates parameterized by the machine state and structured into

– first-order assumptions A

Decoder

• next locinvs DD

Director

Extension

trusteduntrusted

locinvII

next locinvsEE

• Machine state specifies the values of the PC, the registers, and the memory

– left implicit in the examples

10/21/2003 15

ExtensionExtension

• Required to prove:– Local safety condition

(I ) P)• Either trivial or some

address is valid• Type-based extensions

use the soundness of the type system

– Coverage (EE covers DD)

Decoder

• next locinvs DD

Director

Extension

trusteduntrusted

locinvII

next locinvsEE

10/21/2003 16

CoverageCoverage

• (E covers D) means roughly

where safe I means “if locinv I is satisfied, then safe progress can be made”

• but it is sufficient to show

10/21/2003 17

CoverageCoverage

• Covering a single D = 9xD. (AD xD)

• or it is sufficient to show

for some E = 9xE.(AE xE) 2 E

10/21/2003 18

CoverageCoverage

• Typically, the extension makes minor modifications to the locinv produced by the decoder.– e.g., to forget about some detailed information

not necessary for demonstrating safety

• Can implement proof of coverage more efficiently by considering kinds of changes – e.g., using the decoder’s locinv or simply

dropping assumptions from the decoder’s locinv requires no coverage proof.

10/21/2003 19

Coverage - Add AssumptionsCoverage - Add Assumptions

1 Rf: rx := rTHIS

I: rPC = 1 Æ (cinv rM) Æ rTHIS : R Æ rTHIS 0 Æ rx : SP: TrueD: [9tx. rPC = 2 Æ rx = rTHIS Æ (cinv rM) Æ rTHIS : R

Æ rTHIS 0 Æ tx : S]E: [rPC = 2 Æ (cinv rM) Æ rx : R Æ rx 0]

(E covers D) requires8xD. (AD xD) ) rx : R Æ rx 0

10/21/2003 20

Coverage - Scanned Locinv (Loops)Coverage - Scanned Locinv (Loops)

1 L8: jump L2

I: rPC = 8 Æ (cinv rM)Æ rx : S

P: TrueD: [rPC = L2 Æ (cinv rM)

Æ rx : S]E: [rPC = L2 Æ (cinv rM)

Æ rx : R Æ rx 0]

1 Rf: rx := rTHIS

rx : R, rx 0

4 L4: rTHIS := rx

5 L5: rRA := L7

6 L6: ijump rt

rRV : S

8 L8: jump L2

9 L9: ijump rRA

(E covers D)

rx : S ) rx : R Æ rx 0

10/21/2003 21

1 L8: jump L2

Æ rx : S]

1 Rf: rx := rTHIS

rx : R, rx 0

4 L4: rTHIS := rx

5 L5: rRA := L7

6 L6: ijump rt

rRV : S

8 L8: jump L2

9 L9: ijump rRA

(E covers D)

rx : S ) rx : R Æ rx 0

10/21/2003 22

1 L8: jump L2

Æ rx : S] (from before)• Coverage is trivially

satisfied here• Do not know the

incremental changes

1 Rf: rx := rTHIS

rx : S

rx : S, rx 0

3 L3: load rt from rx + 4rt : vm(rx,4), rx : S, rx 0

4 L4: rTHIS := rx

rTHIS = rx, rt : vm(rx,4),rx : S, rx 0

5 L5: rRA := L7

rRA = L7, rTHIS = rx, rt : vm(rx,4),rx : S, rx 0

6 L6: ijump rt

rRV : S

8 L8: jump L2

9 L9: ijump rRA

10/21/2003 23

OutlineOutline

• Motivation

• Architecture Overview

• Simple Local Invariants– Decoder– Extension– Coverage

• Complete Local Invariants– Coverage

• Summary

10/21/2003 24

Indirect JumpsIndirect Jumps

• Indirect jumps are more difficult to handle but necessary– function return, exceptions

• Within the context of a particular locinv, need to state a code address is “safe to jump to” (under certain conditions)– e.g., it is “safe to jump to” the address

contained in rRA.

10/21/2003 25

“rPC = 9, rSAVE = 1, rRA = 27, and it is safe to jump to rPC = rRA as long as rSAVE has the same

value as now.”

. (rPC ) = 9

Æ (rSAVE ) = 1

Æ safe (’. (rPC ’) = (rRA )

Æ (rSAVE ’) = (rSAVE ))

10/21/2003 26

• Existentially quantified predicates parameterized by the machine state and structured into– first-order assumptions A– progress continuations C

• a list of locinvs that are “safe to continue to”

• Not a general higher-order predicate but one structured into first-order pieces.

10/21/2003 27

• Fixing the machine state, a locinv I can be structured into a tuple as follows:

I = 9xI.hPCI, RI, AI, CIi

• PCI is an expression in terms of xI (usually, constant)

• RI is a mapping from register names to expressions

• AI is a first-order formula (assumptions)

• CI is a list of locinvs (progress continuations)

10/21/2003 28

Local Invariants - Part 3Local Invariants - Part 3“rPC = 9, rSAVE = 1, rRA = 27, and it is safe to jump to rPC = rRA as long as rSAVE has

the same value as now.”

I = . (rPC ) = 9

Æ (rSAVE ) = 1

Æ safe (’. (rPC ’) = (rRA )

Æ (rSAVE ’) = (rSAVE ))

I = 9xSAVE,xRA.hPCI = 9,

RI = {SAVE xSAVE, RA xRA, …},

AI = (xSAVE = 1),

CI = [ hPCC1 = xRA,

RC1 = {SAVE xSAVE, …},

AC1 = True,

CC1 = [ ]i ]i

10/21/2003 29

Coverage with Progress ContinuationsCoverage with Progress Continuations

• (E covers D) - a single locinv

• it is sufficient to show

for some E 2 E [ CD

10/21/2003 30

Function ReturnFunction Return9 L9: ijump rRA

I: 9xRA.hPCI = 9, RI = {RA xRA, …}, AI = True,

CI = [hPCC1 = xRA,RC1 = {…},AC1 = True,CC1 = [ ]i]iP: True

D: [9xRA.hPCI = xRA, RI = {RA xRA, …}, AI = True,

CI = [hPCC1 = xRA,RC1 = {…},AC1 = True,CC1 = [ ]i]i]

E: [ ]

• In this case, D contains its own “covering” locinv C1.

10/21/2003 31

SummarySummary

• Untrusted verifier extensions allows the code producer– flexibility to use various safety enforcement

mechanisms– to simplify proof generation by incorporating

specialized reasoning in executable form

• Building extensions is simplified by– structuring invariants into first-order pieces– requiring only first-order proofs (specialized

method of proving covers)

10/21/2003 32

IssuesIssues

• Are locinvs too restrictive?

• Can proving coverage be simplified (and made more efficient)?– by specializing to common cases?

Under the Hood of the Open Verifier

Documents