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

1

Secu

re V

irtu

al A

rchit

ect

ure

Outline• Background• Results to Date• Controlling the OS• Full System Recovery

• Ongoing Work• Secure Application Computation

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-BASEDARCHITECTURES

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

Applications Need a Hero• Enforce application-specific security policies• Confidentiality• Data-centric application/user policies

• But Malicious OS can examine/modify any data in memory• Need an agent to control a potentially malicious OS• Need something below the OS!

4

Secu

re V

irtu

al A

rchit

ect

ure

Operating SystemOperating System

HardwareHardware

ApplicationApplication

Hardware! Protect me from this malicious OS!

Hardware! Protect me from this malicious OS!

Sorry, application.

You’re on your own

Sorry, application.

You’re on your own

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 and Transformations• Type Inference• Points-to Analysis• Automatic Pool Allocation

7

Secu

re V

irtu

al A

rchit

ect

ure

Outline• Background• Results to Date• Controlling the OS• Full System Recovery

• Ongoing Work• Secure Application Computation

8

Secu

re V

irtu

al A

rchit

ect

ure

SVA-OS• API implemented as a run-time library linked into the kernel• Implements interface between system code and hardware• Provides key software/hardware functionality• Like a ukernel, only better

• Sufficiently low-level to support multiple operating systems• Sufficiently high-level to enable strong analysis

9

Secu

re V

irtu

al A

rchit

ect

ure

SVA can control the OS!

Linux + SVA-OS

SVMVirtual ISANative ISA

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

Signal Handler Dispatch

Kernel must modify application stack for signal handler invocation

Provide higher-level instructions for pushing/popping function call frames on applications stack

MMU Configuration

Static analysis assumes virtual address space is immutable

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

10

Secu

re V

irtu

al A

rchit

ect

ure

Summary: A Secure Foundation• Strong memory safety enforcement == full SVA guarantees • 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

11

Secu

re V

irtu

al A

rchit

ect

ure

Safety enforced despite hostile OS Code!

Operating System Recovery• Recovery Domains: An Organizing Principle for Recoverable

Operating Systems• ASPLOS ‘09: Andrew Lenharth, Vikram Adve, and Samuel T. King

• Basic Idea: treat OS system calls as transactions• When an error is detected roll back state and re-exec syscall

12

Secu

re V

irtu

al A

rchit

ect

ure

Outline• Background• Results to Date• Controlling the OS• Full System Recovery

• Ongoing Work• Secure Application Computation

13

Secu

re V

irtu

al A

rchit

ect

ure

Secure Memory• Only an application can access its secure memory• SVA prevents the OS from accessing the secure memory• Disallow OS from mapping the secure memory

14

Secu

re V

irtu

al A

rchit

ect

ure

PhysicalPage Frames

ApplicationVirtual Pages

OSVirtual Pages

ApplicationRegular Memory

ApplicationSecure Memory

OSKernel Memory

Secure Memory is Great, But…• Unfettered OS can indirectly access secure memory• E.g., Signal handler dispatch and context switching

• Secure Memory is difficult to use• Pointers to secure memory must also be in secure memory.• Program itself can leak data unintentionally

15

Secu

re V

irtu

al A

rchit

ect

ure

Secure Memory Outline• What we’re working on now: basic secure memory• Key: maintain CFI for application, protect data

• What we’ll be working on soon: usable secure memory• Use compiler to help with difficult to reason about properties

16

Secu

re V

irtu

al A

rchit

ect

ure

Preventing Access to Program Code and Stacks• OS cannot modify or remap:• Application Stack• Application Code

• Works because SVA controls:• Loads/stores• MMU configuration

• Protects application CFI• OS cannot get application to

bypass run-time checks inserted by SVA

• OS cannot cause application to execute arbitrary code 17

Secu

re V

irtu

al A

rchit

ect

ure

Code:

Stack:

Application Kernel

Interacting with the OS• Prevent OS could from modifying saved program state• CPU state saved on syscall or interrupt• CPU state saved on context switch

• Ensure that OS restores correct state• Context Switch

• Memory access still an open challenge• Simple solution: allow heap access, promote stack buffers to heap• More complex: analyze application and OS together

18

Secu

re V

irtu

al A

rchit

ect

ure

Operating SystemOperating System

ApplicationApplication Operating SystemOperating SystemApplicationApplication

OS is Master OS is Untrusted Partner

Asynchronous Program Invocation and Signal Handling• SVA-OS has instruction for modifying application stack

• Add checks to it to ensure function is a signal handler• SVA can determine which functions are arguments to syscalls

• Ensure OS restores correct application state on sigreturn()

19

Secu

re V

irtu

al A

rchit

ect

ure

sva_push_func sva_load_icontext

ApplicationStack

ApplicationStack

ApplicationStack

Original Application Registers

Application Registers After Signal Handler Dispatch

Basic Usable Secure Memory• Pointers to secure

memory objects must be in secure memory• Points-to graph can

find such pointers• Move them to secure

memory

20

Secu

re V

irtu

al A

rchit

ect

ure

PointerPointer

Secure Memory Object

Secure Memory Object

Insecure Memory Object

Insecure Memory Object

Secure Memory and Non-interference• Computations using secure memory do not use insecure

memory• Computations using insecure memory do not use secure

memory• Import/export instructions moving data to/from secure

memory• Allows intentional breaking of non-interference

• Ensures OS does not affect computations

21

Secu

re V

irtu

al A

rchit

ect

ure

Conclusions• SVA provides a secure foundation• Control over the OS• Recovery from detected safety violations

• We have:• Automated recovery from run-time safety violations• Initial design of secure memory

• Ongoing work:• Implementation of secure memory• Design of secure memory usability enhancements if time permits

22

Secu

re V

irtu

al A

rchit

ect

ure