1 / 25

Eliminating the Hypervisor Attack Surface for a More Secure Cloud

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

carlow
Download Presentation

Eliminating the Hypervisor Attack Surface for a More Secure Cloud

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Eliminating the Hypervisor Attack Surface for a More Secure Cloud JakubSzefer, 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

  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 hardware • Prevent attacks • Contributions • Eliminating the hypervisor attack surface • Realizing on today’s commodity hardware • A prototype implementation and system evaluation

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

  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? • VM sends info. to hypervisor so the hypervisor can handle the event

  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

  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

  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

  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

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

  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

  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 • Modify the guest Linux kernel • Shutdown 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 hypervisor • TrustVisor：Efficient TCB reduction and attestation • New processor architectures • Introduction to the new mainframe：z/VM basics • Hardening the hypervisor • HyperSafe：Alightweightapproachtoprovidelifetimehypervisorcontrol-flowintegrity • Direct access to hardware

  19. Conclusion • Design,implementationandevaluationofaworkingNoHypesystemontoday’scommodity hardware • Removing the attack surface • 1% faster run time

More Related