scispace - formally typeset
Search or ask a question
Journal ArticleDOI

A survey of security issues in hardware virtualization

TL;DR: This article provides a thorough survey of security issues in hardware virtualization, focusing on potential vulnerabilities and existing attacks on various virtualization platforms, but also briefly sketch some possible countermeasures.
Abstract: Virtualization is a powerful technology for increasing the efficiency of computing services; however, besides its advantages, it also raises a number of security issues. In this article, we provide a thorough survey of those security issues in hardware virtualization. We focus on potential vulnerabilities and existing attacks on various virtualization platforms, but we also briefly sketch some possible countermeasures. To the best of our knowledge, this is the first survey of security issues in hardware virtualization with this level of details. Moreover, the adversary model and the structuring of the attack vectors are original contributions, never published before.

Summary (11 min read)

Jump to: [1. INTRODUCTION][2. OVERVIEW OF VIRTUALIZATION CONCEPTS][2.1. Guest Environments][2.2. Host (Privileged) Operating System][2.3. Hypervisor and Virtual Machine Monitor][2.4. Management interface][2.5. Network][2.6. Storage][3. ADVERSARY MODEL][3.1. Network Adversary][3.2. Local Adversary][4. VIRTUAL MACHINE DETECTION][5. COMPROMISING THE GUEST][5.1. Internet to Guest (i2g)][5.2. Guest to Guest (g2g)][5.3. Virtual Machine Migration Network to Guest (vmmn2g)][5.4. Guest to Self (g2s)][5.5. Management interface to Guest (m2g)][6. COMPROMISING THE HOST OS][6.1. Guest to Host OS (g2h)][6.2. Host OS to Self (h2s)][6.3. Internet to Host OS (i2h)][7.1. Guest to Hypervisor (g2hy)][7.2. Host OS to Hypervisor (h2hy)][7.3. Physical/Physical Management Interface to Hypervisor (p2hy)][8. COMPROMISING THE MANAGEMENT INTERFACE][8.1. Guest to Management Interface (g2m)][8.2. Network to Management Interface (n2m)][9. COMPROMISING NETWORKS][9.1. Attack Surfaces of Physical and Virtual LANs][9.2. Compromising Networks of Virtual Systems][10. MISCELLANEOUS THREATS][11. COUNTERMEASURES][11.2. Hardening the Hypervisor and VMs][11.3. Restriction of Physical Access][11.4. Policy and Isolation][11.5. Separation of Roles][11.6. Separation of VMs][11.7. Considering the State of VMs][11.8. Mitigating Design Discrepancies][11.9. Securing the Network][11.10. Adequate Logging and Monitoring][12. SUMMARY] and [ACKNOWLEDGMENTS]

1. INTRODUCTION

  • Virtualization is a powerful technology for increasing the efficiency of computing services provided to private and business users in terms of performance, maintenance, and cost.
  • By controlling access to the physical resources, virtualization can also be used to run different services in parallel on the same physical hardware.
  • As it turns out, the number of reported vulnerabilities and attacks on different virtualization platforms is quite large, so the authors structure the presentation of those based on their target; hence, they introduce vulnerabilities and attacks targeting the guest, the host OS, the hypervisor layer, the management interfaces, and the different networks within a virtual infrastructure.
  • Moreover, the adversary model and the structuring of the attack vectors are original contributions, which have not been published before.

2. OVERVIEW OF VIRTUALIZATION CONCEPTS

  • VMs can be classified into two main categories: process and system virtual machines, as Figure 1 depicts.
  • System virtualization provides a complex layer to services implementing both hardware virtualization1 and hardware emulation.
  • The authors note, however, that some platforms, for example, Xen [Takemura and Crawford 2007] and Kernel-based Virtual Machine (KVM) [KVM 2007] heavy-use hardware emulators, for example, QEMU [Bellard 2005; 2008], for device virtualization, therefore security of hardware virtualization cannot be discussed fully separately from hardware emulation.
  • 4Binary translation is the only solution that uses neither CPU hardware virtualization extension nor OS assist to virtualize sensitive or privileged instructions.

2.1. Guest Environments

  • Each single virtual machine, which comprises a stack made up from an operating system and its applications, defines a guest environment.
  • All the guests are isolated from each other, while they use the same virtual platform provided by the hypervisor.
  • The interface published by the physical platform is uniform and used by all the VMs to access real hardware resources.
  • An important feature of this environment is that guests must run at reduced privilege level in order to allow the hypervisor to control their operations.

2.2. Host (Privileged) Operating System

  • A host operating system always has a more privileged role than guest VMs to be able to manage them and control hardware resources either directly or via the hypervisor.
  • Note that management functionalities are not bound to host operating systems; therefore, the authors discuss them separately in Section 2.4.
  • The host operating system can either be a native operating system, for example, in the case of VMware WS, or a privileged VM, for example, in the case of Microsoft Hyper-V [Microsoft 2008] or Xen.
  • In addition, certain virtual platforms, for example, VMware ESXi [VMware 2007], Citrix XenServer [Citrix 2007], do not employ real host operating systems; only a small hypervisor and a management interface are provided to allow administrators to remotely configure the virtual server.
  • The authors use this nomenclature in order to handle specific security issues (e.g., guest-to-host OS escape) conveniently in the rest of the article.

2.3. Hypervisor and Virtual Machine Monitor

  • As has been introduced, the hypervisor is a software component that intercepts all hardware access requests of the VMs and mediates these requests to physical devices.
  • The tasks of the VMM include the selective control of hardware resources, the provision of replicated platforms, and the sharing of hardware resources between guest operating systems.
  • It is important to emphasize that there exist hypervisors, for example, SecVisor [Seshadri et al. 2007], that do not involve VMM functionalities.
  • Examples of native virtual platforms include VMware ESX/ESXi, Xen, Microsoft Hyper-V, while hosted virtual platforms include ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.
  • See VMware [2009c] for more information about VMware ESX/ESXi.

2.4. Management interface

  • In order to configure and manage guest VMs, vendors provide management interfaces for their products.
  • These allow privileged users to create, delete, and modify both virtual machines and virtual infrastructures.
  • Management interfaces reside at various levels in the software stack depending on the virtualization technology.
  • Examples for this include technologies such as VMware ESXi, Citrix XenServer, Microsoft Hyper-V Server.
  • Furthermore, a management interface might also have a Web front end for an increased availability.

