Eliminating the Hypervisor Attack Surface for a More Secure Cloud
Download
Report
Transcript Eliminating the Hypervisor Attack Surface for a More Secure Cloud
Jakub Szefer, Eric Keller, Ruby B. Lee
Jennifer Rexford
Princeton University
CCS October, 2011
報告人:張逸文
Outline
Introduction
Virtualization vulnerabilities
Threat model
NoHype system architecture
Prototype design
Security analysis
Related work
Conclusion
2
Introduction(1/2)
Web services & Cloud infrastructure
providers
Multi-tenancy → SECURITY
Virtualization software
Previous approaches
NoHype system
eliminating the hypervisor attack surface
altogether
3
Introduction(2/2)
NoHyper
Retain the ability to run and manage VMs in the same
way
Achieve with today’s commodity hardware
Prevent attacks
Contributions
Eliminating the hypervisor attack surface
Realizing on today’s commodity hardware
A prototype implementation and system evaluation
4
Virtualization vulnerabilities(1/2)
Hypervisor
A program allows multiple OSs to share a single
hardware host
Roles of virtualization software
Roles of hypervisor
Processor cores
Memory
I / O devices
Interrupts and Timers
5
Virtualization vulnerabilities(2/2)
Attack Surface
Interaction between guest VM & hypervisor
VM exit
○ the VM’s code is interrupted and the hypervisor’s
code begins to execute to handle some event
○ How often this happens?
VM sends info. to hypervisor so the hypervisor
can handle the event
6
Threat model
NoHype
Avoiding attacks from malicious guest VMs
when VM exit happens
Eliminating the need for interaction
Assumptions
○ Guest OS’s security
○ Cloud management software
7
NoHype system architecture(1/3)
Pre-allocating memory and cores
Hypervisor dynamically manages the memory
and processor cores’ resources
Dedicating number of cores to the specific VM
Guest VM can use the local APIC directly
Pre-allocating memory
Hardware paging mechanisms
8
NoHype system architecture(2/3)
Using only virtualized I/O devices
Dedicating I/O devices to the guest VM
Virtualized NIC, storage, graphics card
Short-circuiting the system discovery
Allowing the guest OS boot normally
Modifying guest OS to cache system configuration data
Temporary hypervisor
No customer code executes while any underlying
virtualization software is present
9
NoHype system architecture(3/3)
Avoiding indirection
Hypervisor performs indirections that map the
virtual view to real hardware
Guest VM directly accesses the processor ID
10
Prototype design(1/5)
VM creation
customer’s request → cloud management
software → system software → create VM
Xen
○ Pre-setting EPT(Extended Page Tables)
○ Physical function driver for NIC
○ pinning a VM to a set of cores
○ allocating the virtualized NIC
11
Prototype design(2/5)
Guest VM bootup
Xen’s inclusion of bootloader, hvmloder
Descoverying devices
○ Temporary hypervisor
○ Modified QEMU to return “no device” for all but a
network card
○ Interrupt:Modified Xen & Linux choose the same
configurable vector
12
Prototype design(3/5)
Discovering processor capabilities
○ The clock frequency --- software virtualized HPET
○ The core identifier --- pass the actual identifier
○ Processor’s features --- implementation CPUID
Hypervisor disengagement
Guest OS kernel module
Hypercall with an unused hypercall number
○ Hypervisor disengagement
○ Sending an IPI to other cores of the VM
13
Prototype design(4/5)
Remove the VM from several lists
Guest’s full control of the individual core
Initialize the local APIC registers
Execution control is transferred to the user’s
code
Guest execution and shutdown
Modify the guest Linux kernel
Shutdown by itself or by VMCS
14
Prototype design(5/5)
Raw performance evaluation
1% performance improvement
15
Security analysis(1/2)
Remaining hypervisor attack surface
Interaction between the cloud manager and the
system manager future work
Temporary hypervisor & modified guest OS
kernel
Trusted Computing Base
VM to VM attack surface
Sending IPIs to other guest VMs
16
Security analysis(2/2)
Isolation between VMs
Pre-setting EPT to assign physical pages to a VM
performance
VMs mapping physical infrastructures
Infrastructure mapping attacks
17
Related work
Minimizing the hypervisor
TrustVisor:Efficient TCB reduction and
attestation
New processor architectures
Introduction to the new mainframe:z/VM
basics
Hardening the hypervisor
HyperSafe:A lightweight approach to provide
lifetime hypervisor control-flow integrity
Direct access to hardware
18
Conclusion
Design, implementation and evaluation of a
working NoHype system on today’s
commodity hardware
Removing the attack surface
1% faster run time
19
20
21
22
23
24
25