Secure Virtual Architecture A Safe Execution Environment for

Secure Virtual Architecture: A Safe Execution Environment for Commodity Operating Systems John Criswell, University of Illinois Andrew Lenharth, University of Illinois Dinakar Dhurjati, Do. Co. Mo 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#) n n n 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 n Research operating systems built with safe languages n Not used in commodity OSs (written in C/C++) Windows n Mac OS X n Linux n Solaris n AIX n BSD n … and many, many others… n

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

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

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

Outline Ø SVA Architecture n SVA Safety n Experimental Results

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

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

Virtual Instruction Set n SVA-Core n Based on LLVM 1, 2 n Typed, Explicit Control Flow Graph, Explicit SSA form n Sophisticated compiler analysis and transformation n SVA-OS n OS-neutral instructions support commodity OSs n Removes difficult to analyze assembly 1. [CGOcode 2004] 2. http: //llvm. org n Encapsulates privileged operations

Outline n SVA Architecture Ø SVA Safety n Experimental Results

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

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

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

Naive Safety Checks Kernel Code: P 1=kmem_cache_alloc(inode_cache); pchk_reg_obj (P 1, reg_size(inode_cache)); … Dest = &P 1[index]; bounds = pchk_get_bounds (P 1); pchk_check_bounds (P 1, Dest, bounds); … P 2=vmalloc(size 1); pchk_reg_obj (P 2, size 1); SVM Metadata: Memory Tracking Data Structure P 1 • Run-time lookups are too slow P 2 • Limited opportunity to remove run-time checks P 3=kmem_cache_alloc(file_cache); pchk_reg_obj (P 3, reg_size(file_cache)); P 4=kmem_cache_alloc(inode_cache); pchk_reg_obj (P 4, reg_size(inode_cache)); P 4

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

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

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

SVM Memory Safety Kernel Code: P 1=kmem_cache_alloc(inode_cache); pchk_reg_obj (MP 1, reg_size(inode_cache)); … Dest = &P 1[index]; bounds = pchk_get_bounds (MP 1, P 1); pchk_check_bounds (P 1, Dest, bounds); P 2=vmalloc(size 1); pchk_reg_obj (MP 2, size 1); P 3=kmem_cache_alloc(file_cache); pchk_reg_obj (MP 3, reg_size(file_cache)); P 4=kmem_cache_alloc(inode_cache); pchk_reg_obj (MP 1, P 4, reg_size(inode_cache)); SVM Metadata: MP 1 P 4 MP 2 MP 3

Outline n SVA Architecture n SVA Safety Ø Experimental Results

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

Linux Kernel Modifications Section Original LOC SVA-OS Allocator Analysi Total s s Modified Arch-indep Core 9, 822 41 76 3 120 Net Drivers 399, 872 12 0 6 18 Net Protocols 169, 832 23 0 29 52 Core FS 18, 499 78 0 19 97 Ext 3 5, 207 0 0 1 1 Total Indep 603, 232 154 76 58 288 4, 777 0 1 Arch-dep 29, 237 Architecture-dependent code almost exclusively modified for SVA-OS port 4, 778 Few memory allocator. Few changes to architecture-independent changes needed code

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

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

Exploits n Tried 5 memory exploits that work on Linux 2. 4. 22 n Uncaught exploit due to code not instrumented Bug. Traq ID Kernel Component Caught? with checks 11956 Console Driver Yes! 10179 TCP/IP Yes! 11917 TCP/IP Yes! 12911 13589 Bluetooth Protocol ELF/Support Library Yes! No

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

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

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