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?