Extensible Verification of Untrusted Code Bor-Yuh Evan Chang, Adam Chlipala, Kun Gao, George Necula, and Robert Schneck May 14, 2004 OSQ Retreat Santa Cruz, California

2 5/14/2004 Type Safety as an Assurance Mechanism Type safety is an accepted assurance mechanism Today –Good:Type check source code in a strongly-typed high-level language (e.g. ML, C#, Java) –Better:Type check intermediate code (e.g., MS-CLI, JVML) OR code untrustedtrusted type checker

3 5/14/2004 Type Systems Today (JVML,MS-CLI,TAL) Hard-wired in the verifier High-level and tailored to particular source languages –E.g, built-in object-oriented features Hard to compile other source languages –Unnatural, loss of performance or expressiveness –E.g, ML ! JVML or Java ! TAL Under constant pressure to become more complex –To handle more source languages –To be able to check more complex code (e.g. optimizations)

4 5/14/2004 Generality by Customization MS-CLI is designed for a multiple languages, but –quite complex (e.g. 6-9 versions of function call) –not complex enough (the ILX project adds more calls) Still not general enough! –JVML: native code interface –MS-CLI: unverifiable subset of the language Proposal: Allow multiple type systems and other verification methods (e.g. PCC) to co-exist –Fix only the safety policy (e.g. memory safety) –Not the enforcement mechanism (e.g. a type system)

5 5/14/2004 Design Goals of the Open Verifier Should be easy to develop “verifier extensions” –Only incrementally more complicated than a conventional verifier for the same language –Be able to retrofit existing compilers or conventional verifiers Client should have complete control over the type system or other conventions –Calling conventions, exceptions, stack usage, data layout

6 5/14/2004 Bytecode Verification Example 2 r arg = 0 3 r rv à r rv r arg à m[r arg ] 1 r rv à 0 5 jump [r ra ] T F 0  ::= int | list | nelist len : list ! int

7 5/14/2004 Bytecode Verification Example 2 r arg = 0 3 r rv à r rv r arg à m[r arg ] 1 r rv à 0 5 jump [r ra ] arg : list arg : list Æ rv : int T F Why? arg : list Æ rv: int arg : nelist Æ rv : int

8 5/14/2004 Bytecode Verifier Correctness How do we know the verifier didn’t forget any checks? –Should not need to provide proofs involving the model of the machine semantics Use strongest post-condition generation to eliminate proof obligations about machine transitions –Show at each program point i with next states N, post(I i ) ) Ç j 2 N I j

9 5/14/2004 Verified Bytecode Verification 2 r arg = 0 3 r rv à r rv r arg à m[r arg ] 1 r rv à 0 5 jump [r ra ] I 1 = arg : list I 2 = arg : list Æ rv : int Why? pc = 2 Æ arg : list Æ rv = 0 post(I 1 )post(I 1 ) ) I 2 new I 2 = post(I 1 ) with add (rv : int) by imm_int with drop (rv = 0) T F

10 5/14/2004 Branch 2 r arg = 0 3 r rv à r rv r arg à m[r arg ] 1 r rv à 0 5 jump [r ra ] arg : list I 2 = arg : list Æ rv : int I 5 = arg : list Æ rv: int Why? pc = 3 Æ arg : list Æ rv : int Æ arg  0 Ç pc = 5 Æ arg : list Æ rv : int Æ arg = 0 post(I 2 ) case post(I 2 ) of I false where (pc = 3) ) new I 3 = I false with let h,h’ = find (arg : list), find (arg  0) in add (arg : nelist) by (cons h h’) with drop (arg : list) with drop (arg  0) | I true where (pc = 5) ) new I 5 = I true with drop (arg = 0) post(I 2 ) ) I 3 Ç I 5 T F I 3 = arg : nelist Æ rv : int

11 5/14/2004 Arithmetic 2 r arg = 0 3 r rv à r rv r arg à m[r arg ] 1 r rv à 0 5 jump [r ra ] arg : list arg : list Æ rv : int arg : list Æ rv: int I 3 = arg : nelist Æ rv : int Why? 9 rv 3. pc = 4 Æ arg : nelist Æ rv 3 : int Æ rv = rv post(I 3 ) new I 4 = post(I 3 ) with let h = find (rv 3 : int) in add (rv : int) by (plus h (imm_int)) with drop (rv 3 : int) with drop (rv = rv 3 + 1) post(I 3 ) ) I 4 T F I 4 = arg : nelist Æ rv : int

12 5/14/2004 Memory Read 2 r arg = 0 3 r rv à r rv r arg à m[r arg ] 1 r rv à 0 5 jump [r ra ] arg : list I 2 = arg : list Æ rv : int arg : list Æ rv: int arg : nelist Æ rv : int I 4 = arg : nelist Æ rv : int Why? 9 arg 4. pc = 2 Æ arg 4 : nelist Æ rv : int Æ addr arg 4 Æ arg = m[arg 4 ] Ç pc = err Æ arg : nelist Æ rv : int Æ : (addr arg) post(I 4 ) case post(I 4 ) of I ok where _ ) I ok with let h = find (arg 4 : nelist) in add (arg : list) by (lem2 h) with … | I err where : (addr arg) by bad ) I err with let h = … in add ? by (bad (lem1 h)) with … post(I 4 ) ) I 2 Ç F T F lem1: If (arg : nelist) then (addr arg) lem2: If (arg : nelist) then (m[arg] : list) F = pc = err Æ ?

13 5/14/2004 Customizability Yields Controlled Trust Trust Meter Trust Any Binary (*.exe) Trust Specialized Verifiers (JVM) Trust Compilers (javac) Trust Typing Rules Trust Model of Machine Semantics

14 5/14/2004 Summary Provide a “natural” language for the verifier to describe in a checkable form the reasoning it makes –Close to conventional type-based verifiers –Amenable to other safety enforcement mechanisms, such as PCC PCC –Most of the time, just goes along with post( ¢ ) –When proof is required, give the proof attached with the code –Proof representation can be chosen by the client

15 5/14/2004 type checker Summary Towards practical extensible verification of untrusted code –Ask only for reasoning already done by conventional verifiers OR untrustedtrusted type checker code post( ¢ ) “preservation and progress”

16 5/14/2004 Conclusion We have verifier extensions for –Cool (“mini-Java”) [Aiken et al.] can verify output of existing Cool compilers –TAL (functional typed assembly language) retrofitted TALx86 [Morrisett et al.] –PCC Philosophy: –To verify complete software systems, not a general, super-expressive type system rather a framework to allow existing ones to work together

18 5/14/2004 Return 2 r arg = 0 3 r rv à r rv r arg à m[r arg ] 1 r rv à 0 5 jump [r ra ] arg : list arg : list Æ rv : int I 5 = arg : list Æ rv: int arg : nelist Æ rv : int Why? pc = ra 0 Æ arg : list Æ rv : int post(I 5 ) post(I 5 ) with drop (arg : list) post(I 5 ) ) R T F R = pc = ra 0 Æ rv : int