Proof-Carrying Code
1997 · paper · Computer science
Describes proof-carrying code, in which untrusted code arrives with a safety proof that a host can quickly check against a safety policy. Case studies include safe assembly extensions of ML programs and network packet filters that are faster than comparable filters and guaranteed safe.
Checked: PDF from courses.grainger.illinois.edu, fetched 4 Oct 2026. Page numbers are those of that PDF.
3 findings
Substance Figure 9 (p14) lists object normalization rules nm_var, nm_c, nm_app and nm_beta only. No rule normalizes a λ-abstraction, so 'M ⇓ λx:A.M′' (the premise of nm_beta) is not derivable, and at_app cannot type second-order applications such as all_i (λx:exp.⌜P⌝).
- p. 14 Figure 9, Normalization rules
M ⇓ λx:A.M′ N ⇓ N′
- p. 13 Theorem B.4 / LF0 discussion
the term [N′/x]M′ is known to be in canonical form
Only the authors can say what is right here.
Judge's note: Checked Fig. 9 on p14. The object rules conclude x⇓x, c⇓c, M N⇓M′N′ (from M⇓M′, N⇓N′) and M N⇓[N′/x]M′ (from M⇓λx:A.M′). None has a λ-term as subject or result, so by induction no judgment λx:A.M⇓… and no M⇓λx:A.M′ is derivable. The signature on p3 gives all_i : Πp:exp→pred.(Πv:exp.pf(p v))→pf(all p), with ⌜D⌝ = all_i (λx:exp.⌜P⌝)(λv:exp.⌜D⌝). at_app on all_i with N = λx:exp.true needs [N/p]B⇓B′. That requires pf((λx:exp.true) v)⇓…, which is not derivable through either nm_app or nm_beta. So, with the rules as printed, Theorem B.4 / Corollary B.5 fail for derivations that use all_i. Adding a rule for λ (A⇓A′, M⇓M′ ⟹ λx:A.M⇓λx:A′.M′) would close the gap. Only the authors can say whether such a rule was intended.
Second check: another model agreed
Report a problem with this finding
Wording The first VC conjunct on p.6 reads 'rm ⊢ r0 : Foo list ⊃ ( rm ⊢ r0 : Foo list ∧ rm ⊢ 0 : int)', but the example's type is T list.
- p. 6 Section 3, Computing the Verification Condition, displayed first conjunct
r_m ⊢ r_0 : Foo list ⊃ ( r_m ⊢ r_0 : Foo list ∧
- p. 6 VC for example program, first conjunct
r_m ⊢ r_0 : Foo list ⊃ ( r_m ⊢ r_0 : Foo list ∧ r_m ⊢ 0 : int)
- p. 5 Precondition and loop invariant
Pre ≡ r_m ⊢ r_0 : T list
- p. 6 Computing/Verification condition example, displayed formula
rm ⊢ r0 : Foo list ⊃ ( rm ⊢ r0 : Foo list ∧ rm ⊢ 0 : int)
Judge's note: Page 5 gives Pre ≡ rm ⊢ r0 : T list and the L2 invariant rm ⊢ r0 : T list ∧ rm ⊢ r1 : int. Substituting [0/r1] into the invariant gives rm ⊢ r0 : T list ∧ rm ⊢ 0 : int. 'Foo' is defined nowhere in the paper. The page 6 image shows 'Foo list' twice.
Second check: another model agreed
Report a problem with this finding
Wording Lemma A.1 proof, Case BEQ (pp.12-13): the hypothesis is printed as '▷ρ(r_s = 0 ⊃ VC_{pc+1} ∧ r_s ≠ 0 ⊃ VC_{pc+n+1})' and the r_s ≠ 0 case concludes '▷ρ(VC_{pc+n+1}), which is exactly what we have to prove'. Figure 6 gives (r_s = 0 ⊃ VC_{i+n+1}) ∧ (r_s ≠ 0 ⊃ VC_{i+1}), and Figure 8 goes to pc+1 when r_s ≠ 0.
- p. 12 Appendix A, proof of Lemma A.1, Case BEQ
VC_{pc+1} ∧ r_s ≠ 0 ⊃ VC_{pc+n+1}
- p. 13 Appendix A, continuation of BEQ case
elimination we get that ▷ ρ( VC_{pc+n+1}), which is exactly what we have to prove.
- p. 6 Figure 6, BEQ case
(r_s = 0 ⊃ VC_{i+n+1}) ∧ (r_s ≠ 0 ⊃ VC_{i+1})
- p. 13 Appendix A, proof of Lemma A.1, continuation of Case BEQ
we get that ▷ ρ(VC_{pc+n+1}), which is exactly what we have to prove
Only the authors can say what is right here.
Judge's note: Checked on the images. Fig. 6 (p6) has BEQ VC = (r_s=0 ⊃ VC_{i+n+1}) ∧ (r_s≠0 ⊃ VC_{i+1}). Fig. 8 (p12) has (ρ,pc+n+1) if r_s=0 and (ρ,pc+1) if r_s≠0. The proof on pp.12-13 swaps the targets. I reworked the step from Fig. 6: conjunction elimination gives ▷ρ(r_s≠0 ⊃ VC_{pc+1}), and implication elimination with ▷ρ(r_s≠0) then gives ▷ρ(VC_{pc+1}), with ρ'=ρ and pc'=pc+1 as Fig. 8 requires. The printed conclusion VC_{pc+n+1} does not match the successor state for r_s≠0. Swapping the indices repairs the step, and Lemma A.1 still holds.
Second check: another model agreed
Report a problem with this finding
13 minor (typos and the like; most checked by the judge only)
Wording The Figure 5 example uses 'MOV r1, 0', 'BR L2' and 'MOV r0, r1', but the VC generator (Figure 6) covers only ADD, LD, BEQ, RET and INV, and the abstract machine (Figure 8) covers only ADDQ, LDQ, BEQ and INV.
- p. 5 Figure 5, lines 1, 13 and 14
MOV r_1, 0
- p. 6 Figure 6
if Π_i = INV I
Only the authors can say what is right here.
Judge's note: Checked on the page images. Figure 5 (p.5) uses MOV at lines 1 and 14 and BR at line 13. Figure 6 (p.6) and Figure 8 (p.12) have no cases for MOV or BR. Page 12 says the machine halts 'when ... invalid instructions are encountered'. The text never says that MOV and BR are pseudo-instructions that expand to supported forms. The figures also name the same instructions differently (ADD/LD in Fig. 6, ADDQ/LDQ in Fig. 8). This is a gap in the presentation only the authors can resolve, not an evident typo.
Second check: another model agreed
Report a problem with this finding
Wording Page 8: 'The safety proof contains the LF representations of the invariants—less the precondition, which is supplied by the code producer—' conflicts with page 5, where the code consumer prepends 'INV Pre', and with page 2, where the interface is part of the consumer's safety policy.
- p. 8 Quantitative Results, first paragraph
less the precondition, which is supplied by the code producer
- p. 5 Computing the Verification Condition
the code consumer prepends the instruction INV Pre to each untrusted program
- p. 8
which is supplied by the code producer
Only the authors can say what is right here.
Judge's note: Page 2 image: the safety policy, including the interface (the invariants holding when the consumer invokes the foreign code), 'is defined and made public by the code consumer'. Page 5 image: 'the code consumer prepends the instruction INV Pre to each untrusted program'. Page 8 image says the precondition is 'supplied by the code producer'. It is also unclear why the precondition would be left out of the proof if the producer supplied it. 'Consumer' was probably meant; only the authors can confirm.
Second check: another model agreed
Report a problem with this finding
Wording In 'VC(Π, Inv, Post) = ∀r_i. ⋀_{i∈Inv} Inv_i ⊃ VC_{i+1}' (p.6), the index i is used both for the quantified registers and for the invariant points.
- p. 6 Definition of VC(Π, Inv, Post)
VC(Π, Inv, Post) = ∀r_i. ⋀_{i∈Inv} Inv_i ⊃ VC_{i+1}
Judge's note: Confirmed in the page 6 image. The intended meaning (quantify over all registers) can be inferred, but as printed the same letter serves as two bound indices. This is a notational ambiguity, not an error in the result.
Second check: another model agreed
Report a problem with this finding
Wording Lemma A.1 proof, Case 'Π_pc = ADD r_s, op, r_d' (p12): the body uses '▷ρ([r_s + n/r_d] VC_{pc+1})' and 'ρ' = ρ∘[r_s + n/r_d]', while Figures 6 and 8 use [r_s + op/r_d].
- p. 12 Appendix A, proof of Lemma A.1, Case ADD
From hypothesis ▷ ρ([r_s + n/r_d] VC_{pc+1})
- p. 6 Figure 6, ADD case
[r_s + op/r_d] VC_{i+1}
- p. 12 Proof of Lemma A.1, Case ADD
▷ ρ([r_s + n/r_d] VC_{pc+1})
- p. 12 Lemma A.1 proof, ADD case
ADD r_s, op, r_d. From hypothesis ▷ ρ([r_s + n/r_d] VC_{pc+1})
Only the authors can say what is right here.
Judge's note: The p12 image shows the case header with op and the body with n. Figure 6 (p6) and Figure 8 (p12) both use r_s + op. n is not bound in this case (it is the LD/BEQ offset). The argument goes through once n is read as op, so this is a symbol slip and the result stands.
Second check: another model agreed
Report a problem with this finding
Wording Page 8: 'For the particular signature L, normalization is only involved in checking instances of the universal quantification elimination rule schema'. But under the at_app rule, checking the ∀-introduction representation all_i (λx:exp.⌜P_x⌝)(λv:exp.⌜D_v⌝) also involves a β-redex.
- p. 8 Section 3, paragraph after Corollary 3.3
normalization is only involved in checking instances of the universal quantification elimination rule schema
- p. 7 Signature constant all_i
(Πv:exp.pf (p v)) → pf (all p)
Only the authors can say what is right here.
Judge's note: My own working from the page 7 and page 14 images. all_i : Πp:exp→pred.(Πv:exp.pf (p v)) → pf (all p). Applying all_i to N = λx:exp.⌜P_x⌝ uses at_app, whose premise [N/p]B ⇓ B′ must normalize pf ((λx:exp.⌜P_x⌝) v). That is a β-redex, so nm_beta is needed. By contrast, and_i and impl_i instantiate p:pred with non-lambda terms, so they create no redex. The literal 'only elimination' claim therefore does not match the signature as printed. The soundness and adequacy results are unaffected.
Second check: another model agreed
Report a problem with this finding
Wording Corollary 3.3 assumes '· ⊢_L M :_LF pf ⌜P⌝', but the same result restated as Corollary B.5 assumes '· ⊢_L M :_c pf ⌜P⌝', the canonical LF0 judgment that Theorems 3.2 and B.4 are stated for.
- p. 8 Corollary 3.3
M :_LF pf ⌜P⌝
- p. 14 Corollary B.5
M :_c pf ⌜P⌝
- p. 8 Corollary 3.3
· ⊢_L M :_LF pf ⌜P⌝
- p. 14 Corollary B.5
· ⊢_L M :_c pf ⌜P⌝
Only the authors can say what is right here.
Judge's note: Page 8 image: Corollary 3.3 has ':_LF'. Page 14 image: Corollary B.5 has ':_c'. Both are introduced as the corollary of the adequacy theorem, and Theorems 3.2 and B.4 are stated with ':_c'. To get the :_LF version from those theorems, a reader would need a completeness result (canonical and LF-typable implies LF0 :_c-typable), and the paper does not state one. The intended statement is probably the :_c form, but only the authors can confirm.
Second check: another model agreed
Report a problem with this finding
Typo Garbled phrase on p.5: 'to ensure that the foreign code is accompanied contains a valid proof of it.'
- p. 5 Section 3, Computing the Verification Condition, right column top
the foreign code is accompanied contains a valid proof of it
- p. 5 right column, first paragraph
the code consumer to ensure that the foreign code is accompanied contains a valid proof of it.
Judge's note: Visible in the page 5 image, right column, first paragraph. The sentence combines 'is accompanied by' and 'contains'.
Second check: none (judge only)
Report a problem with this finding
Typo Duplicated word on p.6: 'says both that the the loop invariant is preserved'.
- p. 6 Section 3, paragraph after first conjunct
says both that the the loop invariant is pre-
- p. 6
both that the the loop invariant is preserved
Judge's note: Visible in the page 6 image, left column, in the paragraph after the displayed conjunct. Both copies of 'the' are on the same line.
Second check: none (judge only)
Report a problem with this finding
Typo Figure 8 names the instructions 'ADDQ r_s, op, r_d' and 'LDQ r_d, n(r_s)', while Figure 6 and the Lemma A.1 case analysis use 'ADD' and 'LD'.
- p. 12 Figure 8
if Π_pc = ADDQ r_s, op, r_d
- p. 6 Figure 6
if Π_i = ADD r_s, op, r_d
- p. 12 Figure 8, abstract machine rules
ADDQ r_s, op, r_d
- p. 6 Figure 6, VC generator
ADD r_s, op, r_d
Judge's note: Checked on the images: Fig. 8 (p12) uses ADDQ/LDQ, while Fig. 6 (p6) and the proof cases (p12) use ADD/LD. These are the real Alpha mnemonics and the meaning is clear, so this is a minor naming inconsistency.
Second check: none (judge only)
Report a problem with this finding
Typo Corollary 3.3 reads 'there exists a derivation of D :: ▷ P' where Corollary B.5 reads 'there exists a derivation D :: ▷ P'; the 'of' is stray.
- p. 8 Corollary 3.3
there exists a derivation of D :: ▷ P
- p. 14 Corollary B.5 (same statement)
there exists a derivation D :: ▷ P
Judge's note: Confirmed on the page 8 and page 14 images. D is the derivation itself, so 'of' is a stray word.
Second check: none (judge only)
Report a problem with this finding
Typo Wrong article in Section 7 Conclusion: 'any attempt to alter either the native code or proof in an PCC binary' should read 'a PCC binary'.
- p. 10 Section 7 Conclusion, first paragraph
or proof in an PCC binary
- p. 10 Section 7 Conclusion, first paragraph
either the native code or proof in an PCC binary
- p. 10
in an PCC binary
Judge's note: The p10 image, right column, Conclusion paragraph 1, clearly prints 'in an PCC binary'. Elsewhere the paper uses 'a PCC binary'.
Second check: none (judge only)
Report a problem with this finding
Typo Missing word in Section 7 Conclusion: 'the certification must be done only once independently how many times the code is used' lacks 'of' ('independently of how many times').
- p. 10 Section 7 Conclusion, third paragraph
be done only once independently how many times the
Judge's note: The p10 image, right column, Conclusion paragraph 3, shows the text as quoted, without 'of'.
Second check: none (judge only)
Report a problem with this finding
Typo Appendix A, before Lemma A.1: 'the execution terminates immediately in a state the satisfies the postcondition' should read 'a state that satisfies'.
- p. 12 Appendix A, paragraph before Lemma A.1
in a state the satisfies the postcondition
Judge's note: The p12 image, right column, paragraph 'The central result...', prints 'a state the satisfies'.
Second check: none (judge only)