Secure Virtual Architecture
description
Transcript of Secure Virtual Architecture
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