1. Jakub Szefer, Eric Keller, Ruby B. Lee Jennifer Rexford Princeton University CCS October, 2011 報告人：張逸文

2. Outline  Introduction  Virtualization vulnerabilities  Threat model  NoHype system architecture  Prototype design  Security analysis  Related work  Conclusion 2

3. Introduction （ 1/2 ）  Web services & Cloud infrastructure providers  Multi-tenancy → SECURITY  Virtualization software Virtualization software  Previous approaches  NoHype system eliminating the hypervisor attack surface altogether 3

4. 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

5. Virtualization vulnerabilities （ 1/2 ）  Hypervisor Hypervisor A program allows multiple OSs to share a single hardware host  Roles of virtualization software Roles of virtualization software  Roles of hypervisor Processor cores Memory I / O devices Interrupts and Timers 5

6. 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? How often this happens? VM sends info. to hypervisor so the hypervisor can handle the event 6

7. 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

8. 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

9. 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

10. 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

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 11

12. Prototype design （ 2/5 ）  Guest VM bootup 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

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 disengagement Guest OS kernel module Hypercall with an unused hypercall number ○ Hypervisor disengagement ○ Sending an IPI to other cores of the VM 13

14. 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 Guest execution and shutdown Modify the guest Linux kernel Shutdown by itself or by VMCSVMCS 14

15. Prototype design （ 5/5 ）  Raw performance evaluation 1% performance improvement 15

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 16

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 17

18. Related work  Minimizing the hypervisor TrustVisor ： Efficient TCB reduction and attestation TrustVisor ： Efficient TCB reduction and attestation  New processor architectures Introduction to the new mainframe ： z/VM basics Introduction to the new mainframe ： z/VM basics  Hardening the hypervisor HyperSafe ： A lightweight approach to provide lifetime hypervisor control-flow integrity HyperSafe ： A lightweight approach to provide lifetime hypervisor control-flow integrity  Direct access to hardware 18

19. 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. 20

21. 21

22. 22

23. 23

24. 24

25. 25