Extensible Untrusted Code Verification Robert Schneck with George Necula and Bor-Yuh Evan Chang May 14, 2003 OSQ Retreat

2 7/12/2015 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 code ? untrustedtrusted Then how do we verify the code?

3 7/12/2015 An Untrusted Verifier The code producer supplies the verifier along with the code code ? untrustedtrusted verifier Too hard to prove correctness of the verifier...

4 7/12/2015 An Untrusted Verifier The code producer supplies the verifier along with the code code untrustedtrusted verifier Too hard to prove correctness of the verifier... extension OpenVer Embed the untrusted verifier as an extension in a trusted framework (the Open Verifier )

5 7/12/2015 Decoder instruction at state s safe if P holds proceed to next states D The Open Verifier Core Extension code trusted untrusted state s a proof of P proceed to next states E and a proof that E covers D next states E

6 7/12/2015 The decoder is the canonical symbolic evaluator Examples of decoding a state (pc = 5 Æ A) The Decoder r 1 Ã r 2 + 1Truepc = 6 Æ r 1 = r Æ 9 x. A[r 1  x] r 1 Ã read r 2 addr r 2 pc = 6 Æ r 1 = (sel m r 2 ) Æ 9 x. A[r 1  x] jump FTruepc = F Æ A if Q then jump F Truepc = F Æ A Æ Q, pc = 6 Æ A Æ : Q jump *raTruepc = ra Æ A instruction 5 local safetynext states The decoder only handles hardware conventions

7 7/12/2015 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?

8 7/12/2015 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 à 1 2.s à read b 3.if odd(s) then jump 5 4.store s à a 5.halt a s 1 b Consider the program:

9 7/12/2015 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 à 1 2.s à read b 3.if odd(s) then jump 5 4.store s à a 5.halt a s 1 b

10 7/12/2015 Typing Rules list 1 list a even 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 à 1 2.s à read b 3.if odd(s) then jump 5 4.store s à a 5.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 Æ 9 m’. inv m’ Æ m = (upd m’ a 1) Extension next state: pc = 2 Æ nelist a Æ nelist b Æ inv m

11 7/12/2015 Typing Rules list 1 list a even 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 à 1 2.s à read b 3.if odd(s) then jump 5 4.store s à a 5.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

12 7/12/2015 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

13 7/12/2015 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

14 7/12/2015 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

15 7/12/2015 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 Schneck with George Necula and Bor-Yuh Evan Chang May 13, 2003 OSQ Retreat

17 7/12/2015 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 à y 0 + x 0 (for positive x) 1.while (x > 0) do { 2. x à x y à y } –Invariant on line 1: (x ¸ 0 Æ x + y = x 0 + y 0 ) 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...