Isolating commodity hosted hypervisors with HyperLock

Abstract

Hosted hypervisors (e.g., KVM) are being widely deployed. One key reason is that they can effectively take advantage of the mature features and broad user bases of commodity operating systems. However, they are not immune to exploitable software bugs. Particularly, due to the close integration with the host and the unique presence underneath guest virtual machines, a hosted hypervisor -if compromised -can also jeopardize the host system and completely take over all guests in the same physical machine.In this paper, we present HyperLock, a systematic approach to strictly isolate privileged, but potentially vulnerable, hosted hypervisors from compromising the host OSs. Specifically, we provide a secure hypervisor isolation runtime with its own separated address space and a restricted instruction set for safe execution. In addition, we propose another technique, i.e., hypervisor shadowing, to efficiently create a separate shadow hypervisor and pair it with each guest so that a compromised hypervisor can affect only the paired guest, not others. We have built a proof-ofconcept HyperLock prototype to confine the popular KVM hypervisor on Linux. Our results show that HyperLock has a much smaller (12%) trusted computing base (TCB) than the original KVM. Moreover, our system completely removes QEMU, the companion user program of KVM (with > 531K SLOC), from the TCB. The security experiments and performance measurements also demonstrated the practicality and effectiveness of our approach.

Cyber-Storms Come from Clouds: Security of Cloud Computing in the IoT Era

“…However, due to several reasons (e.g. misconfiguration, design and implementation bugs) an attacker can compromise the hypervisor, evade from isolation and potentially take over all the other guests [139]. We refer to such situation as virtual machine escape [102].…”

“…Indeed, a compromised VMM can threaten integrity of data [109]. More specifically, if a virtual machine is able to escape from isolation and compromise the VMM, it can access memory locations belonging to other users while having the required privileges to write or delete their content [126] [139], in such a way to perform a VM hopping attack [57,132]. The VMM can possibly be attacked through several attack vector: device drivers, VM exit events or hypercalls [84]; a throughout list of vulnerabilities typical of common VMMs used to deploy Cloud systems, can be found in [96].…”

HyperCheck: A Hardware-AssistedIntegrity Monitor

“…Another branch of research focuses on improving the security of the hypervisor by adding hooks [13], [56], [57] and enforcing security policies in virtual machines [54], [58]. These methods are hypervisor-specific and run at the same level as the hypervisor.…”

“…Moreover, a number of virtual machine escape attacks [9], [10], [11] and hypervisor rootkits [12] are widely deployed. Security researchers have noticed this problem and have begun to improve hypervisor security [13], [14], [15].…”

Design, Implementation and Verification of an eXtensible and Modular Hypervisor Framework

“…These systems are designed to provide interesting security and functional properties including secrecy of security sensitive application code and data [7], trusted user and application interfaces [2], [4], [13], application integrity and privacy [3], [5], [10], [11], [17], debugging support [8], malware analysis, detection and runtime monitoring [6], [9], [14]- [16] and trustworthy resource accounting [1]. A majority of these hypervisor-based solutions are designed and written from scratch with the primary goal of achieving a low Trusted Computing Base (TCB) while providing a specific security property and functionality in the context of an operating system or another (more traditional) hypervisor [2]- [10].…”