2.5. Network

  • Virtual servers are not meant to be isolated nodes running multiple VMs simultaneously, but they are networked in order to add higher efficiency and performance.
  • In virtual networks, one can connect VMs in the same way as one does with physical networks; in addition, networking is feasible within a single virtual server host and across multiple hosts, too.
  • These internal networks can have operational disadvantages, because traditional network tools designed for physical switches and nodes may not work properly with them.
  • Note that physical management communication differs from its virtual counterpart.
  • Used to transport physical management traffic to archive them on a network-based storage dedicated to management data.

2.6. Storage

  • Storage virtualization abstracts away physical storage components and provides a single storage device that can be reached directly or over the network.
  • This conceptual simplicity comes with the price of enhanced data management and distributed access requirements.
  • Furthermore, VMware supports raw device mappings (RDM) technology that allows virtual machines to read and write to an existing volume (iSCSI or FC) directly7 [VMware 2008a].
  • Each virtual disk appears as an SCSI device for the virtual machine without taking into account the real physical connection (RAID, SCSI, iSCSI, NFS, or FC).
  • Stores files remotely on a Fibre Channel SAN through a VMFS (RDM) volume.

3. ADVERSARY MODEL

  • The authors classify attackers into two main categories: network and local attackers, though the two may overlap.
  • In their taxonomy, the authors also adopt the traditional hacking models, black box and grey box, where the former refers to an attacker without any network or physical access to the target system, while the latter supposes an internal attacker with certain privileges (LAN or computer access).
  • The authors further distinguish white-box attacks, where a malicious user is an insider who has administrative privileges.
  • In the following, the authors define the corresponding terms for virtualized environments.

3.1. Network Adversary

  • That is, the authors build upon the traditional Dolev-Yao network threat model [Dolev and Yao 1981].
  • 7RDM can work either through a VMFS mapping file or directly without using the datastore.

3.2. Local Adversary

  • The distinction of local adversaries requires a more fine-grained approach, as their capabilities highly depend on the access rights granted to them.
  • Note that he does not access any management interfaces and does not have any prior information about other customers or the organization of the target system.
  • In an IaaS model, customers typically hire multiple VMs at the same time, which they can control through a management interface (e.g., VMware vCenter) provided by the cloud operator.
  • Thus, a malicious customer may get access to multiple VMs that he can control at will.
  • Figure 3 depicts adversaries who can launch various attacks (BB, GGB, IGB, WB) depending on their access rights to resources.

4. VIRTUAL MACHINE DETECTION

  • Since the appearance of hardware virtualization technologies, a considerable amount of effort has been devoted to making virtualized environments transparent.
  • Instead of simple detecting virtualization, malware writers have ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.

5. COMPROMISING THE GUEST

  • Up until this point, the adversary could detect and identify the virtual system he is about to compromise.
  • Moreover, inactive images are typically left out of security measures, such as security patches, access policies, or sensitive configurations.
  • One of the most threatening issues is cross-VM information flow, which allows an attacker to steal information from other guest VMs residing on the same physical host [Ristenpart et al. 2009].
  • Moreover, sensitive keys can be extracted from public virtual machine images (e.g., API keys from Amazon Machine Images (AMI) [Bugiel et al. 2011]) that allow a ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.
  • This section classifies these security weaknesses with the corresponding attack vectors depicted in Figure 4.

5.1. Internet to Guest (i2g)

  • A guest VM is exposed to external network attacks just like conventional server hosts.
  • Note that there exist critical OS-level vulnerabilities, for example, the TrueType Font Parsing Vulnerability (CVE-2011-3402) used by the Duqu malware [Bencsáth et al. 2011], that can be exploited remotely by simple social engineering techniques, such as convincing the user to open an infected Word Doc file or visit a website with malicious content.
  • Moreover, the intruder can take advantage of the virtualized nature of the system and exploit the virtualization specific flaws in it.
  • Even an attacker with this knowledge base should first fingerprint the remote system to detect if it is virtualized and attack accordingly if so.

5.2. Guest to Guest (g2g)

  • These attacks are typically indirect: first a rogue user should escape from a guest environment and then compromise other guests through privileged access to the host.
  • Note that accomplishing a direct guest-to-guest attack could mean that a basic principle of hardware virtualization, for example, the perfect isolation of guest VMs, is violated.
  • This could be due to an unresolved issue in the memory management module (MMU) of the hypervisor that allows a malicious user to access memory pages of other guest VMs.
  • In the case of content-based page sharing, the VMM scans the memory periodically (20 msec by default for KSM) in order to create fingerprints from pages and to check if they are identical.
  • If so, pages are merged and shared by the guests until one of them issues a write access.

5.3. Virtual Machine Migration Network to Guest (vmmn2g)

  • Virtual machine migration makes system deployment fast and easy by copying runtime memory images of VMs between virtual server hosts through the virtual machine migration network.
  • A malicious user with access to the migration network could passively snoop the packets transmitted over the cable, thus stealing complete virtual images.
  • An active network adversary could furthermore compromise the system by manipulating the guest images (e.g., embedding rootkits, keyloggers) that are going to be installed into an allegedly sanitized virtual server.
  • A tool that demonstrates this is called Xensploit [Oberheide et al. 2008], which initiates a manin-the-middle (MITM) attack to get access to the transferred VMware or Xen guest images.
  • The authors emphasize that vendors and system administrators should pay more attention to this threat.

5.4. Guest to Self (g2s)

  • Note, here the authors suppose that the adversary can exploit a weakness in the virtual environment, and thus conventional privilege escalations are ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.
  • The Google security team discovered a vulnerability in several VMware products that allowed for such an attack (CVE-2009-2267 [Ormandy and Tinnes 2009]).
  • Practically, when the processor operates in protected mode, the two leastsignificant bits of the code segment (CS) register represent the current privilege level (CPL).
  • The error code is represented by several flags indicating, for example, if the CPU was operating in user or supervisor mode (U/S bit is set or not).
  • When a VMware guest is in Virtual-8086 mode and the adversary executes a far call or a far jump to an invalid address, a page fault is generated, and the registers are pushed to the stack using supervisory access (U/S bit is cleared) causing an invalid error code report to the guest kernel.

5.5. Management interface to Guest (m2g)

  • An attacker with access to a management interface can gain extra privileges and misconfigure other customers’ guest VMs.
  • In that way, he can reroute management or storage traffic to unsecured network segments or open backdoors for external black-box attacks.

