Modular Machine Code Verification

1. PhD Thesis Defense Modular Machine Code Verification Zhaozhong Ni Advisor: Zhong Shao Committee: Zhong Shao, Paul Hudak Carsten Schürmann, David Walker Department of Computer Science, Yale University Nov. 29, 2006

2. 19 Lines of Code on Every PC ; load new context mov eax, [esp+8] mov esp, [eax+28] mov ebp, [eax+24] mov edi, [eax+20] mov esi, [eax+16] mov edx, [eax+12] mov ecx, [eax+8] mov ebx, [eax+4] mov eax, [eax+0] ret swapcontext: ; store old context mov eax, [esp+4] mov [eax+0], OK mov [eax+4], ebx mov [eax+8], ecx mov [eax+12], edx mov [eax+16], esi mov [eax+20], edi mov [eax+24], ebp mov [eax+28], esp

3. 19 Lines of Code in Every ms swapcontext: • Runs thousands of time per second • Used by assembly, C, MSIL, JVML, etc. • Basis of multi-tasking, OS, and software • Safety and correctness taken for granted

4. 19 Lines of Code Looks Simple swapcontext: … call swapcontext … eax a1 retp ebx OK a2 old b1 ecx a3 new edx a4 … b2 esi a5 b3 edi b4 a6 b5 ebp a7 esp a8 a8 b6 b7 b8 … … … retp’ …

5. 19 Lines of Code Proven Hard swapcontext: • Simple code, complex reasoning! • stack / heap / memory mutation • procedure call / first-class code pointer • protection / polymorphism • Lack specification and verification that are • formal (machine checkable in sound logic) • general (allows all possible usage of context) • realistic (usable from assembly and C level)

6. Outline • Introduction • The XCAP Framework • Mini Thread Library • Connect XCAP to TAL • Conclusion

7. Software Reliability • Bugs are costly • Especially important for • mission-critical software • consumer electronics software • internet software

8. Test-Patch Approach • Works most of the time • Gives no guarantee • Could make things worse test debug yes pre-release? no create patch

9. Language-based Approach • Uses types and other formal specifications • Excludes all bugs in certain categories illegal command, overflow, dangling pointer, etc. • Successful and popular ML, Java, C#, etc. • Reached virtual machine code level JVML, MSIL, TIL, TAL, etc. • Meta-theorems can make guarantees

10. Traditional Assumptions • Types are for application software you can not write OS without (void *) • Types are for high-level languages not much to talk about 89 84 24 07 5B CD 15 • Types are only for “no blue screen” how about “variable x is a prime number” • Type safety are bad for performance turn off array-bound checking before release

