Secure Virtual ArchitectureJohn Criswell, Arushi Aggarwal, Andrew Lenharth, Dinakar Dhurjati, and Vikram AdveUniversity of Illinois at Urbana-Champaign

1

Secu

re V

irtu

al A

rchit

ect

ure

Outline• Background• Current Work• Future Work

2

Secu

re V

irtu

al A

rchit

ect

ure

transformation

HARDWARE SYstem architectures

SVA

Binary translation and

emulation

Formal methods

Hardware support for isolation

Dealing with malicious hardware

Cryptographic secure computation

Data-centric security

Secure browser appliance

Secure servers

web-based architectures

e.g., Enforce properties on a malicious OS

e.g., Prevent dataexfiltration

e.g., Enable complex distributed systems, with resilience to hostile OS’s

Secu

re V

irtu

al A

rchit

ect

ure

3

Wouldn’t It Be Great?• Enforce information flow policy• Confidentiality• Data-centric policy created by application/user

• Malicious OS can examine/modify any data in memory• Need to control OS memory operations

• Keep system running when a safety violation is detected

4

Secu

re V

irtu

al A

rchit

ect

ure

Process1

Process1

Process2

Process2

Operating SystemOperating System

MemoryMemory

Secure Virtual Architecture

• Compiler-based virtual machine• Uses sophisticated compiler analysis & transformation techniques

• Virtual instruction set• Typed virtual instruction set enables sophisticated program analysis• Special instructions for OS kernel support

• Provide safe execution environment for commodity software• Supports unmodified C/C++ applications• Supports commodity operating systems (e.g., Linux)

5

CommodityApplications + OS

Compiler + VMVirtual ISANative ISA

Secu

re V

irtu

al A

rchit

ect

ure

SVA Safety Guarantees

Safe Language Secure Virtual Architecture

Control flow integrity Control flow integrityArray 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 harmlessSound operational semantics Sound operational semantics

• Dangling pointers & non-type-safe objects do not compromise other guarantees• Strongest memory safety for C sans garbage collection

6

Secu

re V

irtu

al A

rchit

ect

ure

What’s the Secret Sauce?• Run-time Checks• Load/Store Checks• Bounds Checks• Illegal Free Checks• Indirect Call Checks

• Static Analysis• Type Inference• Points-to Analysis

7

Secu

re V

irtu

al A

rchit

ect

ure

Outline• Background• Current Work• Future Work

8

Secu

re V

irtu

al A

rchit

ect

ure

Safe Software/Hardware InteractionOperation Problem Solution

Context Switching Kernel can load bad state on to CPU

Store CPU state in SVA VM memory

Stack Management Kernel stacks are regular, mutable memory objects

SVA creates new type of memory object for kernel stacks; pointers to such objects cannot be dereferenced

MMU Configuration Static analysis assumes virtual address space is immutable

Use para-virtualization to prevent MMU configurations that violate static analysis safety guarantees

9

Secu

re V

irtu

al A

rchit

ect

ure

A Secure Foundation• Strong memory safety enforcement• Even for low level OS code!

• Can rely on static analysis results to hold at run-time• Enforces safety properties on applications and OS kernel code

10

Secu

re V

irtu

al A

rchit

ect

ure

Safety enforced despite hostile OS Code!

Current Work• Information Flow for C• Improved Type Inference• Recovery from Safety Violations

11

Secu

re V

irtu

al A

rchit

ect

ure

CIF: C Information Flow Compiler• Experimental information flow infrastructure for C/C++• Explicit information flow on memory object granularity• Properly joins (meets) labels for computation results• Based on SVA• Memory safety errors cannot violate safety guarantees• Can reuse SVA infrastructure for optimization

12

DataData

DataData

MemoryObject

MemoryObject

Process

Meet

Secu

re V

irtu

al A

rchit

ect

ure

SVA Controls Information Flow

• SVA controls• Memory access• MMU configuration• Information Flow

• Uniform monitoring• SVA enforces policies• Not the OS

13

Process1

Process1

Process2

Process2

SVA Virtual MachineSVA Virtual Machine

Operating SystemOperating System

MemoryMemory Secu

re V

irtu

al A

rchit

ect

ure

Improving Type Safety in SVA• Benefits• Better pointer disambiguation due to improved field sensitivity• Better safety

• More static type safety yields more precise run-time safety guarantees

• Better performance• Type-safe objects do not need load/store checks

14

Secu

re V

irtu

al A

rchit

ect

ure

Type Safety Enhancements• Tracking types at byte-offsets• Permit a subset of a memory object to be type safe• Supports C++ class hierarchy sub-typing

• Identifying C library functions and allocator wrappers• Static code transformations to improve inference results• Cloning of address-taken functions for use in direct calls• Clone functions that take embedded structures from

incompatible types

15

Secu

re V

irtu

al A

rchit

ect

ure

Static Type Safety SPEC 2000

Secu

re V

irtu

al A

rchit

ect

ure

16

Static Type Safety SPEC 2006

Secu

re V

irtu

al A

rchit

ect

ure

17

Outline• Background• Current Work• Future Work

18

Secu

re V

irtu

al A

rchit

ect

ure

Dynamic Type Tracking in SVA• Track types stored to memory at run-time• Used for memory operations that cannot be proven safe

statically• Byte granularity tracking• Fine grained tracking of fields in structures

• Check type of data when loading from memory

19

Secu

re V

irtu

al A

rchit

ect

ure

Conclusions• SVA provides a secure foundation• We have:• Infrastructure for secure information flow• Improved type inference• Automated recovery from run-time safety violations

• In the pipeline:• Secure information flow to enforce safety sans OS support• Dynamic type tracking

20

Secu

re V

irtu

al A

rchit

ect

ure