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

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

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…

Why a Safe Execution Environment for Commodity Systems? Security Memory error vulnerabilities in OS kernel code are a reality 1 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 (

Secure Virtual Architecture 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 Commodity OS Hardware Compiler + VM Virtual ISA Native ISA

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

Outline  SVA Architecture SVA Safety Experimental Results

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

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

Virtual Instruction Set SVA-Core Based on LLVM 1,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 1.[CGO 2004] 2.

Outline SVA Architecture  SVA Safety Experimental Results

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.

SVA Safety Guarantees Safe LanguageSecure Virtual Architecture Array indexing within bounds No uses of uninitialized variables Type safety for all objectsType safety for subset of objects No uses of dangling pointersDangling pointers are harmless Control flow integrity Sound operational semantics Dangling pointers & non-type-safe objects do not compromise other guarantees Stronger than systems that do not provide any dangling pointer protection

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

Memory Tracking Data Structure 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)); P1 P4 P2 SVM Metadata: Kernel Code: P3 Run-time lookups are too slow Limited opportunity to remove run-time checks

Improved Object Lookups 1 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 Memory Partitioned Object Set Pointers 1. Dhurjati et al. [ICSE 2006]

Type Safe (Homogeneous) Partitions 1 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] 1. Dhurjati et al. [TECS 2005, PLDI 2006] Memory Blue Partition Red Partition

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

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)); P1 P4 P2 SVM Metadata: Kernel Code: P3 MP1 MP3 MP2

Outline SVA Architecture SVA Safety  Experimental Results

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

Linux Kernel Modifications SectionOriginal LOCSVA-OSAllocatorsAnalysisTotal Modified Arch-indep Core9, Net Drivers399, Net Protocols169, Core FS18, Ext35, Total Indep603, Arch-dep29,2374,777014,778 Few memory allocator changes needed Architecture-dependent code almost exclusively modified for SVA-OS port Few changes to architecture-independent code

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

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

Exploits Tried 5 memory exploits that work on Linux Uncaught exploit due to code not instrumented with checks BugTraq IDKernel ComponentCaught? 11956Console Driver Yes! 10179TCP/IP Yes! 11917TCP/IP Yes! 12911Bluetooth Protocol Yes! 13589ELF/Support LibraryNo

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

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

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