11. Program Specification syntactic types bool prime (int n) { assert (n > 0); for (int i = 2; i < n; i ++) // n mod 2,…,i-1 ≠ 0 if (n % i == 0) return false; // n mod 2,…,n-1 ≠ 0 return true; } machine-logical specifications meta-logical specifications

12. Machine Code Verification • Motivations • everything goes down to binary • high-level safety efforts lost in compilation • critical code directly written in low level • Challenges • Expressiveness • Modularity • Goals • both user and system level code • modular specification + certification

13. Proof-Carrying Code • Proposed 10 years ago [Necula & Lee] • machine code • machine checkable proof Code Specification Proof Meta theory Checker

14. Foundational PCC • Proposed by [Appel] Code Specification Proof Meta theory Checker mathematic logic theory mathematic logic checker

15. Approaches to PCC • Type-based PCC • TAL [Morrisett98] • Touchstone PCC [Colby00] • Syntactic FPCC[Hamid02] • FTAL [Crary03] • LTAL[Chen03] • … • Modular • Generate proof easily • Type safety • Logic-based PCC • Original PCC [Necula98] • Semantic FPCC [Appel01] • CAP [Yu03] • Open Verifier [Chang05] • CCAP/CMAP [Yu04, Feng05] • … • Expressive • Advanced properties • Good interoperability

16. PCC After 10 Years In principle, can verify any machine code! In reality, many programs are not verified. For some code, we do not know HOW! Code Specification Proof Meta theory Checker

17. User-level Code: List Append Adapted from [Reynolds02] ……

18. User-level Code: List Append Adapted from [Reynolds02] ……

19. User-level Code: List Append Adapted from [Reynolds02]

20. ECP Problem w. Hoare Logic • Embedded code pointers (ECP) Examples: computed GOTOs, higher-order functions, indirect jumps, continuations, return addresses “… are difficult to describe in … Hoare logic”[Reynolds02] • Previous approaches • Ignore ECP [Necula98, Yu04] • Limit ECP specifications to types [Hamid04] • Sacrifice modularity [Yu03] • Use complex indexed semantic models [Appel01]

21. Outline • Introduction • The XCAP Framework • Mini Thread Library • Connect XCAP to TAL • Conclusion

22. The XCAP Framework [POPL’06] • A logic-based PCC framework • modular verification of machine code • supports ECP without compromise • Support both system and user code • Consists of • target machine (not fixed) • assertion language (consistency) • inference rules (soundness)

23. Target Machine

24. Dynamic Semantics

25. Certified Assembly Programming [Yu03, Hamid04, Yu04, Feng05] • Hoare logic in CPS • Use general predicate logic for assertions example: • Mechanized in a proof assistant (Coq) • Extensions made: CCAP, CMAP, etc.

26. How CAP Certify Instructions

27. How CAP Certify Programs …

28. The ECP Problem cptr(f, a) = ?

29. Previous Approach • Internalize Hoare-derivation for ECP Circularity! • Stratification [OHearn97, Naumann01] • Works for simple case • Hard for assembly • Hard for polymorphism • Step-Indexing [Appel01, Appel02, Schneck03] • Works for polymorphism • Heavyweight • Not standard Hoare logic

30. CAP’s Approach • Specify ECP by checking against code spec • Verify all code specs are indeed valid • Modularity problem

31. The XCAP Approach • Specify ECP independent of code spec • Check ECP against global code spec • Verify global code spec is indeed valid

32. Extended Propositions

33. XCAP Rules

34. How XCAP Works with ECP (SEQ) (ECP) (JMP) (JD)

35. Verification of append()

36. Impredicative Polymorphisms • Important for ECP • Naïve interpretation function fails

37. New Interpretation Interpretation Soundness of interpretation Consistency

38. Recursive Specification • Simple recursive data structures • linked list, queue, stack, tree, etc. • supported via inductive definition of Prop • Complex recursive structures with ECP • object (self refers to the entire object) • threading invariant (each thread assumes others) • Recursive specification

39. Memory Mutation • Strong update • special conjunction (p * q) in separation logic • directly definable in Prop and PropX • explicit alias control, popular in system level • Weak update (general reference) • mutable reference (int ref) in ML • managed data pointers (int __gc*) in .NET • rely on GC to recycle memory • popular in user level

40. Weak Update • Reference cell • Interpretation • Record macro

41. Implementation in Coq • PropX can share similar tactics with Prop

42. Outline • Introduction • The XCAP Framework • Mini Thread Library • Connect XCAP to TAL • Conclusion

43. Why Thread Library? • Concurrent verification • primitives’ correctness is assumed • primitives are not really “primitive”! • poor portability due to lack of formal spec • Core of OS kernel • assignment 1 of OS course • written in C and Assembly • requires both safety and efficiency

45. A Mini Thread Library • Modeled after Pth • Non-preemptive user level threads • Written in (subset of) x86 assembly

46. Threading Model

47. Modules and Interfaces

48. Verify That 19 Lines of Code Step 1: specify machine context Step 2: specify function call/return Step 3: specify swapcontext() Step 4: prove it!

49. Machine Context typedef struct mctx_st *mctx_t; struct mctx_st { int eax,int ebx,int ecx,int edx, int esi, int edi, int ebp,int esp }; mctx retv public bx cx private dx cs si di bp sp ret … … … …

50. Function Call / Return excess space local storage esp return address argument 1 argument 2 … argument n caller frames