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