6. COMPROMISING THE HOST OS

  • One of the most appealing targets for an adversary is to access the host operating system.
  • This can have unpredictable consequences, as not only the VMs running on top of it can be manipulated, but the adversary can reach and exploit other hosts in the virtual/physical network.
  • By doing so, he can snoop and/or manipulate storage data and virtual machine migration data transmitted over the cable and gain privileges to restricted resources, such as storages.
  • More information about storage security is discussed in Section 9.2.4.
  • Yet, compromising the host OS is not impossible.

6.1. Guest to Host OS (g2h)

  • Guest-to-host OS attacks are one of the most luring challenges that an adversary could achieve.
  • Once the adversary opens a shell, he can control the guest in accordance with his privileges.
  • There are proposed techniques [Peng et al.
  • That is, a malicious user with access to the guest operating system could exploit a vulnerability in the virtualization platform that makes the host operating system crash, practically causing denial-of-service conditions for all other guests.
  • For of example, Kortchinsky [2009] explored a vulnerability in the display function inside the vmware-vmx binary, which allows its users to launch arbitrary code on the host OS.

6.2. Host OS to Self (h2s)

  • There are circumstances when an adversary could somehow compromise a host with several VMs atop it and gain restricted access to the resources of the host OS.
  • Even a narrow time window [tc, tu] could allow an attacker, possibly after thousands of probes, to slide into that window at time ta (tc < ta < tu) and get access to resources with the privileges of the process.
  • The access system call is used to check the user’s permission for a file opened by the fopen system call.
  • As a consequence, race conditions carry real threats which emerge in virtualization softwares as well.
  • CVE2010-4295 refers to this bug in the mounting process vmware-mount of hosted VMware products, which allows a host OS user to gain extra privileges.

6.3. Internet to Host OS (i2h)

  • This section demonstrates a relatively old (2005) black-box attack where a remote intruder can exploit a heap overflow vulnerability in the VMware natd module (vmnat.exe) so as to execute arbitrary userland commands on the host [Shelton 2005].
  • The significance of this attack is that an adversary can directly access the host without compromising a guest VM.
  • The problem is that vmnat cannot process specially crafted PORT and EPRT FTP commands.
  • The former defines the local PORT on which the client listens for data communication, while the latter refers to Extended Data Port, defined in RFC 2428, and allows for an extended address (network protocol, network/transport address) for data connection.
  • By constructing an evil buffer content, the attacker can gain control over registers ECX, EDI, and EBX, which allows him to overwrite an available heap header FLINK (pointer to the next free memory chunk) and PLINK (pointer to the previous free memory chunk).

7.1. Guest to Hypervisor (g2hy)

  • Guest-to-hypervisor escapes are possibly the most frightening security issues related to hardware virtualization.
  • More precisely, an adversary could load malicious buffer content into the input parameter of FLASK-specific hypercalls.
  • Of driver domains or driver virtual machines .
  • The introduced (theoretical and practical) attacks send specially crafted message signaled interrupts (MSI) from an untrusted driver domain via a network interface card (NIC) to one of the processors in a multiprocessor system.
  • All in all, these exotic attacks perfectly demonstrate that even hypervisors and the x86 architecture can contain serious vulnerabilities, which can be exploited from the guest both theoretically and practically.

7.2. Host OS to Hypervisor (h2hy)

  • The runtime modification of hypervisors is an appealing problem for many adversaries, as they could insert silent backdoors and rootkits underneath the operating systems.
  • In the Xen 0wning Triology [Wojtczuk 2008b], the author presents several ways to modify the Xen hypervisor via DMA transfers.
  • The attack supposes that the adversary has root privileges on the host OS, which is not impossible to achieve (see Section 8.1 for demonstration).
  • In addition, the author of Wojtczuk [2008b] could present another attack at the same time, where even an Intel VT-d-aware architecture could be tricked.

7.3. Physical/Physical Management Interface to Hypervisor (p2hy)

  • Physical white-box attacks are not so frequent in reality, yet they present a serious threat due to rogue malicious system administrators and employees.
  • Such an administrator could shutdown, reboot, etc. a virtual server host with multiple VMs on top of it.
  • Furthermore, guest-to-host escapes (see Sections 6.1.3 and 8.1) could allow a guest user to execute arbitrary privileged instructions on the host.
  • The first attack [Wojtczuk and Rutkowska 2009] consists of two stages: hooking the CPU’s system management mode (SMM)9 handler and compromising the securely-loaded hypervisor (here Xen) via that attack vector.
  • The second attack [Wojtczuk et al. 2009] could misconfigure the TXT chipset in such a way that a securely loaded hypervisor could be compromised via traditional DMA attacks.

8. COMPROMISING THE MANAGEMENT INTERFACE

  • Access to the management interface can be critical, considering the overall security of the virtual environment.
  • That is, management interfaces can either be bound to an existing host operating system, or the virtualization technology provides only a small management console to which the administrator can remotely connect by means of a management client.
  • An attacker with access to a central management interface could compromise a whole virtual infrastructure.
  • See Figure 8 for the representation of attack vectors.

8.1. Guest to Management Interface (g2m)

  • As has already been mentioned previously, a potential attack surface is the management interface that could be compromised from a guest VM, for example.
  • This section discusses two examples of this case.
  • CVE-2007-4993 is one example where a privileged guest user over Xen 3.0.3 can craft a malicious boot config file (grub.conf) to execute arbitrary commands in the host operating system during system launch.
  • Another security problem is described in CVE-2009-0518, where the VMware VI Client retains the server-side password in its process memory after connecting to the virtual center that might allow a guest user to read it out.
  • Figure 3 illustrates how an adversary on the virtual management servers could launch infrastructure grey-box attacks via the compromised management interface.

8.2. Network to Management Interface (n2m)

  • Management interfaces often provide Web surfaces for more convenient system monitoring and controlling.
  • Similarly to any other Web applications, these sites ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.
  • May not meet the sufficient security requirements.
  • By doing so, when a system administrator opens the Web interface next time, the script embedded there is executed on his local computer, causing a system attack.
  • From that point on, the impact of the attack depends on the intruder.

9. COMPROMISING NETWORKS

  • Network virtualization comes with a diverse and useful feature set; however, it still cannot provide the same security level as physical networks.
  • First of all, virtual network components can suffer from the same software weaknesses (e.g., buffer overflows, integer overflows, etc.) as traditional applications do.
  • Moreover, VSAs are still not strong enough to prevent or contain sophisticated attacks and malcodes.
  • By compromising a network segment via L2 switches, an attacker can sniff and manipulate the traffic, snoop information, and so on.
  • Here the authors suppose that different networks discussed in Section 2.5 are segregated into different VLANs/network segments, as best practices suggest.

9.1. Attack Surfaces of Physical and Virtual LANs

  • Each network segment, discussed in Section 2.5, has its own proprietary goal of physical or virtual separation, so segregation should be a focal point in guaranteeing the basic level of security.
  • Practically, different network traffics are bundled into a common physical port that is represented by a virtual switch in the hypervisor by trunking, and different VLANs are created for each of them ).
  • VLAN hopping exploits networks with multiple VLANs by enabling an attacker to escape from his VLAN segment and intercept or modify network traffic transmitted in other VLANs.
  • By MAC address spoofing, an attacker can impersonate another host.
  • 12A special data frame used by bridges to exchange information about the network so as to determine the root bridge.

