Secure Virtual Architecture: A Safe Execution Environment for Commodity Operating Systems

1. Secure Virtual Architecture:A Safe Execution Environment for Commodity Operating Systems John Criswell, University of Illinois Andrew Lenharth, University of Illinois Dinakar Dhurjati, DoCoMo Communications Laboratories, USA Vikram Adve, University of Illinois

2. What is a Safe Execution Environment? Intuitively, the environment provided by a safe programming language (e.g., Java, C#) • Array indexing stays within object bounds • No uses of uninitialized variables • All operations are type safe • No uses of dangling pointers • Control flow obeys program semantics • Sound operational semantics

3. State of the Art • Research operating systems built with safe languages • Not used in commodity OSs (written in C/C++) • Windows • Mac OS X • Linux • Solaris • AIX • BSD • … and many, many, many others…

4. Why a Safe Execution Environment for Commodity Systems? • Security • Memory error vulnerabilities in OS kernel code are a reality1 • Novel Design Opportunities • Safe kernel extensions (e.g. SPIN) • Single address space OSs (e.g. Singularity) • Develop New Solutions to Higher-Level Security Challenges • Information flow policies • Encoding security policies in type system • Preventing memory exhaustion attacks 1. Month of Kernel Bugs (http://projects.info-pull.com/mokb/)

5. Hardware Secure Virtual Architecture Commodity OS Virtual ISA Compiler + VM Native ISA • Compiler-based virtual machine • Uses analysis & transformation techniques from compilers • Supports commodity operating systems (e.g., Linux) • Typed virtual instruction set enables sophisticated program analysis • Provide safe execution environment for commodity OSs

6. Contributions • Compiler-based virtual machine that • Hosts a commodity OS • Supports sophisticated compiler analysis techniques • First system to provide safety guarantees for complete commodity OS (e.g., Linux) • Retain explicit memory deallocation • Retain custom kernel memory allocators

7. Outline • SVA Architecture • SVA Safety • Experimental Results

8. SVA System Architecture Applications Safety Checking Compiler OS Kernel Drivers OS Memory Allocator SVA ISA Safety Verifier SVA Virtual Machine Native Code Generator Memory Safety Run-time Library SVA-OS Run-time Library Native ISA Hardware Hardware

9. Software Flow Compile-Time: Install/Load/Run-Time: TCB Safety Verifier Bytecode + Run-Time Checks Kernel/Application Source Code Generator Safety Checking Compiler Native Code Bytecode with Safe Types Hardware

10. Virtual Instruction Set • SVA-Core • Based on LLVM1,2 • Typed, Explicit Control Flow Graph, Explicit SSA form • Sophisticated compiler analysis and transformation • SVA-OS • OS-neutral instructions support commodity OSs • Removes difficult to analyze assembly code • Encapsulates privileged operations • Like porting to a new hardware architecture • [CGO 2004] • http://llvm.org

11. Outline • SVA Architecture • SVA Safety • Experimental Results

12. Secure Virtual Architecture Goals • Maximize safety guarantees • Minimize reliance on OS correctness • Minimize kernel changes • Retain original kernel memory allocators • Allocators have special semantics and features • Custom pool allocators (e.g., Linux kmem_cache_alloc()) • Flags for DMA memory, pinned memory, etc.

13. SVA Safety Guarantees • Dangling pointers & non-type-safe objects do not compromise other guarantees • Stronger than systems that do not provide any dangling pointer protection

14. Safety Checks Load/Store Checks Bounds Checks Illegal Free Checks Indirect Call Checks Safety Transforms Stack to heap promotion Memory initialization Safety Checks & Transforms Object Bounds Tracking Methods • “Fat” Pointers [SafeC, CCured, Cyclone,…] • Programmer Annotations [SafeDrive,…] • Object Lookups [Jones-Kelly,SAFECode,…]

15. Naive Safety Checks P1=kmem_cache_alloc(inode_cache); pchk_reg_obj (P1, reg_size(inode_cache)); … Dest = &P1[index]; bounds = pchk_get_bounds (P1); pchk_check_bounds (P1, Dest, bounds); … P2=vmalloc(size1); pchk_reg_obj (P2, size1); P3=kmem_cache_alloc(file_cache); pchk_reg_obj (P3, reg_size(file_cache)); P4=kmem_cache_alloc(inode_cache); pchk_reg_obj (P4, reg_size(inode_cache)); SVM Metadata: Kernel Code: Memory Tracking Data Structure P1 • Run-time lookups are too slow • Limited opportunity to remove run-time checks P2 P3 P4

16. Improved Object Lookups1 Pointers Memory Partitioned Object Set • Alias analysis (DSA) groups objects into logical partitions • Run-time records object allocations in partitions • Run-time checks only consider objects in a single partition • Reduces slowdown from 4x-11x to 10%-30% for nearly all standalone programs, daemons 1. Dhurjati et al. [ICSE 2006]

17. Type Safe (Homogeneous) Partitions1 Memory • Alias analysis performs type inference • Type-homogeneous partitions reduce run-time checks: • No load/store checks • No indirect call checks • Harmless dangling pointers • Type-unsafe partitions require all run-time checks • Proved sound operational semantics [PLDI 2006] Blue Partition Red Partition 1. Dhurjati et al. [TECS 2005, PLDI 2006]

18. Kernel Pool Allocator Constraints • All objects from same pool must be in same partition • Only reuse memory internally for type-homogeneous partitions • Objects must be aligned at a multiple of the object size Inode Kernel Pool Blue Partition Red Partition

19. SVM Memory Safety P1=kmem_cache_alloc(inode_cache); pchk_reg_obj (MP1, P1, reg_size(inode_cache)); … Dest = &P1[index]; bounds = pchk_get_bounds (MP1, P1); pchk_check_bounds (P1, Dest, bounds); P2=vmalloc(size1); pchk_reg_obj (MP2, P2, size1); P3=kmem_cache_alloc(file_cache); pchk_reg_obj (MP3, P3, reg_size(file_cache)); P4=kmem_cache_alloc(inode_cache); pchk_reg_obj (MP1, P4, reg_size(inode_cache)); SVM Metadata: Kernel Code: MP1 P1 P4 MP2 P2 MP3 P3

20. Outline • SVA Architecture • SVA Safety • Experimental Results

21. Prototype Implementation • Ported Linux to SVA instruction set • Similar to porting to new hardware architecture • Compiled using LLVM • Wrote SVA-OS as run-time library linked into kernel • Provide safety guarantees to entire kernel except: • Memory management code • Architecture-dependent utility library • Architecture-independent utility library

22. Linux Kernel Modifications Few memory allocator changes needed Architecture-dependent code almost exclusively modified for SVA-OS port Few changes to architecture-independent code

23. Web Server Bandwidth • Memory safety overhead less than 59% • Transfers of larger file sizes show acceptable overhead

24. Server Latency Overhead • Many short data transfers suffer high memory safety overhead • Overhead acceptable for larger file sizes Acceptable overhead for security-critical servers

25. Exploits • Tried 5 memory exploits that work on Linux 2.4.22 • Uncaught exploit due to code not instrumented with checks

26. Performance Improvements • Source code changes • Smarter run-time checks • Selective use of “fat” pointers • Pre-checking all accesses within monotonic loops • Removing redundant object lookups and run-time checks • Very fast indirect call checks • Improve static analysis • Stronger type inference • More precise call graph • Restore context sensitivity • Static array bounds checking

27. Future Work • Ensure safe use of: • SVA-OS instructions • MMU configuration • DMA operations • Novel OS Designs • Recovery semantics for the virtual machine • Private application memory • Information flow

28. Contributions • Compiler-based virtual machine that • Hosts a commodity OS • Supports sophisticated compiler analysis techniques • First system to provide safety guarantees for complete commodity OS (e.g., Linux) • Retain explicit memory deallocation • Retain custom kernel memory allocators Questions? See what we do at http://llvm.org