Published on

This talk with discuss the design and implementation of a new type of hypervisor derived from the Xen code base. µ-Xen has been built and optimized for modern CPUs and chipsets, and thus assumes the presence of CPU and IO MMUs that are virtualization capable. µ-Xen borrows extensively from the production-proven and tuned Xen code base, but removal of support for older hardware and PV-MMU guests has enabled significant simplification of the code. µ-Xen supports optimizations in support of running large numbers of very similar virtual machines, through the support of a native 'vmfork' optimization and efficient re-merging of shareable pages.

The primary goal of µ-Xen has been to run as a late-load hypervisor on an existing OS. It has a narrow and well-defined interface to the services it expects from the underlying OS, which makes it easy to port to other OSes, or to enable it to run on bare metal. During initialisation, µ-Xen can de-privilege the running host OS into a VM container, enabling it to establish itself as the most privileged software component in the system. Thus, µ-Xen enforces the privacy and integrity of itself and VMs that it is running, against a faulty or malicious host OS, while co-operating with the host OS on the actual allocation of physical resources.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • dynamic content cannot be blacklistedmalicious content can compromise whitelisted apps
  • µ-Xen

    1. 1. ®µ-XenIan PrattSVP, ProductsBromium Inc. 1
    2. 2. Outline ®• µ-Xen Goals• Architecture and implementation• Evolutionary path• Use case: Bromium end-point security 2
    3. 3. The µ-Xen Client Hypervisor ®• Derived from the Xen code base• Designed to address client hypervisor deployment challenges• Designed to achieve a high-degree of security assurance• No requirement to support legacy s/w or h/w• Optimized to support micro-virtualization• Evolution to a new class of hypervisor 3
    4. 4. Evolution to a new class of hypervisor ®• Start with a self-contained type-2 – Host kernel module containing µ-Xen blob – Well-defined interface to/from the host • Memory allocation, Schedule VCPUs, Timers, Events• Similar to hXen project – Windows, OS X; easily portable – µ-Xen drives VT hardware, leaves IO and other hardware to host OS 4
    5. 5. µ-Xen streamlines Xen code base ®• x64 only• No support for systems that are not VTx/EPT or AMDV/NPT capable• No support for PV MMU guests• Significant code size reductions• No compat code• Separate build target• Future: slim down instruction emulator 5
    6. 6. µ-Xen virtual IO ®• µ-Xen demultiplexes IORecs and events to multiple host processes per VM – Able to have separate video, audio, disk, net etc processes – Helps scheduling latency, enables better exploitation mitigation lock-down• Use just the relevant parts of QEMU• User-space PV backend drivers• Post-boot virtual IO device revocation 6
    7. 7. Support for large numbers of similar VMs ®• Support for VM fork – Simple extension of Populate on Demand code• Tree of templates/VMs supported• PV driver support for re-sharing free pages• IO tracking to re-share swapped and re-read pages 7
    8. 8. Evolution to a new class of hypervisor ®• Goal: host is responsible for resource allocation, but can not interfere with the privacy or integrity of the hypervisor or other guests, e.g.: – Hypervisor asks host for memory, receives it, then removes host access to it – Host may perform IO on behalf of hypervisor and guests, but must be privacy and integrity protected – Host may deny service, crash; IO tamper detectable 8
    9. 9. De-privilege host into a VT container ®• Remove host access to hypervisor and guest memory in EPT tables – h/w devices passed through to host, VTd protected• Device models can only access Granted memory – Require PV network and disk as no virtual DMA – Guest IO buffers encrypted/authenticated before grant copy/map• Save/restore, dom builder must first have guest memory encrypted/authenticated by hypervisor – Hypervisor paging requires similar treatment 9
    10. 10. Further Enhanced Security ®• Migrate certain host h/w devices to ownership by hypervisor or privileged guest(s), replace with virtual device – E.g. Keyboard controller to avoid key logging – Possibly WiFi/NIC too• Measured launch of hypervisor – TXT/TPM to establish DRoT – Remote attestation of hypervisor configuration 10
    11. 11. Task-based Micro-virtualization
    12. 12. The Challenge
    13. 13. What Went Wrong? Poor Isolation leads to Vulnerability  Multi-tenancy of code (& data) from a huge set of trust sources  Code & Data are executed in the context of a few, weakly organized and poorly isolated “bins” representing levels of trust - e.g. UID, GID, PID  Overloaded, complex specs & buggy implementations of porous interfaces Thus malware can:  Access data and documents in the same “bin”  Subvert other good code that is placed into the same “bin”  Use another bug in an App or OS to elevate its privilege
    14. 14. Why Legacy Security Solutions FailBlack-listing: Detection is not protection Doesn’t protect users from zero day attacks Unable to detect targeted & advanced malwareWhite-listing: Restriction is not protection Users want to be productive Attackers can compromise trusted applications and web sites
    15. 15. The ChallengeBromium Confidential 15Bromium Confidential
    16. 16. The Micro-Virtualization ApproachNext generation endpoint securityA pragmatic approach to trusted computingBased on hardware based isolation and not detection Contain risky activity from corporate data and network Block zero day and polymorphic threatsProvides isolation & trust through hardware virtualization
    17. 17. Lightweight, fast, Virtualizes vulnerable hidden, with an tasks within a single unchanged native UX Windows desktop Small code base for Hypervisor I/O Virtualization (VT-d) maximum security TXT & TPM based hardware root ofHardware Virtualization trust (VT-x)
    18. 18. The Microvisor isolates vulnerable tasks from Windows, each other & key system resources Windows and IT Micro-VMs have provisioned apps “least privilege” are trusted access to files, Each vulnerable tasknetworks & devices, is instantly isolated and execute CoW in a micro-VM, invisible to the user
    19. 19. Key Threat Vectors Are IsolatedWeb Browsing E-mail AttachmentsExternal Documents USB files
    20. 20. Conclusions ®• µ-Xen is targeted at client systems• Combines ease of deployment with useful security properties• Enables task-based micro-virtualization, allowing mandatory access control to be retrofitted to commodity client OSes• We’re hiring! Please email ian@bromium.com 21