- Conference and Journals
- Project Archive
We focus on designing secure cloud architectures to provide various protections for Virtual Machines in Infrastructure as a Service (IaaS) systems. These projects include:
Cloud customers need guarantees regarding the security of their virtual machines (VMs), operating within an Infrastructure as a Service (IaaS) cloud system. This is complicated by the customer not knowing where his VM is executing, and on the semantic gap between what the customer wants to know versus what can be measured in the cloud. We present an architecture for monitoring a VM’s security health, with the ability to attest this to the customer in an unforgeable manner
Cloud computing is a disruptive trend that is changing the way we use computers and virtualization is the key underlying technology in cloud infrastructures. Unfortunately, the use of virtualization is the source of a significant security concern: multiple virtual machines (VMs) run on the same server and since the virtualization layer plays a considerable role in the operation of a virtual machine, a malicious VM has the opportunity to attack the virtualization layer. A successful attack would give the malicious VM control over the all-powerful virtualization layer and potentially compromise the confidentiality and integrity of the virtualization layer and the other VMs. The NoHype system architecture proposes removing the virtualization layer while retaining the key features needed to be able to provide for multi tenancy of VMs. The NoHype architecture is named to indicate the removal of the hypervisor (no hypervisor) but we also try to show that the NoHype architecture may indeed be implementable on today's commodity hardware (not a hype). By removing bulky virtualization layer we propose that the architecture improves security while retaining key functionality to be able to host multiple VMs on same physical hardware.
This is a joint work between Prof. Lee's group and Prof. Rexford's group (CS department).
Virtualization has become a standard part of many computer systems. A key part of virtualization is the all-powerful hypervisor which manages the physical platform and can access all of its resources, including memory assigned to the guest virtual machines (VMs). Continuing releases of bug reports and exploits in the virtualization software show that defending the hypervisor against attacks is very difficult. In this work, we present hypervisor-secure virtualization – a new research direction with the goal of protecting the guest VMs from an untrusted hypervisor. We also present the Hy- perWall architecture which achieves hypervisor-secure virtualization, using hardware to provide the protections. HyperWall allows a hypervisor to freely manage the memory, processor cores and other resources of a platform. Yet once VMs are created, our new Confidentiality and Integrity Protection (CIP) tables protect the memory of the guest VMs from accesses by the hypervisor or by DMA, depending on the customer’s specification. If a hypervisor does become compromised, e.g. by an attack from a malicious VM, it cannot be used in turn to attack other VMs. The protections are enabled through minimal modifications to the micropro- cessor and memory management units. Whereas much of the previous work concentrates on protecting the hypervisor from attacks by guest VMs, we tackle the problem of protecting the guest VMs from the hypervisor.
Other related papers
The rise of the Cloud Computing paradigm has led to security concerns, taking into account that resources are shared and mediated by a Hypervisor which may be targeted by rogue guest VMs and remote attackers. In order to better define the threats to which a cloud server’s Hypervisor is exposed, we conducted a thorough analysis of the codebase of two popular open-source Hypervisors, Xen and KVM, followed by an extensive study of the vulnerability reports associated with them. Based on our findings, we propose a characterization of Hypervisor Vulnerabilities comprised of three dimensions: the trigger source (i.e. where the attacker is located), the attack vector (i.e. the Hypervisor functionality that enables the security breach), and the attack target (i.e. the runtime domain that is compromised). This can be used to understand potential paths different attacks can take, and which vulnerabilities enable them. Moreover, most common paths can be discovered to learn where the defenses should be focused, or conversely, least common paths can be used to find yet-unexplored ways attackers may use to get into the system