9.2. Compromising Networks of Virtual Systems

  • Thus, virtual machines can get access to plaintext and sensitive management data.
  • The most threatening issues considering storage network security are snooping attacks where a malicious user can passively sniff the data being transmitted.
  • ISCSI (Internet Small Computer System Interface) is another SAN protocol that, similarly to FC, allows block-level access to storages; thus entire LUNs (logical unit numbers)14 can be accessed by iSCSI clients.
  • By using ARP poisoning, he can impersonate the valid iSNS server with a fake one which is used as a mediator.

10. MISCELLANEOUS THREATS

  • Up until now, a considerably wide spectrum of attacks on hardware virtualization has been introduced with detailed description of flaws or design vulnerabilities.
  • Albeit, there are other threats called virtual-machine based rootkits, which install a VMM underneath an existing operating system and execute the original OS in a guest system.
  • By doing so, the rootkit can mediate between the hardware and the OS in order to perform naughty activities, such as key logging, opening a backdoor, and monitoring the OS.
  • In 2006, three such projects emerged—Bluepill [Rutkowska 2006], Subvirt [King et al. 2006], and Vitriol [Zovi 2006]—each of which targeted different platforms and operating systems.
  • Bluepill and Vitriol are capable of installing themselves underneath a running operating system on the fly, without reboot, while SubVirt modifies the boot process in order to activate itself.

11. COUNTERMEASURES

  • Following the detailed discussion on various vulnerabilities and attacks in hardware virtualized environments, in this section, the authors give a brief overview on possible countermeasures.
  • The authors note, however, that the main objective of this article is to survey the vulnerabilities rather then giving a detailed introduction of the countermeasures.

11.2. Hardening the Hypervisor and VMs

  • Hardening of the hypervisor and the hosted VMs should also be a focal point of systemwide security.
  • That is, the latest security patches for traditional applications should be also installed both on the hypervisor and the hosted VMs.
  • The main contributions in this area are summarized elegantly in Szefer et al. [2011] as follows.
  • One example of this approach is SecVisor [Seshadri et al. 2007] that supports and secures one single guest VM, while TrustVisor [McCune et al. 2010] allows for integrity protection of code and data in designated application portions.

11.3. Restriction of Physical Access

  • The physical or physical management network access of virtual server hosts should be restricted as much as possible (see Section 7.3), as it can simultaneously mean access to VMs, storages, networks, hypervisors, virtual appliances, and so on.
  • Unused physical interfaces should be disabled in order to tailor the attack surface and limit the caused damage.

11.4. Policy and Isolation

  • Control policies of virtual environments should be implemented and maintained to provide the same level of security that physical environments have.
  • Furthermore, the isolation of security functions is another core point of system-wide hardening.
  • Firewall functionalities should never be combined with private key storing on the same virtual host, as it can be a single point of failure that affects the integrity of the whole virtual environment.

11.5. Separation of Roles

  • Administrative roles should be separated, as best practices suggest.
  • A storage administrator should not get access to firewalls and monitoring services, and vice versa.
  • Furthermore, multifactor authentication and dual- or splitcontrol administrative passwords for various administrators should be used in order to reduce the risk of a malicious supervisor.
  • Role-based access control (RBAC) should be maintained for virtual components in order to avoid unwanted access to resources.

11.6. Separation of VMs

  • VMs with different security levels should be hosted on different virtual servers.
  • A VM with lower security requirements typically has weaker security controls which can be ideal for an attacker to compromise other VMs with higher security requirements being hosted on the same physical hardware.

11.7. Considering the State of VMs

  • Section 5 highlighted a few security problems for unprotected inactive VMs.
  • More precisely, migration path of inactive VMs should point to secured routes that cannot be compromised by man-in-the-middle attackers.
  • Inactive VMs containing highly sensitive information should be stored and maintained at the same security level as any other active VMs containing similar pieces of information.
  • Backup and restoration of active/inactive VMs should also be treated securely.
  • Furthermore, data that are not required any more should be deleted simultaneously in each copy of a VM.

11.8. Mitigating Design Discrepancies

  • There are design-level issues where software vendors must take the security-toperformance trade-off into account.
  • Direct guest-to-guest attacks include the passive memory deduplication attack which can be mitigated by setting the pages of target applications read-only in the page table entries (PTE) of the VM so that the adversary cannot measure write access latency and cannot predict the launch of an application.
  • Another possible workaround is the obfuscation of the code image loaded into the memory by the victim’s operating system.
  • Technically speaking, timing analysis is one option for detecting the presence of a certain variant of this malware; however, there are other enhanced implementations that resist timing analysis.
  • As the sanitization of an infected hypervisor is not trivial, preventive countermeasures have to be employed, including the installation of most-recent security patches, although it still does not solve the problem of white-box attacks.

11.9. Securing the Network

  • Certain network discrepancies, such as sniffing and snooping of migration and storage traffic (as discussed in Sections 5.3, 9.2.2, 9.2.4) can be mitigated by appropriate secure communication channels, such as SSL or IPsec.
  • Spanning Tree attacks (Section 9.1.4) can be prevented traditionally by proprietary tools (e.g., bpdu-guard, root-guard, of the vendor), so virtual switches have to implement such methods by default.
  • MAC address spoofing (Section 9.1.6) can also be prevented.
  • In the case of VMware ESX, the administrator can disable the guest OS to change the virtual MAC address.
  • To alleviate the risk of most of the attacks targeting storage networks, system administrators should separate this traffic and apply secure channels (IPSec, SSL) to protect the data transmitted here.

