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

20

21

22

23

24

25