Multi-processor architectural support for protecting virtual machine privacy in untrusted cloud environment

Abstract

Virtualization is fundamental to cloud computing because it allows multiple operating systems to run simultaneously on a physical machine. However, it also brings a range of security/privacy problems. One particularly challenging and important problem is: how can we protect the Virtual Machines (VMs) from being attacked by Virtual Machine Monitors (VMMs) and/or by the cloud vendors when they are not trusted? In this paper, we propose an architectural solution to the above problem in multi-processor cloud environments. Our key idea is to exploit hardware mechanisms to enforce access control over the shared resources (e.g., memory spaces), while protecting VM memory integrity as well as inter-processor communications and data sharing. We evaluate the solution using full-system emulation and cycle-based architecture models. Experiments based on 20 benchmark applications show that the performance overhead is 1.5%-10% when access control is enforced, and 9%-19% when VM memory is encrypted.

SoK: Hardware-supported Trusted Execution Environments

“…Flicker [5] x86 DRTM SEA [6] x86 DRTM SICE [23] x86 SRTM PodArch [24] x86 SRTM HyperCoffer [25] x86 SRTM H-SVM [26], [27] x86 SRTM EqualVisor [18] x86 SRTM xu-cc15 [28] x86 SRTM wen-cf13 [29] x86 SRTM Komodo [30] ARM SRTM SANCTUARY [31] ARM SRTM TrustICE [32] ARM SRTM HA-VMSI [33] ARM SRTM Sanctum [4] RISC-V SRTM TIMBER-V [34] RISC-V SRTM Keystone [35] RISC-V SRTM Penglai [36] RISC-V SRTM CURE [37] RISC-V SRTM Iso-X [38] OpenRISC SRTM HyperWall [39] SPARC SRTM Sancus [40], [41] MSP430 HW TrustLite [42] Custom SRTM TyTan [43] Custom SRTM XOM [44] Custom SRTM AEGIS [45] Custom SRTM TABLE I: The surveyed TEEs with their respective Root-of-Trust for Measurement (RTM) and their support for local and remote attestation. We use SRTM for static Root-of-Trust, DRTM for dynamic Root-of-Trust, and HW for hardware based systems that do not rely on SRTM or DRTM (c.f., Section IV-A).…”

“…Provisioning secrets into enclaves is often the last optional step during its launch. Some TEEs such as IBM PEF [22], AMD SEV-SNP [3], PodArch [24], and Wen-cf13 [29] allow enclaves to be provisioned with secret data prior to the attestation. In this case, the enclave's initial state will contain some secret values also reflected in the measurement.…”

Primitives towards verifiable computation: a survey

“…Moreover, the integrity and confidentiality of the physical memory space is also not assured by TPMs. Recently, Wen et al have proposed another architectural based security mechanism for untrusted cloud environment [42], which imposes an access control policy over the shared resources in order to protect the virtual machine's memory integrity. In addition, it provides security for data sharing and inter-processor communications.…”

“…Another series of solutions towards VC were put forward by the researchers during the session 1994-2009 based on assumptions such as; 1) the usage of trusted hardware (secure crypto-processors, trusted platform modules etc.) [41,42], 2) attestation [43,44], 3) replication [45,46] and 4) auditability [47,48]. These proposals are discussed in detail within Section 2.…”

Evolution of Attacks, Threat Models, and Solutions for Virtualized Systems

“…It does so by introducing paraverification, where an untrusted OS is required to verify its own behavior by communicating its intent to the hypervisor. [Wen et al 2013] propose a solution to protect VMs from VMMs in multi-processor Cloud environments by exploiting hardware mechanisms to enforce access control over the shared resources (e.g., memory spaces). STEALTHMEM [Kim et al 2012] is a system-level protection mechanism against cache-based side channel attacks in the Cloud.…”