Upload
tamyra
View
32
Download
0
Embed Size (px)
DESCRIPTION
Under the Hood of the Open Verifier. Bor-Yuh Evan Chang, Adam Chlipala, Kun Gao, George Necula, and Robert Schneck October 21, 2003 OSQ Group Meeting. OV. PCC. FPCC. Less Flexible. More Flexible. Issues with PCC and FPCC. Flexibility - PowerPoint PPT Presentation
Citation preview
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
FPCC
OV
PCC
10/21/2003 3
Issues with PCC and FPCCIssues with PCC and FPCC
• Scalability– Can the proof obligations for the code producer
be simplified?
More ScalableLess Scalable
PCC
OV
FPCC
10/21/2003 4
Issues with PCC and FPCCIssues with PCC and FPCC
• 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
code
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
code
10/21/2003 8
The Open VerifierThe Open Verifier
Decoder Director
Extension
trusteduntrusted
locinv II
next locinvsEE
code
StandardStandardCoolCool
VerifierVerifier
Cool Extension
DefinitionsDefinitionsandand
LemmasLemmas
10/21/2003 9
The Open VerifierThe Open Verifier
Decoder Director
Extension
trusteduntrusted
locinv II
next locinvsEE
code
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
• instruction at locinv II safe if PP holds
• next locinvs DD
Director
Extension
trusteduntrusted
locinvII
• a proof of PP• a proof that EEcovers DD
next locinvsEE
code
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
rTHIS : R, rTHIS 0, rx : S
1 Rf: rx := rTHIS
2 L2: if rx=0 jump L9
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
• instruction at locinv II safe if PP holds
• next locinvs DD
Director
Extension
trusteduntrusted
locinvII
• a proof of PP• a proof that EEcovers DD
next locinvsEE
code
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
2 L2: if rx=0 jump L9
10/21/2003 14
Local Invariants - Part 2Local Invariants - Part 2
• Existentially quantified predicates parameterized by the machine state and structured into
– first-order assumptions A
Decoder
• instruction at locinv II safe if PP holds
• next locinvs DD
Director
Extension
trusteduntrusted
locinvII
• a proof of PP• a proof that EEcovers DD
next locinvsEE
code
• 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
• instruction at locinv II safe if PP holds
• next locinvs DD
Director
Extension
trusteduntrusted
locinvII
• a proof of PP• a proof that EEcovers DD
next locinvsEE
code
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]
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
(E covers D)
rx : S ) rx : R Æ rx 0
10/21/2003 21
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 : S]
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
(E covers D)
rx : S ) rx : R Æ rx 0
10/21/2003 22
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 : S] (from before)• Coverage is trivially
satisfied here• Do not know the
incremental changes
rTHIS : R, rTHIS 0, rx : S
1 Rf: rx := rTHIS
rx : S
2 L2: if rx=0 jump L9
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
7 L7: rx := rRV rx : 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
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.”
. (rPC ) = 9
Æ (rSAVE ) = 1
Æ safe (’. (rPC ’) = (rRA )
Æ (rSAVE ’) = (rSAVE ))
10/21/2003 26
Local Invariants - Part 3Local Invariants - Part 3
• 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
Local Invariants - Part 3Local Invariants - Part 3
• 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
means
• 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?