virtualization software stack i s usual ly huge and most of them are
within the trusted computing base.
Figure 1 depicts the typical (hostless) architecture of virtualization
and the attack surface in a multi-tenant cloud. As tenant VMs are
usually managed by the management tools via over-powerful priv-
ileged in terfaces to the VMM, they could be arbitrarily inspected
and tampered with by not only the VMM but also the manage-
ment tools in the management VM. In principle, operators should
be granted with only the least privilege and will not be able to tam-
per with tenant VMs. In practice, however, operators are usually
granted with access rights more than they should have, as it is usu-
ally difficult to define the proper privilege precisely [35]. Conse-
quently, improperly granting access rights to users’ data could eas-
ily put users’ data under threat (i.e., attack surface 3). For example,
a cloud operator might leverage the internal maintenance interface
to du mp a VM’s memory image for offline analysis, stealthily mi-
grate/clone a VM to a shadow place for replayin g, or even copy
away all VM’s virtual disks.
Worse even, as more and more functional ities being integrated into
the vir tualization layer such as live migratio n, security monitoring
and snapshot, the TCB, which includes VMM, management VM
and management tools, is exploding in both size and complexity.
For example, the TCB size for Xen, i ncluding the VMM, manage-
ment VM and tools has been steadily increasing across each major
release, as shown in Table 1. An adversary could mount attacks to
the virtualization layer by exploiting th e inside security vulnerabili-
ties (attack surface 1 and 2). Here, we d el iberately separate internal
(surface 3) and external attacks (surface 1 and 2) as in typical data-
center there are usually physically separated network for internal
operators and for external accesses. Usuall y, internal attacks are
much more powerful and easy to mount if a cloud operator tends to
be malicious.
However, most previous efforts only aim at protecting against at-
tack surface 1 and 2 b y securing [60, 68] or removing [31] the vir-
tualization layer, without defending at tackers leveraging attack sur-
face 3. For example, they cannot defend against attacks leveraging
legal maintenance operations such as dump/clone/migrate a VM or
virtual disks. Further, they r equire a reconstruction of the cloud
software stack. To this end, it is critical to pr ovide multi-tenant
cloud with an approach that defending against attackers penetrated
through the three attack surfaces from tampering with tenant VMs,
yet with a small trusted computing base, which motivates the de-
sign and implementation of CloudVisor.
VMM Dom0 Kernel Tools TCB
Xen 2.0 45K 4,136K 26K 4,207K
Xen 3.0 121K 4,807K 143K 5,071K
Xen 4.0 270K 7,560K 647K 8,477K
Table 1: T CB of Xen virtualization layer ( by Lines of Code,
counted by sloccount).
2.2 Assumptions and Threat Models
Adversaries: Given that there are multiple attack surfaces in a
multi-tenant cloud, we consider both local adversaries and remote
adversaries and assume that they have full control over the VM
management stack including the commodity hypervisor, the man-
agement VM and too ls. An adversary may leverage the powerful
management interfaces to try to dump a tenant VM’s memory, steal
the VM’s virtual disks, or even inject code to the VM.
Assumptions: We assume the cloud provider itself does not in-
tend to be malicious or with the goal of tampering with or steal-
ing its tenant’s sensitive information. Instead, the threat may come
from the intentional or unintentio nal mis-operations from its oper-
ators [26, 63]. Hence, we assume there will be no internal physical
attacks such as placing probes into the buses and f reezing all main
memory and reading out the data. Actuall y, typical data-centers
usually have strict control of physical accesses as well as surveil-
lance cameras to monitor and log such accesses. However, as the
disk storage might be easily accessible by operators through the
VM management stack or even physical maintenance (such as disk
replacements), we assume that the external disk storage is not trust-
worthy.
Security Guarantees: The goal of CloudVisor is to prevent the
malicious VM management stack from inspecting or modifying a
tenant’s VM states, thus providing both secrecy and in tegrity to
a VM’s states, including CPU states, memory pages and disk I/O
data. CloudVisor gu arantees that all accesses not from a VM it-
self (e.g., the VMM, other VMs), such as DMA, memory dumping
and I/O data, can only see the encrypt ed version of that VM’s data.
Upon illegal tampering with a VM’s states, CloudVisor uses cryp-
tographic approaches to verify t he integrity, ordering and freshness
of a VM’s data and fail-stops a VM upon tampering.
A malicious VMM cannot issue arbitrary control transfers from the
VMM to a tenant’ VM. Instead, all control transfers between the
VMM and a VM can onl y be done through a well-defined entry
and exit points, which will b e mediated by CloudVisor. The VMM
cannot fake an execution context to let a VM run upon. Actually,
a VM’s execution context is securely saved and restored by Cloud-
Visor during a control transfer.
With platfo r m measurement techniques such as Intel Trusted eX-
ecution Technology and TPM, CloudVisor allows cloud tenants to
assure that their VMs are running “as is” on machines protected by
CloudVisor. Hence, attackers cannot alter the booting environment
or fool a tenant’s VM to run in a wrong execution mode such as a
para-virtualized mode and a different paging mode, which will be
detected and refused by CloudVisor.
Non-Security Goals: As a tenant’s VM stil l uses services provided
by th e VMM and its management VM and tools, CloudViso r cannot
guarantee availability and execution correctness of a tenant’s VM.
However, we believe this is not an issue for multi-tenant cloud, as
the primary goal of cloud providers i s featuring utility-st yle com-
puting resources to users with certain service-level agreement. Pro-
viding degraded or even wrong services will be easily discovered
by customers and the misbehaving provider or operator will soon
be dumped out of the market.
CloudVisor does not guard against side-channel attacks in the
cloud [49], which may be hard to d eploy and have very limited
bandwidth to leak informati on. However, C loudVisor does lever-
age advanced hardware features like AES instructions in recent
CPUs [4] to prevent leakage of crypto keys [56]. Further, many
security-critical applications such as OpenSSL have builtin mecha-
nism to defend against side-channel attacks.
CloudVisor also provides no protection to interactions of a VM
with its outside environments. Hence, the security of a tenant’s VM
is ultimately limited by the VM itself. For example, an adversary
may sti ll be able to subvert a VM by exploiting security vu lnerabil-