Some papers about Virtualized Security.

1. Pre-knowledge

1.1. Hypervisor

A hypervisor (or virtual machine monitor, VMM, virtualizer) is computer software, firmware or hardware that creates and runs virtual machines. A computer on which a hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources: for example, Linux, Windows, and macOS instances can all run on a single physical x86 machine. This contrasts with operating-system-level virtualization, where all instances (usually called containers) must share a single kernel, though the guest operating systems can differ in user space, such as different Linux distributions with the same kernel.

1.1.1. Classificaton

In their 1974 article, Formal Requirements for Virtualizable Third Generation Architectures, Gerald J. Popek and Robert P. Goldberg classified two types of hypervisor.

1.1.1.1. Type-1, native or bare-metal hypervisors

These hypervisors run directly on the host’s hardware to control the hardware and to manage guest operating systems. For this reason, they are sometimes called bare metal hypervisors.

  • Features
    • Need hardware support
    • Treat hypervisor as the main OS
    • High operating efficiency
  • Examples
    • AntsleOS
    • Microsoft Hyper-V
    • Oracle VM Server for SPARC
    • Oracle VM Server for x86
    • VMware ESXi (formerly ESX)
    • Xen
    • KVM

1.1.1.2. Type-2 or hosted hypervisors

These hypervisors run on a conventional operating system (OS) just as other computer programs do.

  • Features
    • A guest operating system runs as a process on the host
    • Type-2 hypervisors abstract guest operating systems from the host operating system. Thus it has lower operating efficiency than type-1.
  • Examples
    • Parallels Desktop for Mac
    • QEMU
    • VirtualBox
    • VMware Player
    • VMware Workstation

2. Papers

2.1. Taming Hosted Hypervisors with (Mostly) Deprivileged Execution

Keywords: KVM, Depriviledged, Least Priviledge Principle.

  • Existing hosted hypervisors typically have a large code base, which inevitably introduces exploitable software bugs;
  • Designed a new system named DeHype which deprivileging the system’s execution into user mode (applies the least priviledge principle to hosted hypervisors);
    • reduce the attack surface (with a much smaller TCB) and bring additional benefits in allowing for better development and debugging;
    • define a minimal subset of priviledged hypervisor code into an OS extension (HypeLet) (which can execute a priviledged instruction in priviledged mode).
  • Limitations.
    • aiming at removing KVM out of the globally shared trusted computing base (TCB), the hosted hypervisor, which includes a complete Linux, remains in each VMs TCB while being large and vulnerable (including all Linux vulnerabilities).

  • Decompose the KVM into two parts.
    • the deprivileged KVM hypervisor running in user mode;
    • a minimal loadable kernel module called HypeLet running in kernel mode.

2.2. Deconstructing Xen

Keywords: XEN, Deconstructure, Samepriviledge Memory Isolation.

  • Analyze the 191 Xen hypervisor vulnerabilities from Xen Security Advisories;
    • reveal that the majority (144) are in the core hypervisor not Dom0.
  • Present Nexen, a novel deconstruction and reorganization of Xen (provide a fundamental need for hypervisor hardening at minimal performance and implementation costs) (principle of least priviledge);
    • use sameprivilege memory isolation to enforce cross-VM data and control-flow integrity (to operate at the highest hardware priviledge level);
    • extends the privileged security monitor from the Nested Kernel architecture, to isolate and control the memory management unit (MMU) (each slice is analogous to a lightweight process).
  • Limitations.
    • cannot handle vulnerabilities in the shared service;
    • does not prevent abuse of I/O devices well;
    • a Xen slice compromised by other VMs can bypass the sanity check and arbitrarily modify the guest’s running state from a malicious administrator.

  • Decompose Xen into three parts (multiple internal domains (iDoms)) (each iDoms cannot directly access data within each others’ address spaces).
    • a privileged security monitor;
    • one shared service domain;
    • multiple per-VM Xen slices (isolated by a least-priviledged sandboxing framework);

2.3. Comprehensive VM Protection against Untrusted Hypervisor through Retrofitted AMD Memory Encryption

Keywords: Hardware-based Memory Encryption, Secure Encrypted Virtualization (SEV).

  • Provide a security analysis on the security of SEV;
    • the hypervisor is still in the position of managing the guest memory mapping and key sharing mechanisms, where replay attacks can be conducted to infer VM’s encrypted memory;
    • miss some functionalities to provide the full VM protection.
  • Propose a software-based extension to the SEV feature, namely Fidelius;
    • separate the management of critical resources from service provisioning;
    • adopt a sibling protection with non-bypassable memory isolation;
    • reuses the SEV API to provide a full VM life-circle protection, including two sets of para-virtualized I/O interfaces to encode the I/O data.
  • Limitations.
    • guest VMs may be compromised through the security flaws inside them;
    • DoS attack and availability guarantee of the guest VM is not under consideration;
    • does not prevent against side-channel attacks.

  • Its trust computing base includes the AMD memory encryption engines and the Fidelius context lying in parallel with the hypervisor (they are isolated from each other through non-bypassable memory isolation mechanism).

2.4. EnclavePDP: A General Framework to Verify Data Integrity in Cloud Using Intel SGX

Keywords: Cloud Storage Service, Software Guard Extensions (SGX), Third Party Auditor (TPA).

  • Existing Provable Data Possession (PDP) schemes mostly resort to a Third Party Auditor (TPA) to verify the integrity on behalf of users, but placing TPA in the Trusted Computing Base (TCB) is not always a reasonable assumption;
  • Proposed and implemented EnclavePDP, a novel and generic framework that can securely verify the integrity of the outsourced data relying on Intel SGX.
    • eliminate the TPA from the TCB;
    • utilize Intel SGX to perform data integrity verification;
    • tailor Intel SGX SSL library and ported PBC libraries into Intel SGX.

  • There are five major functionalities that should be fulfilled by PDP schemes.
    • KeyGen: During the initialization phase, the client generates public and private keys for the other functionalities;
    • Tag: The file is divided intonblocks, and a tag is generated for each block using the private key;
    • Challenge: After choosing a random set of file blocks to audit, a challenge is generated using the private key;
    • Proof: When receiving a challenge, a proof of data possession is computed using the public key;
    • Verify: A received proof will be verified against the challenge using the private key or public key depending onthe specific PDP schemes.

3. Paper Structure

  1. Abstract;
  2. Introduction;
  3. Background;
  4. Overview;
  5. …;
  6. Related Works;
  7. Conclusion;
  8. References.

4. References

Hypervisor - Wikipedia
KVM 之 CPU 虚拟化