jakub szefer, eric keller, ruby b. lee jennifer rexford princeton university ccs october, 2011...
Post on 27-Dec-2015
236 Views
Preview:
TRANSCRIPT
Eliminating the Hypervisor Attack Surface for a More Secure Cloud
Jakub Szefer, Eric Keller, Ruby B. Lee Jennifer Rexford Princeton UniversityCCS October, 2011
報告人:張逸文
2
Outline
Introduction Virtualization vulnerabilities Threat model NoHype system architecture Prototype design Security analysis Related work Conclusion
3
Introduction( 1/2) Web services & Cloud infrastructure
providers Multi-tenancy → SECURITY Virtualization software Previous approaches NoHype system
eliminating the hypervisor attack surface altogether
4
Introduction( 2/2) NoHyper
Retain the ability to run and manage VMs in the same way
Achieve with today’s commodity hardwarePrevent attacks
ContributionsEliminating the hypervisor attack surfaceRealizing on today’s commodity hardwareA prototype implementation and system evaluation
5
Virtualization vulnerabilities( 1/2)
HypervisorA program allows multiple OSs to share a single
hardware host Roles of virtualization software Roles of hypervisor
Processor coresMemoryI / O devicesInterrupts and Timers
6
Virtualization vulnerabilities( 2/2)
Attack SurfaceInteraction between guest VM & hypervisorVM 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
7
Threat model
NoHypeAvoiding attacks from malicious guest VMs
when VM exit happensEliminating the need for interactionAssumptions○ Guest OS’s security○ Cloud management software
8
NoHype system architecture( 1/3)
Pre-allocating memory and coresHypervisor dynamically manages the memory
and processor cores’ resourcesDedicating number of cores to the specific VMGuest VM can use the local APIC directlyPre-allocating memoryHardware paging mechanisms
9
NoHype system architecture( 2/3)
Using only virtualized I/O devicesDedicating I/O devices to the guest VMVirtualized NIC, storage, graphics card
Short-circuiting the system discoveryAllowing the guest OS boot normallyModifying guest OS to cache system configuration dataTemporary hypervisorNo customer code executes while any underlying
virtualization software is present
10
NoHype system architecture( 3/3)
Avoiding indirectionHypervisor performs indirections that map the
virtual view to real hardwareGuest VM directly accesses the processor ID
11
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
12
Prototype design( 2/5) Guest VM bootup
Xen’s inclusion of bootloader, hvmloderDescoverying devices○ Temporary hypervisor○ Modified QEMU to return “no device” for all but a
network card○ Interrupt:Modified Xen & Linux choose the
same configurable vector
13
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 disengagementGuest OS kernel moduleHypercall with an unused hypercall number○ Hypervisor disengagement○ Sending an IPI to other cores of the VM
14
Prototype design( 4/5)① Remove the VM from several lists
② Guest’s full control of the individual core
③ Initialize the local APIC registersExecution control is transferred to the user’s
code Guest execution and shutdown
Modify the guest Linux kernelShutdown by itself or by VMCS
15
Prototype design( 5/5) Raw performance evaluation
1% performance improvement
16
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
17
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
18
Related work
Minimizing the hypervisorTrustVisor:
Efficient TCB reduction and attestation New processor architectures
Introduction to the new mainframe:z/VM basics
Hardening the hypervisorHyperSafe:A lightweight approach to provide
lifetime hypervisor control-flow integrity Direct access to hardware
19
Conclusion
Design, implementation and evaluation of a working NoHype system on today’s commodity hardware
Removing the attack surface 1% faster run time
top related