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

1
Secure Virtual ArchitectureA 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
• A language is type-safe if the only operations
  that can be performed on data in the language are
  those sanctioned by the type of the data.
• 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
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 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,

15
Naive Safety Checks
SVM Metadata
Kernel Code
Memory Tracking Data Structure

• P1kmem_cache_alloc(inode_cache)
• pchk_reg_obj (P1, reg_size(inode_cache))
• Dest P1index
• bounds pchk_get_bounds (P1)
• pchk_check_bounds (P1, Dest, bounds)
• P2vmalloc(size1)
• pchk_reg_obj (P2, size1)
• P3kmem_cache_alloc(file_cache)
• pchk_reg_obj (P3, reg_size(file_cache))
• P4kmem_cache_alloc(inode_cache)
• pchk_reg_obj (P4, reg_size(inode_cache))

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
SVM Metadata
Kernel Code

• P1kmem_cache_alloc(inode_cache)
• pchk_reg_obj (MP1, P1, reg_size(inode_cache))
• Dest P1index
• bounds pchk_get_bounds (MP1, P1)
• pchk_check_bounds (P1, Dest, bounds)
• P2vmalloc(size1)
• pchk_reg_obj (MP2, P2, size1)
• P3kmem_cache_alloc(file_cache)
• pchk_reg_obj (MP3, P3, reg_size(file_cache))
• P4kmem_cache_alloc(inode_cache)
• pchk_reg_obj (MP1, P4, reg_size(inode_cache))

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