Extensible Untrusted Code Verification

Robert Schneckwith George Necula and Bor-Yuh Evan Chang

May 14, 2003OSQ Retreat

04/19/23 2

Flexibility for Code Producers

• A host receives code from an untrusted agent• Before executing the code, the host wants to

verify certain properties (e.g. memory safety)• The host does not want to restrict the code

producer…... to a particular type system... to particular software conventions

codecode ?

untrusted trusted

• Then how do we verify the code?

04/19/23 3

An Untrusted Verifier

• The code producer supplies the verifier along with the code

codecode ?

untrusted trusted

verifier

verifier

• Too hard to prove correctness of the verifier...

04/19/23 4

An Untrusted Verifier

• The code producer supplies the verifier along with the code

codecode

untrusted trusted

verifier

verifier

• Too hard to prove correctness of the verifier...

extension

extension

OpenVer

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

04/19/23 5

Decoder

• instruction at state s safe if P holds

• proceed to next states D

The Open Verifier

Core

Extension

codecode

trusted

untrusted

state s

• a proof of P• proceed to next states E

and a proof that E covers D

next statesE

04/19/23 6

• The decoder is the canonical symbolic evaluator• Examples of decoding a state (pc = 5 Æ A)

The Decoder

r1 Ã r2 + 1 True pc = 6 Æ r1 = r2 + 1 Æ 9x. A[r1 x]

r1 Ã read r2

addr r2 pc = 6 Æ r1 = (sel m r2) Æ 9x. A[r1 x]

jump F True pc = F Æ A

if Q then jump F

True pc = F Æ A Æ Q ,pc = 6 Æ A Æ :Q

jump *ra True pc = ra Æ A

instruction 5

local safety

next states

• The decoder only handles hardware conventions

04/19/23 7

Soundness and Trustworthiness

• We have proven the soundness of the algorithm used by the core of the Open Verifier

• The trusted code base (core, decoder, proof checker) could be small and simple– thus easy to trust

• We need to ensure the extension is memory safe– Use the extension to verify itself---this one time, run

it in a separate address space

• What about the extensions?– What does it take to write an extension?– How much can extensions do?

04/19/23 8

A Type System of Lists

• Code producer uses accessible memory for lists– “1” is a list (the empty list)– any even address containing a list is a list– nothing else is a list

1. store a à 12. s à read b3. if odd(s) then jump 54. store s à a5. halt

a

s

1

b

16

20

16

20

44

10

10

1

• Consider the program:

04/19/23 9

Informal Proof Obligations

• Proof obligations (informal): “a and b are accessible addresses and if the contents of b

after storing 1 at a is even then it is an accessible address”

– Too low level

• Code producer would prefer instead: “a and b are non-empty lists” – Simpler and easier to prove (using the definition of lists)

• How can the code producer achieve this effect ?

1. store a à 12. s à read b3. if odd(s) then jump 54. store s à a5. halt

a

s

1

b

04/19/23 10

Typing Rules

list 1

list a even a

nelist a

nelist a

list a

inv m nelist a list b

inv (upd m a b)

nelist a inv m

list (sel m a)

nelist a

addr a

1. store a à 12. s à read b3. if odd(s) then

jump 54. store s à a5. halt

Initial state: pc = 1 Æ nelist a Æ nelist b Æ inv m

Decoder local safety: addr a

Decoder next state: pc = 2 Æ nelist a Æ nelist b Æ 9m’. inv m’ Æ m = (upd m’ a 1)

Extension next state: pc = 2 Æ nelist a Æ nelist b Æ inv m

04/19/23 11

Typing Rules

list 1

list a even a

nelist a

nelist a

list a

inv m nelist a list b

inv (upd m a b)

nelist a inv m

list (sel m a)

nelist a

addr a

1. store a à 12. s à read b3. if odd(s) then

jump 54. store s à a5. halt

Initial state: pc = 2 Æ nelist a Æ nelist b Æ inv m

Decoder local safety: addr b

Decoder next state: pc = 3 Æ nelist a Æ nelist b Æ inv m Æ s = (sel m b)

Extension next state: pc = 3 Æ nelist a Æ nelist b Æ inv m Æ list s

04/19/23 12

Producing Proofs

• Using the typing lemmas is completely automatizable– We use a Prolog interpreter where the Prolog

program consists of the typing rules:nelist a :- list a, even a

– Each individual program is then handled automatically

• Proving the typing rules is hard– They become lemmas to be proven by hand in Coq

Definition nelist [a:val] := (addr a) /\ (even a).Definition list [a:val] := (a = 1) \/ (nelist a).Lemma rule : (a:val)(list a) ! (even a) ! (nelist a).Proof...

– But only need to proven once

04/19/23 13

How to Construct an Extension

Type Checker

OpenVer Wrapper

Theorem Prover

Proofs of Lemmas

• Could simply import an existing type checker (e.g. a bytecode

verifier)

• Package the type-checker state into a logical predicate

— requires recognizing invariants which may be implicit in the type-checker

• Use the typing rules in an automated theorem prover

• Instantiate all the typing predicates and rules as definitions and lemmas

04/19/23 14

What can extensions do?

• Software conventions of stacks and function calls– The program had better use the stack safely

• A low-level extension to prove run-time functions– allocator, garbage collector

• Working on an extension for the simple object-oriented language Cool

04/19/23 15

Experience so far...

• We have built a prototype implementation– 5500 lines of ML in the trusted framework

• 1000 lines to parse Mips assembly code• 2000 lines in the logic and proof checker• 120 lines in the decoder

• An extension for the lists example– which also handles the stack and allocation

• 1000 lines in the “standard” type checker• 900 lines to package for the OpenVer and tie it all

together• 600 lines for the Prolog interpreter• 250 lines for the Prolog rules• ??? lines of Coq proof

– compare 4000 lines of Coq script for Java native-code

Extensible Untrusted Code Verification

Robert Schneckwith George Necula and Bor-Yuh Evan Chang

May 13, 2003OSQ Retreat

04/19/23 17

The extension produces different next states...1. generalization

– Only need that memory satisfies an invariant, not its contents

2. re-use of states– loop invariants

– A program to effect y à y0 + x0 (for positive x)

1. while (x > 0) do {2. x à x - 13. y à y + 14. }

– Invariant on line 1: (x ¸ 0 Æ x + y = x0 + y0)

3. “indirect” states– The decoder can’t handle a state without a literal pc– An indirect jump could implement function return, method

dispatch, switch statement, exception handling...