Virtual Machines Xen and Terra

1. Virtual Machines Xen and Terra Rajan Palanivel

2. Xen and Terra : Papers • Xen and the art of virtualization. -Univ. of Cambridge • Terra: A VM based platform for trusted computing. - Stanford Univ.

3. Virtual Machine and Advantages • Multiplexing the real machine in to multiple “virtual” machines. • General architecture consist of a software layer (Monitor) that exposes VMs and various “guest” OSs run on these VMs. • Some Advantages: • Concurrent execution of different OS on the same hardware and hence different applications. • Resource Isolation. • Upgrade OS software to a different version without losing the ability to run older legacy OS and it’s applications.

4. Types of Monitor. • Monitor runs on a higher privilege level than the guest OS. • Sensitive/Privileged instructions. (Ex: MOV) • Classified by the amount of guest OS instructions that are executed by monitor or by the real hardware. • CSIM (Complete software Interpreter machine), Hybrid VM (HVM) and VMM. • VMM : Requires that “Statistically dominant subset of the virtual processor instructions be executed on the real processor” . (Type 1 and Type 2) • Xen –Type 1 VMM.

5. Guest Process Guest Process Guest Operating System Virtual Machine Monitor Hardware Type I VMM Type 1 and Type 2 VMMs Guest Process Guest Process Guest Operating System Virtual Machine Monitor Host Operating System Hardware Type II VMM • Uses existing host OS abstractions to implement services • Poor performance • Runs directly on hardware • Good performance

6. Full Virtualization • Full Virtualization: No modification required for the guest OS (VMWare’s ESXServer). • Drawbacks : (esp. on x86) • Sensitive Instructions fail without traps. • Need dynamic rewrite of OS kernel. • Shadow system structures (performance issue to sync virtual and shadow structures). • Guest OS may need both virtual and real resources. (Time: TCP timeouts and RTT, Machine address for super pages etc).

7. Xen: Para Virtualization • Para Virtualization: Exposed hardware is similar but not identical to the real machine. • OS modifications required. • ABI not changed. (Guest apps run without changes). • High performance. • Xen Hypervisor.

8. Xen

9. Xen – CPU • Xen Hypervisor runs in ring 0. • Guest OS runs in a lower privilege level (ring 1). Privileged and sensitive instructions are paravirtualized by requiring them to be validated and executed by hypervisor. • Guest OS protects itself from it’s other processes by running in a separate address space (and separate privilege level). • Trap/Exception handlers are registered with Xen for validation. (Xen checks that the code segment of the handlers will not run in ring 0). • Fast Exception handlers for system calls.

10. Xen – Memory Management • Initial Memory allocation: • Static Allocation for each domain. • Dynamic expansion/contraction possible. • Virtualizing memory is Complicated in x86: • x86-MMU handles TLB misses by searching through the page table in the hardware. (No Soft TLB support). • TLB flush on context switches. (No tagged TLB support).

11. Xen – Memory Management • Virtual address translation: • Page Tables: Allocated and managed by guest OSs but restricted to read only access. Updates validated and applied by Xen. (via hypercalls) • Xen: Associates a type and reference count with each machine page frame. (PD, PT, LDT, GDT, RW). • Xen exists in the 64 MB section on top of every address space (TLB flush prevented when entering/leaving Xen Hypervisor). • Page fault Handling: (CR2 register) : Pre determined location.

12. Control /Data / Timers • Hypercalls : synchronous calls from domain to Hypervisor. Domains do privileged operations via hypercalls. • Events: asynchronous notifications delivered via events from Xen to domains. (For delivering h/w interrupts). • Data transfer through Descriptor rings. (Producer – Consumer). • Time and Timers: Real, Virtual and wall-clock.

13. Xen - Network • Xen provides a Virtual Firewall-router (VFR). • Each domain has one or more VIFs (virtual Interfaces) attached logically to VFR. • VFR has rules of the form <pattern><action>. • Two I/O buffer descriptor rings. (Transmit and Receive). • Trans: Domain updates the transmit descriptor ring. Xen copies the descriptor and the packet header. Header is inspected by VFR. Payload is not copied (Scatter-gather). Pages are pinned till completion. • Recv: Xen multiplexes/firewalls using VFR and avoids copy by page flipping.

14. I/O Ring (Transmit or Receive)

15. Control and Management. • Management software runs on a special guest OS (domain 0). • List of parameters to manage include access control (for i/o devices), amount of physical memory per domain, VFR rules etc. • Mgmt software uses control interfaces provided by Xen.

16. Xen – Relative Performance

17. Xen – Network Performance

18. Xen - Performance Multiple Apache processes in Linux vs. One Apache process in each guest OS

19. Terra: Goals • Goal is to run applications with wide range of security requirements simultaneously. • Multiple Closed platforms on general purpose hardware. • Software stack is tailored from hardware interface up to meet the security requirements of it’s applications. • Isolation and authentication.

20. Terra - TVMM • Trusted VMM (TVMM). • Facilitates Open and Closed box VMs. • Open box VM runs regular commodity applications. • Closed box VMs provide hardware memory protection. (Isolation) • Cryptographic authentication (Attestation). TVMM acts as a trusted party to authenticate the software running in a VM to remote parties.

21. Terra – Architecture. • Two VM abstractions (Open and close). • Contents of closed box cannot be inspected or manipulated by the platform owner. • Provides Isolation, Extensibility, Efficiency, Compatibility and Security. • Extra features by Terra: Root Secure, Attestation and Trusted path.

22. Terra - Architecture

23. Terra – Attestation and VM Identity • Attestation: Application in a closed box VM authenticates itself to remote parties. • Authenticates who built the hardware and what layers of software are running on the machine. • Building a certificate chain (H/w -> BIOS -> boot loader -> TVMM -> VM -> Apps). • Terra uses a tamper resistant hardware (TPM). (Embedded private key)

24. Terra – Attestation VM TVMM SIGNED CERTIFICATE ENDORSE API CALL Boot Loader Firmware Hardware

25. Terra : Example Attestation • TLS/SSL Session between Quicken and Remote bank server. • Client sends the attestation certificate chain during TLS Handshake. • Lowest certificate (of h/w) in the chain is from a trusted authority. • All hashes in the chain are on the list of remote server’s list of authorized software. (trustable BIOS, boot loader, TVMM) • Topmost certificate (containing the hash of quicken) is on the list of authorized version. • If all the checks are valid, then TLS is completed and session key exchanged.

26. Privacy • Attestation process identifies the machine! (privacy concerns). • Privacy CA (PCA): User’s machine send an attested cert request to PCA and PCA issues an anonymized cert for attestation. • Other issues : DRM etc. – Media servers may release content only to platforms that would prevent copying, expire the media after certain time etc.

27. Terra – Device Driver Security. • Drivers have the most security holes.. • Hardware memory protection + chipset protection can prevent drivers from DMA ing to other address spaces. • NGSCB architecture: • Runs in a curtained memory protected from DMA attacks and from untrusted OS. • Leverages device drivers of the untrusted OS (running in an open box VM) via an explicit interface in the untrusted Os kernel.

28. Q & A. • QA