11.10. Adequate Logging and Monitoring

  • The logging and monitoring of all activities in a deployed virtual environment is highly recommended.
  • Logs should be directed into separate physical storages that are secured with appropriate functions.
  • This helps to identify and analyze data breaches or any compromises that affect the integrity of communication channels, security controls, or segmentation.
  • An exciting workaround to mitigate the damage for virtual machine attacks is represented by ReVirt [Dunlap et al. 2002] that makes use of virtual machine logs to replay a system’s execution before, during, and after an attacker compromises it.
  • Further suggestions for countermeasures can be found in PCI Security Standards Council [2011].

12. SUMMARY

  • The authors focused on potential vulnerabilities and existing attacks on hardware virtualization platforms, but they also briefly sketched some possible countermeasures.
  • This requires better understanding and continuous research in this domain.
  • The impact of an attack on a hypervisor could be very serious because it affects multiple guest operating systems and the services running on top of those.
  • Therefore, vendors of virtualized platforms should pay special attention to the security of their products, system administrators should pay special attention to careful operation and maintenance of virtual infrastructures, and researchers should develop effective tools for detecting and containing such attacks.

ACKNOWLEDGMENTS

  • The authors would like to thank KÜRT Co. for providing the virtualization infrastructure to test and verify the feasibility of certain attacks and countermeasures.
  • Special thanks go to Sándor Szunyogh for his precious practical advice.
  • The authors would also like to thank Márk Félegyházi, Peter Szor, Zoltán Micskei, and the anonymous reviewers for their useful comments.
  • Pictograms and icons used for figures are created by Zsombor Kiss (http://www.kisszsombor.com).

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

40
A Survey of Security Issues in Hardware Virtualization
G
´
ABOR P
´
EK, Budapest University of Technology and Economics and K
¨
URT Co.
LEVENTE BUTTY
´
AN, Budapest University of Technology and Economics.
BOLDIZS
´
AR BENCS
´
ATH, Budapest University of Technology and Economics.
Virtualization is a powerful technology for increasing the efficiency of computing services; however, besides
its advantages, it also raises a number of security issues. In this article, we provide a thorough survey of
those security issues in hardware virtualization. We focus on potential vulnerabilities and existing attacks
on various virtualization platforms, but we also briefly sketch some possible countermeasures. To the best of
our knowledge, this is the first survey of security issues in hardware virtualization with this level of details.
Moreover, the adversary model and the structuring of the attack vectors are original contributions, never
published before.
Categories and Subject Descriptors: D.4.6 [Operating Systems]: Security and Protection
General Terms: Security
Additional Key Words and Phrases: Hardware virtualization, operating systems, security, malware
ACM Reference Format:
P
´
ek, G., Butty
´
an, L., and Bencs
´
ath, B. 2013. A survey of security issues in hardware virtualization. ACM
Comput. Surv. 45, 3, Article 40 (June 2013), 34 pages.
DOI: http://dx.doi.org/10.1145/2480741.2480757
1. INTRODUCTION
Virtualization is a powerful technology for increasing the efficiency of computing ser-
vices provided to private and business users in terms of performance, maintenance, and
cost. Essentially, virtualization provides an abstraction of physical hardware resources
that allows for the operation of the same services on a multitude of different physical
hardware platforms. By controlling access to the physical resources, virtualization can
also be used to run different services in parallel on the same physical hardware. It
allows, for example, for the execution of multiple operating systems simultaneously on
the same physical host. In this way, resources can be utilized more efficiently, and users
can decrease their expenditures on computing services significantly. For these very
same reasons, virtualization plays a key role in cloud computing, which allows distinct
customers to hire online computing resources for their own purposes. By doing so,
specific applications (Software as a Service—SaaS), development platforms (Platform
This work is connected to the scientific program of the “Development of quality-oriented and harmonized
R+D+I strategy and functional model at BME”, and the “Security focused services and products in cloud
infrastructure environment” project at K
¨
URT Co., supported by the New Sz
´
echenyi Plan (Project ID: T
´
AMOP-
4.2.1/B-09/1/KMR-2010-0002 and GOP-1.3.1-09/B-2010-0007). L. Butty
´
an was partially funded by the
Hungarian Academy of Sciences through the support of the Academic Research Group on Information
Systems (ID: 04-130).
Authors’ addresses: G. P
´
ek,L.Butty
´
an, and B. Bencs
´
ath, Laboratory of Cryptography and System Secu-
rity, Budapest University of Technology and Economics, BME-HIT, PO Box 91, 1521 Budapest, Hungary;
corresponding author’s email: pek@crysys.hu.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted
without fee provided that copies are not made or distributed for profit or commercial advantage and that
copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for
components of this work owned by others than ACM must be honored. Abstracting with credit is permitted.
To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this
work in other works requires prior specific permission and/or a fee. Permissions may be requested from
Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212)
869-0481, or permissions@acm.org.
c
2013 ACM 0360-0300/2013/06-ART40 $15.00
DOI: http://dx.doi.org/10.1145/2480741.2480757
ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.

40:2 G. P
´
ek et al.
as a Service—PaaS), or complete virtual machines with networking components and
storage capabilities (Infrastructure as a Service—IaaS) can be requested from the
cloud operator on a pay-per-use basis.
While the advantages of virtualization are pretty much clear to everyone, one must
also be aware of the fact that it gives rise to a number of security issues. Some of
those issues exist in traditional computing environments as well, but they need to
be addressed with special care in virtualized environments, while some other issues
are specific to virtualization and hence require novel solutions. One such example is
multitenancy, which allows for cross-platform information flow between customers hir-
ing virtual machines over the same physical host [Ristenpart et al. 2009] in an IaaS
cloud. Other issues entitle adversaries to execute arbitrary out-of-the-guest code ei-
ther locally [Wojtczuk 2008b] or remotely [Shelton 2005] without owning the required
access rights. Virtualized storage systems also have special security requirements
[Dwivedi 2003, 2004, 2005] in order to keep data secure. Due to the increasing pop-
ularity of using virtualization technologies, it is important to discuss these security
issues and hence raise the awareness of the potential users of virtualized services and
infrastructures.
For this reason, in this article, our objective is to provide a thorough survey of security
issues in hardware virtualization. We focus on potential vulnerabilities and existing
attacks on hardware virtualization platforms, but we also briefly sketch some possible
countermeasures. As it turns out, the number of reported vulnerabilities and attacks
on different virtualization platforms is quite large, so we structure the presentation of
those based on their target; hence, we introduce vulnerabilities and attacks targeting
the guest, the host OS, the hypervisor layer, the management interfaces, and the differ-
ent networks within a virtual infrastructure. The detailed discussion of vulnerabilities
and attacks is preceded by the definition of an adversary model and a short overview
on virtualization detection and identification techniques.
More specifically, the content of this survey is structured as follows: We first present
a taxonomy of virtualization concepts in Section 2; this helps to understand the scope
of our survey, which is focused on hardware virtualization. After that, in Section 3,
we introduce an adversary model,where we distinguish different types of adversaries
based on their available privileges and the targeted resources. Since, as a first step of an
attack, the adversary needs to detect and identify the virtualized environment, we give
a short overview on existing techniques for virtual machine detection and identification
in Section 4. Then, we describe vulnerabilities and attacks aimed at compromising the
guest, the host operating system, and the hypervisor in Sections 5, 6, and 7, respec-
tively. In addition to studying the security issues at the main software layers, we also
survey vulnerabilities and attacks on the management interfaces in Section 8, and
on the various networks and storage services used in a typical virtual infrastructure
in Section 9. Some miscellaneous threats related to virtualization are mentioned in
Section 10. Finally, we provide a brief overview on possible countermeasures against
the discussed attacks in Section 11 and conclude the paper in Section 12.
To the best of our knowledge, this is the first survey of security issues in hardware
virtualization with this level of details. Moreover, the adversary model and the struc-
turing of the attack vectors are original contributions, which have not been published
before. We believe that they are sufficiently general to be used to classify not only
existing but also future vulnerabilities and attacks in virtualized environments.
Note that the sources from which we compiled this survey are not limited to papers
published in journals or conference proceedings, but we extensively relied upon the
Common Vulnerabilities and Exposures (CVE) database hosted by MITRE (available
online at http://cve.mitre.org/). References to CVE records do not appear in the
reference list at the end of the article, but they can be easily resolved online.
ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.

A Survey of Security Issues in Hardware Virtualization 40:3
Fig. 1. Taxonomy of virtualization concepts.
2. OVERVIEW OF VIRTUALIZATION CONCEPTS
A virtual machine (VM) is an abstraction of computing resources presented to services
to allow them to operate simultaneously on the same physical hardware infrastructure.
VMs can be classified into two main categories: process and system virtual machines, as
Figure 1 depicts. A process VM executes an individual process, and thus its lifetime is
identical to the lifetime of the corresponding process. Examples for such VMs are found
in well-known development platforms, such as Microsoft.NET and Java VM. Extending
this concept, system virtualization corresponds to a VM that provides a complete op-
erating system with multiple processes. The process or system being executed in a VM
is called the guest, while the underlying platform that allows a VM to run is defined as
the host. System virtualization provides a complex layer to services implementing both
hardware virtualization
1
and hardware emulation. Hardware virtualization includes
approaches where the hardware and the software are built upon the same instruction
set, while hardware emulation can apply different instruction sets. In this article,
we focus on the security issues of hardware virtualization. We note, however, that
some platforms, for example, Xen [Takemura and Crawford 2007] and Kernel-based
Virtual Machine (KVM) [KVM 2007] heavy-use hardware emulators, for example,
QEMU [Bellard 2005; 2008], for device virtualization, therefore security of hardware
virtualization cannot be discussed fully separately from hardware emulation.
Note that operating system-level virtualized platforms, such as OpenVZ [OpenVZ
2005], FreeBSD jail [FreeBSD 2000], and Oracle Solaris Containers [Oracle 2004],
cannot be placed into Figure 1, as they do not allow for the running of VMs with a
kernel version that is different from that of the host system. As a consequence, they do
not provide true virtualization. KVM is also an interesting technology, as it virtualizes
the Linux kernel but also supports hardware assisted virtualization.
2
Another combined solution is the VMware ESX/ESXi platform, which either uses
binary translation or hardware-assisted virtualization, depending on both the guest
1
Virtualization of operating systems or computers.
2
Enables a proprietary execution scheme: nonsensitive instructions are executed on the physical processor
directly, while sensitive ones are intercepted by the hypervisor, residing at a higher privilege level (ring -1)
and executed by the virtual processors implemented in the hypervisor.
ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.

40:4 G. P
´
ek et al.
(a) Native virtual platform. (b) Hosted virtual platform. (c) Our notation.
Fig. 2. Main types of hardware virtualization.
operating system and the processor architecture, in order to achieve optimized per-
formance [VMware 2009a, 2011a]. Furthermore, both native (also known as bare-
metal) and hosted virtual platforms can use paravirtualization
3
, binary translation
4
,
or hardware-assisted virtualization to reach greater throughput and CPU utilization.
For instance, VMware installs paravirtualized drivers, for example, paravirtual SCSI
adapters (PVSCSI) for ESX/ESXi guests [VMware 2012], while the new MS Virtual PC
exploits the rich feature set of hardware assisted virtualization [Microsoft 2012].
A unique and interesting idea is presented by NoHype [Keller et al. 2010], which
assigns dedicated physical resources to VMs (processor core, memory partition, etc.) by
removing the hypervisor. Therefore, NoHype eliminates the attack surface exposed by
the hypervisor but offers a viable solution for secure cloud computing, as it supports
multitenancy and resource utilization. See sources [Smith and Nair 2005; Adams and
Agesen 2006; Scope Alliance 2008] for more detailed information about virtualization.
Hardware virtualization allows the sharing of hardware resources via hypervisors,
which are software components that intercept all hardware access requests of the
VMs and mediate these requests to physical devices. In many cases, a hypervisor is
commonly referred to as the host, which should not be confused with the host operating
system responsible for managing guest VMs and controlling hardware resources. We
use a high-level system model depicted in Figure 2(c) in order to handle various system
virtualization platforms uniformly. Note that this is a certain type of generalization,
as the location of these layers differs from implementation to implementation. Later,
in Section 2.3, we explain the figure in details. Here we separate three software layers:
guest VMs, the host operating system, and the hypervisor. In the rest of the section,
we discuss the main components of a hardware virtualized environment extended by
network virtualization functionalities.
3
Paravirtualization is a type of virtualization that requires modified guest OSs to replace their nonvirtual-
izable instructions to special hypervisor system calls (hypercalls).
4
Binary translation is the only solution that uses neither CPU hardware virtualization extension nor OS
assist to virtualize sensitive or privileged instructions. Similarly to the concepts of other binary translators,
the VMM (or hypervisor) translates privileged OS requests and caches them for repeated use, while user-
mode instructions are executed natively.
ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.

A Survey of Security Issues in Hardware Virtualization 40:5
2.1. Guest Environments
Each single virtual machine, which comprises a stack made up from an operating
system and its applications, defines a guest environment. All the guests are isolated
from each other, while they use the same virtual platform provided by the hypervisor.
The interface published by the physical platform is uniform and used by all the VMs
to access real hardware resources. An important feature of this environment is that
guests must run at reduced privilege level in order to allow the hypervisor to control
their operations.
2.2. Host (Privileged) Operating System
A host operating system always has a more privileged role than guest VMs to be able
to manage them and control hardware resources either directly or via the hypervi-
sor. Note that management functionalities are not bound to host operating systems;
therefore, we discuss them separately in Section 2.4. The host operating system can
either be a native operating system, for example, in the case of VMware WS, or a priv-
ileged VM, for example, in the case of Microsoft Hyper-V [Microsoft 2008] or Xen. In
addition, certain virtual platforms, for example, VMware ESXi [VMware 2007], Citrix
XenServer [Citrix 2007], do not employ real host operating systems; only a small hy-
pervisor and a management interface are provided to allow administrators to remotely
configure the virtual server. Note that the term host operating system can be confus-
ing in case of native platforms, as it refers to a privileged guest VM (e.g., Xen (dom0),
Hyper-V (root partition)). However, we use this nomenclature in order to handle specific
security issues (e.g., guest-to-host OS escape) conveniently in the rest of the article.
See Sections 2.4 and 8 for more details.
2.3. Hypervisor and Virtual Machine Monitor
As has been introduced, the hypervisor is a software component that intercepts all
hardware access requests of the VMs and mediates these requests to physical devices.
A hypervisor typically implements a virtual machine monitor (VMM) component as
well to manage VM hardware abstraction.
The tasks of the VMM include the selective control of hardware resources, the pro-
vision of replicated platforms, and the sharing of hardware resources between guest
operating systems. Moreover, VMMs can manage and maintain the applications on the
guests. If a guest invokes privileged instructions, they are first intercepted by the VMM,
which checks the authenticity of instructions and performs them on behalf of the guest.
It is the VMM’s responsibility to ensure that these aforementioned operations remain
transparent for guests. It is important to emphasize that there exist hypervisors, for
example, SecVisor [Seshadri et al. 2007], that do not involve VMM functionalities.
Hypervisors and also hardware virtualization come with two main types: native (type
1) and hosted (type 2). Native (bare-metal) hypervisors (see Figure 2(a)) run directly on
top of the hardware; thus they have full control over hardware resources such as CPUs,
memory, devices, and so on. Therefore, they have to provide an abstraction layer for
guests by adding virtual processors that allow guest codes to be executed. Furthermore,
CPU scheduling, interrupt handling, I/O control, and memory management are also
essential tasks to fulfil. A hosted hypervisor (see Figure 2(b)) runs as a process on top of
an existing host operating system. It monitors the requests of the guest and dispatches
them to an appropriate API function. Thus, the architectural position of the hypervisor
and the host operating system is swapped in case of native and hosted virtual platforms.
This is the reason why the boundaries of the hypervisor are indicated with a dotted line
(see Figure 2(c)) in the rest of the article. Examples of native virtual platforms include
VMware ESX/ESXi, Xen, Microsoft Hyper-V, while hosted virtual platforms include
ACM Computing Surveys, Vol. 45, No. 3, Article 40, Publication date: June 2013.

Citations
More filters
Journal ArticleDOI
TL;DR: The definition of MEC, its advantages, architectures, and application areas are provided; where the security and privacy issues and related existing solutions are also discussed.
Abstract: Mobile edge computing (MEC) is an emergent architecture where cloud computing services are extended to the edge of networks leveraging mobile base stations. As a promising edge technology, it can be applied to mobile, wireless, and wireline scenarios, using software and hardware platforms, located at the network edge in the vicinity of end-users. MEC provides seamless integration of multiple application service providers and vendors toward mobile subscribers, enterprises, and other vertical segments. It is an important component in the 5G architecture which supports variety of innovative applications and services where ultralow latency is required. This paper is aimed to present a comprehensive survey of relevant research and technological developments in the area of MEC. It provides the definition of MEC, its advantages, architectures, and application areas; where we in particular highlight related research and future directions. Finally, security and privacy issues and related existing solutions are also discussed.

1,815 citations


Cites background from "A survey of security issues in hard..."

  • ...Virtualized servers and their hosted physical servers can be protected through hypervisor hardening, network abstractions, and isolation policies [98]....

    [...]

Journal ArticleDOI
TL;DR: The main goal of this study is to holistically analyze the security threats, challenges, and mechanisms inherent in all edge paradigms, while highlighting potential synergies and venues of collaboration.

1,045 citations


Cites background from "A survey of security issues in hard..."

  • ...For example, Abdo et al. [123] demonstrated that, by deploying a crowdsourcing platform in a trusted edge data center, it was possible to protect the anonymity of the participants of certain location-based services....

    [...]

  • ...This kind of approach might be used to track the reputation of services that are available to the whole ecosystem, such as Security-as-a-Service solutions....

    [...]

Book ChapterDOI
01 Mar 2017
TL;DR: In this article, the authors present an augmented-reality application, where the user's mobile device continuously records its current view, computes its own location, and streams the combined information to the cloud server, while the Cloud server performs pattern recognition and information retrieval and sends back to the mobile device contextual augmentation labels, to be seamlessly displayed overlaying the actual scenery.
Abstract: Introduction The ongoing development of the fifth generation (5G) wireless technologies is taking place in a unique landscape of recent advancement in information processing, marked by the emerging prevalence of cloud-based computing and smart mobile devices. These two technologies complement each other by design, with cloud servers providing the engine for computing and smart mobile devices naturally serving as human interfaces and untethered sensory inputs. Together, they are transforming a wide array of important applications such as telecommunications, industrial production, education, e-commerce, mobile healthcare, and environmental monitoring. We are entering a world where computation is ubiquitously accessible on local devices, global servers, and processors everywhere in between. Future wireless networks will provide communication infrastructure support for this ubiquitous computing paradigm, but at the same time they can also utilize the new-found computing power to drastically improve communication efficiency, expand service variety, shorten service delay, and reduce operational expenses. The previous generations of wireless networks are passive systems. Residing near the edge of the Internet, they serve only as communication access pathways for mobile devices to reach the Internet core and the public switched telephone network (PSTN). Improvements to these wireless networks have focused on the communication hardware and software, such as advanced electronics and signal processing in the transmitters and receivers. Even for 5G, substantial research effort has been devoted to densification techniques, such as small cells, device-to-device (D2D) communications, and massive multiple-input multiple-output (MIMO). The successes of this communication-only wireless evolution reflect the classical view of an information age centered on information consumption through the Internet. Yet, in many emerging applications, communication and computation are no longer separated, but interactive and unified. For example, in an augmented-reality application, which might be displayed on smart eyeglasses, the user's mobile device continuously records its current view, computes its own location, and streams the combined information to the cloud server, while the cloud server performs pattern recognition and information retrieval and sends back to the mobile device contextual augmentation labels, to be seamlessly displayed overlaying the actual scenery. As it can be seen from this example, there is a high level of interactivity between the communication and computing functions, and a low tolerance for the total delay due to information transmission and information processing.

170 citations

01 Jan 2008
TL;DR: 分析了基于处理器硬件虚拟化技术实现的KVM子系统的架构。
Abstract: 分析了基于处理器硬件虚拟化技术实现的KVM子系统的架构。针对KVM跟踪独立事件信息的局限性,提出一种新的KVM事件跟踪机制(kvmtrace)来达到性能调节的目的,并使用relayfs接口进行了设计与实现。同时探讨了Linux kernel Markers实现机制及其在kvmtrace的实际应用。

157 citations

References
More filters
Journal ArticleDOI
TL;DR: Several models are formulated in which the security of protocols can be discussed precisely, and algorithms and characterizations that can be used to determine protocol security in these models are given.
Abstract: Recently the use of public key encryption to provide secure network communication has received considerable attention. Such public key systems are usually effective against passive eavesdroppers, who merely tap the lines and try to decipher the message. It has been pointed out, however, that an improperly designed protocol could be vulnerable to an active saboteur, one who may impersonate another user or alter the message being transmitted. Several models are formulated in which the security of protocols can be discussed precisely. Algorithms and characterizations that can be used to determine protocol security in these models are given.

5,145 citations

Proceedings Article
10 Apr 2005
TL;DR: QEMU supports full system emulation in which a complete and unmodified operating system is run in a virtual machine and Linux user mode emulation where a Linux process compiled for one target CPU can be run on another CPU.
Abstract: We present the internals of QEMU, a fast machine emulator using an original portable dynamic translator. It emulates several CPUs (x86, PowerPC, ARM and Sparc) on several hosts (x86, PowerPC, ARM, Sparc, Alpha and MIPS). QEMU supports full system emulation in which a complete and unmodified operating system is run in a virtual machine and Linux user mode emulation where a Linux process compiled for one target CPU can be run on another CPU.

2,420 citations

Proceedings ArticleDOI
09 Nov 2009
TL;DR: It is shown that it is possible to map the internal cloud infrastructure, identify where a particular target VM is likely to reside, and then instantiate new VMs until one is placed co-resident with the target, and how such placement can then be used to mount cross-VM side-channel attacks to extract information from a target VM on the same machine.
Abstract: Third-party cloud computing represents the promise of outsourcing as applied to computation. Services, such as Microsoft's Azure and Amazon's EC2, allow users to instantiate virtual machines (VMs) on demand and thus purchase precisely the capacity they require when they require it. In turn, the use of virtualization allows third-party cloud providers to maximize the utilization of their sunk capital costs by multiplexing many customer VMs across a shared physical infrastructure. However, in this paper, we show that this approach can also introduce new vulnerabilities. Using the Amazon EC2 service as a case study, we show that it is possible to map the internal cloud infrastructure, identify where a particular target VM is likely to reside, and then instantiate new VMs until one is placed co-resident with the target. We explore how such placement can then be used to mount cross-VM side-channel attacks to extract information from a target VM on the same machine.

2,230 citations

Journal ArticleDOI
Carl A. Waldspurger1
09 Dec 2002
TL;DR: Several novel ESX Server mechanisms and policies for managing memory are introduced, including a ballooning technique that reclaims the pages considered least valuable by the operating system running in a virtual machine, and an idle memory tax that achieves efficient memory utilization.
Abstract: VMware ESX Server is a thin software layer designed to multiplex hardware resources efficiently among virtual machines running unmodified commodity operating systems. This paper introduces several novel ESX Server mechanisms and policies for managing memory. A ballooning technique reclaims the pages considered least valuable by the operating system running in a virtual machine. An idle memory tax achieves efficient memory utilization while maintaining performance isolation guarantees. Content-based page sharing and hot I/O page remapping exploit transparent page remapping to eliminate redundancy and reduce copying overheads. These techniques are combined to efficiently support virtual machine workloads that overcommit memory.

1,528 citations

Proceedings ArticleDOI
03 Dec 1995
TL;DR: The prototype exokernel system implemented here is at least five times faster on operations such as exception dispatching and interprocess communication, and allows applications to control machine resources in ways not possible in traditional operating systems.
Abstract: Traditional operating systems limit the performance, flexibility, and functionality of applications by fixing the interface and implementation of operating system abstractions such as interprocess communication and virtual memory. The exokernel operating system architecture addresses this problem by providing application-level management of physical resources. In the exokernel architecture, a small kernel securely exports all hardware resources through a low-level interface to untrusted library operating systems. Library operating systems use this interface to implement system objects and policies. This separation of resource protection from management allows application-specific customization of traditional operating system abstractions by extending, specializing, or even replacing libraries. We have implemented a prototype exokemel operating system. Measurements show that most primitive kernel operations (such as exception handling and protected control transfer) are ten to 100 times faster than in Ultrix, a mature monolithic UNIX operating system. In addition, we demonstrate that an exokernel allows applications to control machine resources in ways not possible in traditional operating systems. For instance, virtual memory and interprocess communication abstractions are implemented entirely within an application-level library. Measurements show that application-level virtual memory and interprocess communication primitives are five to 40 times faster than Ultrix's kernel primitives. Compared to state-of-the-art implementations from the literature, the prototype exokernel system is at least five times faster on operations such as exception dispatching and interprocess communication.

1,309 citations

Frequently Asked Questions (1)
Q1. What contributions have the authors mentioned in the paper "A survey of security issues in hardware virtualization" ?

In this article, the authors provide a thorough survey of those security issues in hardware virtualization. To the best of their knowledge, this is the first survey of security issues in hardware virtualization with this level of details. The authors focus on potential vulnerabilities and existing attacks on various virtualization platforms, but they also briefly sketch some possible countermeasures.