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

John Criswell, University of IllinoisAndrew Lenharth, University of Illinois

Dinakar Dhurjati, DoCoMo Communications Laboratories, USAVikram 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 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/)

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

HardwareCompiler + VMVirtual ISANative 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 SafetyRun-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-timeLibrary

Safety Verifier

Hardware

Software Flow

Safety CheckingCompiler

Safety Verifier

Code Generator

Compile-Time: Install/Load/Run-Time:

Kernel/ApplicationSource

Bytecodewith

Safe Types

Bytecode+

Run-Time Checks

Native Code

Hardware

TCB

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

1. [CGO 2004]2. http://llvm.org

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 Language Secure Virtual Architecture

Array indexing within bounds Array indexing within boundsNo uses of uninitialized variables No uses of uninitialized variablesType safety for all objects Type safety for subset of objectsNo uses of dangling pointers Dangling pointers are harmlessControl flow integrity Control flow integritySound operational semantics 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 TrackingData 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 Lookups1

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

PartitionedObject Set

Pointers

1. Dhurjati et al. [ICSE 2006]

Type Safe (Homogeneous) Partitions1

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

Section Original LOC SVA-OS Allocators Analysis Total 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

Ext3 5,207 0 0 1 1

Total Indep 603,232 154 76 58 288

Arch-dep 29,237 4,777 0 1 4,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

0%

10%

20%

30%

40%

50%

60%

70%

1 2 4 8 16 32 64 128

File Size in KB

Per

cent B

andw

idth

R

educt

ion R

elati

ve to

Nati

ve

thttpd apache

Server Latency Overhead

0%

20%

40%

60%

80%

100%

120%

140%

1 2 4 8 16 32 64 128 256

File Size in KB

Perc

ent O

verh

ead

Rela

tive

to N

ati

ve

thttpd apache

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 2.4.22 Uncaught exploit due to code not instrumented with checks

BugTraq ID Kernel Component Caught?

11956 Console Driver Yes!

10179 TCP/IP Yes!

11917 TCP/IP Yes!

12911 Bluetooth Protocol Yes!

13589 ELF/Support Library No

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 http://llvm.org