VIRTUAL MACHINE ARCHITECTURE

Author : Prakhar Sharma April 4, 2011

Contents
1 INTRODUCTION 1.1 Evolution . . . . . . . . . . . . 1.2 Virtual Machine Concept . . . . 1.3 Early Virtual Machines . . . . . 1.3.1 Processor State Mapping 1.3.2 Memory Mapping . . . . 1.3.3 I/O Mapping . . . . . . 2 2 2 5 5 6 6 8 8 10 11 12 13 13 16 16 16 18 19 20 21 22

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

2 VIRTUALIZATION 2.1 Introduction To Virtualization . . . . . . . . . . . . . . . . . . 2.2 Virtualization Techniques . . . . . . . . . . . . . . . . . . . . 2.2.1 Full virtualization using binary translation . . . . . . . 2.2.2 OS Assisted Virtualization or Paravirtualization . . . . 2.2.3 Hardware Assisted Virtualization . . . . . . . . . . . . 2.3 Summarizing the current State of x86 Virtualization techniques 3 VIRTUAL MACHINES 3.1 Denation . . . . . . . . . . . . 3.1.1 Architectured Interfaces . 3.2 Types of Virtual Machines . . . 3.2.1 System Virtual Machines . 3.2.2 Process Virtual Machines 3.3 Virtual Machine Monitors . . . . 3.3.1 VMM Implementation . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

4 OPEN ISSUES 23 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Primary Benets . . . . . . . . . . . . . . . . . . . . . . . . . 24 i

CONTENTS 4.3 Security Vulnerabilities in Virtualization . . . . . . . . . . . . 4.3.1 Communication between VMs or Between VMs and host 4.3.2 VM Escape . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 VM monitoring from the host . . . . . . . . . . . . . . 4.3.4 VM monitoring from another VM . . . . . . . . . . . . 4.3.5 Denial of Service . . . . . . . . . . . . . . . . . . . . . 4.3.6 Guest-to-Guest attack . . . . . . . . . . . . . . . . . . 4.3.7 External Modication of a VM . . . . . . . . . . . . . 4.3.8 External modication of the hypervisor . . . . . . . . .

ii 25 25 26 26 27 28 28 28 29 30

5 CONCLUSION

List of Figures
1.1 1.2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 3.3 Conventional extended machine organization[2] . . . . . . . . Virtual Machine Organisation[2] . . . . . . . . . . . . . . . . . 3 4

Summary Timeline of x86 Virtualization Technologies[4] . . . 8 x86 Virtualization Layer[4] . . . . . . . . . . . . . . . . . . . . 9 Hypervisior manages Virtual Machine Monitors that host Virtual Machines[4] . . . . . . . . . . . . . . . . . . . . . . . . . . 10 The binary translation approach to x86 virtualization[4] . . . . 11 The Paravirtualization approach to x86 Virtualization[4] . . . 12 The hardware assist approach to x86 virtualization[4] . . . . . 14 Summary comparison of x86 processor virtualization techniques[4] 15 Computer system architecture[1] . . . . . . . . . . . . . . . . . 17 System Virtual Machine[1] . . . . . . . . . . . . . . . . . . . . 20 Process Virtual Machine[4] . . . . . . . . . . . . . . . . . . . . 21

Chapter 1 INTRODUCTION
1.1 Evolution

In the early 1960s two major evolutionary steps were taken with regard to computing systems architecture. These were the emergence of I/O processors and the use of multiprogramming to improve resource utilization and overall performance. As a consequence of the rst step computing systems became multiprocessor congurations where nonidentical processors could have access to the common main memory of the system. The second step resulted in several computational processes sharing a single processor on a time-multiplexed basis while vying for a common pool of resources. Both these developments introduced very serious potential problems for system integrity. An I/O processor executing an "incorrect" channel program could alter areas of main memory that belonged to other computations or to the nucleus of the software system. A computational process executing an "incorrect" procedure could cause similar problems to arise. Since abundant experience had demonstrated that it was not possible to rely on the "correctness" of all software, the multi-processing/multiprogramming architectures of the third generation had to rely on a completely new approach.

1.2

Virtual Machine Concept

Figure 1.1 illustrates the conventional dual state extended machine architecture which is responsible for all the diculties that were cited in the preceding section. As can be seen in the Figure1.1, the crux of the problem is that 2

CHAPTER 1. INTRODUCTION

Figure 1.1: Conventional extended machine organization[2] conventional systems contain only one basic machine interface and thus are only capable of running one privileged software nucleus at any given time. Note, however, that conventional systems are capable of running a number of user programs at the same time since the privileged software nucleus can support several extended machine interfaces. If it were possible to construct a privileged software nucleus which supported several copies of the basic machine interface rather than the extended machine interface, then a dierent privileged software nucleus could be run on each of the additional basic machine interfaces and the problems mentioned in the proceding section could be eliminated. A basic machine interface which is not supported directly on a bare machine but is instead supported in a manner similar to an extended machine interface is known as a virtual machine. As illustrated in Figure 1.2, the program which supports the additional basic machine interfaces is known as a virtual machine monitor or VMM. Since a basic machine interface supported by a VMM is functionally identical to the basic machine interface of the corresponding real machine, any privileged software nucleus which runs on the bare machine will run on the virtual machine as well. Furthermore, a

CHAPTER 1. INTRODUCTION

Figure 1.2: Virtual Machine Organisation[2]

CHAPTER 1. INTRODUCTION

privileged software nucleus will have no way of determining whether it is running on a bare machine or on a virtual machine. Thus a virtual machine is, in a very fundamental sense, equivalent to and functionally indistinguishable from its real machine counterpart. In practice no virtual machine is completely equivalent to its real machine counterpart. For example, when several virtual machines share a single processor on a time multiplexed basis, the time dependent characteristics of the virtual and real machine are likely to dier signicantly. The overhead created by the VMM is also apt to cause timing dierences. A more signicant factor is that virtual machines sometimes lack certain minor functional capabilities of their real machine counterparts such as the ability to execute self-modifying channel programs. Thus the characterization of virtual machines presented in the preceding paragraph must be slightly modied in many cases to encompass all entities which are conventionally referred to as virtual machines.

1.3

Early Virtual Machines

Virtual machine monitors for computers with dual state architecture rst appeared in the mid 1960s. Early VMMs12,13 were most noteworthy for the manner in which they controlled the processor state, main memory and I/O operations of the virtual machines which ran under their control. This section presents a brief description and analysis of the special mapping techniques that were employed in these early systems.

1.3.1

Processor State Mapping

The mapping of processor state was probably the most unusual feature of early virtual machine monitors. If a VMM did not maintain proper control over the actual state of the processor, a privileged software nucleus executing on a virtual machine could conceivably enter privileged mode and gain unrestricted access to the entire system. It would then be able to interfere at will with the VMM itself or with any other virtual machine present in the system. Since this is obviously an unacceptable situation, some mapping of virtual processor state to actual processor state was required. The solution that was adopted involved running all virtual machine processes in the non-privileged state and having the virtual machine monitor

CHAPTER 1. INTRODUCTION

maintain a virtual state indicator which was set to either privileged or nonprivileged mode, depending on the state the process would be in if it were executing directly on the bare machine. Instructions which were insensitive to the actual state of the machine were then allowed to execute directly on the bare machine with no intervention on the part of the VMM. All other instructions were trapped by the VMM and executed interpretively, using the virtual system state indicator to determine the appropriate action in each case.

1.3.2

Memory Mapping

Early virtual machine monitors also mapped the main memory addresses generated by processes running on virtual machines. This was necessary because each virtual machine running under a VMM normally has an address space consisting of a single linear sequence that begins at zero. Since physical memory contains only one true zero and one linear addressing sequence, some form of address mapping is required in order to run several virtual machines at the same time. Another reason for address mapping is that certain locations in main memory are normally used by the hardware to determine where to transfer control when an interrupt is received. Since most processors automatically enter privileged mode following an interrupt generated transfer of control, it is necessary to prevent a process executing on a virtual machine from obtaining access to these locations. By mapping these special locations in virtual address space into ordinary locations in real memory, the VMM can retain complete control over the actual locations used by the hardware and thus safeguard the integrity of the entire system.

1.3.3

I/O Mapping

The nal problem which early VMMs had to resolve was the mapping of I/O operations. As in the case of main memory addresses, there are a number of reasons why I/O operations have to be mapped. The primary reason is that the only addresses which appear in programs running on virtual machines are virtual (mapped) addresses. However, existing I/O channels require absolute (real) addresses for proper operation since timing considerations make it extremely dicult for channels to dynamically look up addresses in page tables as central processors do. Thus all channel programs created within

CHAPTER 1. INTRODUCTION

a particular virtual machine must have their addresses "absolutized" before they can be executed. The VMM performs this mapping function by trapping the instruction which initiates channel program execution, copying the channel program into a private work area, absolutizing the addresses in the copied program, and then initiating the absolutized copy. When the channel program terminates, the VMM again gains control since all special memory locations which govern interrupt generated transfers are maintained by the VMM. After receiving the interrupt, the VMM transfers control to the address which appears in the corresponding interrupt dispatching location of the appropriate virtual machines memory. Thus I/O completion interrupts are "reected back" to the virtual machine in the same manner that out-of-bounds memory exceptions are[2].

Chapter 2 VIRTUALIZATION
2.1 Introduction To Virtualization

In 1998, VMware gured out how to virtualize the x86 platform, once thought to be impossible, and created the market for x86 virtualization. The solution was a combination of binary translation and direct execution on the processor that allowed multiple guest OSes to run in full isolation on the same computer with readily aordable virtualization overhead. While hardware assist is a valuable technique that will mature and expand the envelope of workloads that can be virtualized, paravirtualization is not an new technology that oers an order of magnitude greater performance. Figure 2.1 provides a summary timeline of x86 virtualization technologies from VMwares binary translation to the recent application of kernel paravirtualization and hardware-assisted virtualization.

Figure 2.1: Summary Timeline of x86 Virtualization Technologies[4] 8

CHAPTER 2. VIRTUALIZATION

Figure 2.2: x86 Virtualization Layer[4] The term virtualization broadly describes the separation of a service request from the underlying physical delivery of that service. With x86 computer virtualization, a virtualization layer is added between the hardware and the operation system as shown in gure 2.2. This virtualization layer allows multiple operation system instances to run concurrently within VM on a single computer, dynamically partitioning and sharing the available physical resources such as CPU, storage, memory and I/O devices. As desktop and server processing capacity has consistently increased year after year, virtualization has proved to be a powerful technology to simplify software development and testing, to enable server consolidation, and to enhance data center agility and business continuity. Virtualization approaches use either a hosted or a hypervisor architecture. A hosted architecture installs and runs the virtualization layer as an application on top of an operating system and supports the broadest range of hardware congurations. In contrast, a hypervisor (bare-metal) architecture installs the virtualization layer directly on a clean x86-based system. Since it has direct access to the hardware resources rather than going through an operating system, a hypervisor is more ecient than a hosted architecture and

CHAPTER 2. VIRTUALIZATION

10

Figure 2.3: Hypervisior manages Virtual Machine Monitors that host Virtual Machines[4] delivers greater scalability, robustness and performance. VMware Player, ACE, Workstation and Server employ a hosted architecture for exibility, while ESX Server employs a hypervisor architecture on certied hardware for data center class performance. As depicted in Figure 2.3, the virtualization layer is a hypervisor running directly on the hardware. The functionality of the hypervisor varies greatly based on architecture and implementation. Each VMM running on the hypervisor implements the virtual machine hardware abstraction and is responsible for running a guest OS. Each VMM has to partition and share the CPU, memory and I/O devices to successfully virtualize the system.

2.2

Virtualization Techniques

As claried below, three alternative techniques now exist for handling sensitive and privileged instructions to virtualize the CPU on the x86 architecture: 1. Full virtualization using binary translation 2. OS assisted virtualization or paravirtualization 3. Hardware assisted virtualization (rst generation)

CHAPTER 2. VIRTUALIZATION

11

Figure 2.4: The binary translation approach to x86 virtualization[4]

2.2.1

Full virtualization using binary translation

VMware can virtualize any x86 operating system using a combination of binary translation and direct execution techniques. This approach, depicted in Figure 2.4, translates kernel code to replace nonvirtualizable instructions with new sequences of instructions that have the intended eect on the virtual hardware. Meanwhile, user level code is directly executed on the processor for high performance virtualization. This combination of binary translation and direct execution provides Full Virtualization as the guest OS is fully abstracted (completely decoupled) from the underlying hardware by the virtualization layer. The guest OS is not aware it is being virtualized and requires no modication. Full virtualization is the only option that requires no hardware assist or operating system assist to virtualize sensitive and privileged instructions. Full virtualization oers the best isolation and security for virtual machines, and simplies migration and portability as the same guest OS instance can run virtualized or on native hardware. VMwares virtualization products and Microsoft Virtual Server are examples of full virtualization.

CHAPTER 2. VIRTUALIZATION

12

Figure 2.5: The Paravirtualization approach to x86 Virtualization[4]

2.2.2

OS Assisted Virtualization or Paravirtualization

Paravirtualization refers to communication between the guest OS and the hypervisor to improve performance and eciency. Paravirtualization, as shown in Figure 2.5, involves modifying the OS kernel to replace nonvirtualizable instructions with hypercalls that communicate directly with the virtualization layer hypervisor. The hypervisor also provides hypercall interfaces for other critical kernel operations such as memory management, interrupt handling and time keeping. Paravirtualization is dierent from full virtualization, where the unmodied OS does not know it is virtualized and sensitive OS calls are trapped using binary translation. The value proposition of paravirtualization is in lower virtualization overhead, but the performance advantage of paravirtualization over full virtualization can vary greatly depending on the workload. As paravirtualization cannot support unmodied operating systems (e.g. Windows 2000/XP), its compatibility and portability is poor. Paravirtualization can also introduce signicant support and maintainability issues in production environments as it requires deep OS kernel modications. The open source Xen project is an example of paravirtualization that virtualizes the processor and memory using a modied Linux kernel and virtualizes the I/O using custom guest OS device drivers.

CHAPTER 2. VIRTUALIZATION

13

While it is very dicult to build the more sophisticated binary translation support necessary for full virtualization, modifying the guest OS to enable paravirtualization is relatively easy. VMware has used certain aspects of paravirtualization techniques across the VMware product line for years in the form of VMware tools and optimized virtual device drivers. The VMware tools service provides a backdoor to the VMM Hypervisor used for services such as time synchronization, logging and guest shutdown. VMware is helping develop paravirtualized versions of Linux to support proofs of concept and product development.

2.2.3

Hardware Assisted Virtualization

Hardware vendors are rapidly embracing virtualization and developing new features to simplify virtualization techniques. First generation enhancements include Intel Virtualization Technology (VT-x) and AMDs AMD-V which both target privileged instructions with a new CPU execution mode feature that allows the VMM to run in a new root mode below ring 0. As depicted in Figure 2.6, privileged and sensitive calls are set to automatically trap to the hypervisor, removing the need for either binary translation or paravirtualization. The guest state is stored in Virtual Machine Control Structures (VT-x) or Virtual Machine Control Blocks (AMD-V). Processors with Intel VT and AMD-V became available in 2006, so only newer systems contain these hardware assist features. Due to high hypervisor to guest transition overhead and a rigid programming model, VMwares binary translation approach currently outperforms rst generation hardware assist implementations in most circumstances. The rigid programming model in the rst generation implementation leaves little room for software exibility in managing either the frequency or the cost of hypervisor to guest transitions1. Because of this, VMware only takes advantage of these rst generation hardware features in limited cases such as for 64-bit guest support on Intel processors.

2.3

Summarizing the current State of x86 Virtualization techniques

VMware is currently utilizing all of these x86 virtualization techniques either in production or in the development lab to deliver the best balance between performance and functionality. With the overview of virtualization

CHAPTER 2. VIRTUALIZATION

14

Figure 2.6: The hardware assist approach to x86 virtualization[4]

CHAPTER 2. VIRTUALIZATION

15

Full Virtualization with Binary Translation Technique Binary Translation and Direct Execution Guest Modication / Compatibility Unmodied Guest OS Excellent compatibility Performance Good Fair Curre Used By VMware, Microsoft, Parallels Guest OS Hypervisor Independent? Yes Figure 2.7: techniques[4] Summary comparison of x86 processor virtualization

techniques covered, the summary comparison in Figure 2.7 is useful for understanding the high-level strengths and weaknesses of each technique. Full Virtualization with Binary Translation Hardware Assisted Virtualization OS Assisted Virtualization / Paravirtualization Technique Binary Translation and Direct Execution Exit to Root Mode on Privileged Instructions Hypercalls Guest Modication / Compatibility Unmodied Guest OS Excellent compatibility Unmodied Guest OS Excellent compatibility Guest OS codied to issue Hypercalls so it cant run on Native Hardware or other Hypervisors Poor compatibility; Not available on Windows OSes Performance Good Fair Current performance lags Binary Translation virtualization on various workloads but will improve over time Better in certain cases Used By VMware, Microsoft, Parallels VMware, Microsoft, Parallels, Xen VMware, Xen Guest OS Hypervisor Independent? Yes Yes XenLinux runs only on Xen Hypervisor VMI-Linux is Hypervisor agnostic[4].

Chapter 3 VIRTUAL MACHINES

3.1 Denation

A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. Virtual machines are separated into two major categories, based on their use and degree of correspondence to any real machine. A system virtual machine provides a complete system platform which supports the execution of a complete operating system (OS). In contrast, a process virtual machine is designed to run a single program, which means that it supports a single process[5]. An essential characteristic of a virtual machine is that the software running inside is limited to the resources and abstractions provided by the virtual machineit cannot break out of its virtual world. A virtual machine can support individual processes or a complete system depending on the abstraction level where virtualization occurs. Some VMs support exible hardware usage and software isolation, while others translate from one instruction set to another. A virtual machine was originally dened by Popek and Goldberg as "an ecient, isolated duplicate of a real machine". Current use includes virtual machines which have no direct correspondence to any real hardware.

3.1.1

Architectured Interfaces

A discussion of VMs is also a discussion about computer architecture in the pure sense of the term. Because VM implementations lie at architected

16

CHAPTER 3. VIRTUAL MACHINES

17

Figure 3.1: Computer system architecture[1] Key implementation layers communicate vertically via the instruction set architecture (ISA), application binary interface(ABI), and application programming interface (API). interfaces, a major consideration in the construction of a VM is the delity with which it implements these interfaces. Architecture, as applied to computer systems, refers to a formal specication of an interface in the system, including the logical behavior of resources managed via the interface. Implementation describes the actual embodiment of an architecture. Abstraction levels correspond to implementation layers, whether in hardware or software, each associated with its own interface or architecture. Figure 3.1 shows some important interfaces and implementation layers in a typical computer system. Three of these interfaces at or near the HW/SW boundarythe instruction set architecture, the application binary interface, and the application programming interfaceare especially important for VM construction. Figure 3.1 - Computer system architecture. Key implementation layers communicate vertically via the instruction set architecture (ISA), application

CHAPTER 3. VIRTUAL MACHINES binary interface(ABI), and application programming interface (API). 3.1.1.1 Instruction set architecture

18

The ISA marks the division between hardware and software, and consists of interfaces 3 and 4 in Figure 3.1. Interface 4 represents the user ISA and includes those aspects visible to an application program. Interface 3, the system ISA, is a superset of the user ISA and includes those aspects visible only to operating system software responsible for managing hardware resources. 3.1.1.2 Application binary interface

The ABI gives a program access to the hardware resources and services available in a system through the user ISA (interface 4) and the system call interface (interface 2). The ABI does not include system instructions; rather, all application programs interact with the hardware resources indirectly by invoking the operating systems services via the system call interface. System calls provide a way for an operating system to perform operations on behalf of a user program after validating their authenticity and safety. 3.1.1.3 Application programming interface

The API gives a program access to the hardware resources and services available in a system through the user ISA(interface 4) supplemented with highlevel language (HLL) library calls (interface 1). Any system calls are usually performed through libraries. Using an API enables application software to be ported easily, through recompilation, to other systems that support the same API.

3.2

Types of Virtual Machines

To understand what a virtual machine is, it is rst necessary to consider the meaning of machine from both a process and system perspective. From the perspective of a process executing a user program, the machine consists of a logical memory address space assigned to the process along with userlevel instructions and registers that allow the execution of code belonging to the process. The machines I/O is visible only through the operating

CHAPTER 3. VIRTUAL MACHINES

19

system, and the only way the process can interact with the I/O system is through operating system calls. Thus the ABI denes the machine as seen by a process. Similarly, the API species the machine characteristics as seen by an applications HLL program. From the perspective of the operating system and the applications it supports, the entire system runs on an underlying machine. A system is a full execution environment that can support numerous processes simultaneously. These processes share a le system and other I/O resources. The system environment persists over time as processes come and go. The system allocates real memory and I/O resources to the processes, and allows the processes to interact with their resources. From the system perspective, therefore, the underlying hardwares characteristics alone dene the machine; it is the ISA that provides the interface between the system and machine. The process or system that runs on a VM is the guest, while the underlying platform that supports the VM is the host. The virtualizing software that implements a process VM is often termed the runtime, short for runtime software. The virtualizing software in a system VM is typically referred to as the virtual machine monitor (VMM)

3.2.1

System Virtual Machines

System virtual machines (sometimes called hardware virtual machines) allow the sharing of the underlying physical machine resources between dierent virtual machines, each running its own operating system. The software layer providing the virtualization is called a virtual machine monitor(VMM) or hypervisor. System VMs emerged during the 1960s and early 1970s and were the origin of the term virtual machine. At that time, mainframe computer systems were very large, expensive, and usually shared among numerous users; with VM technology, dierent user groups could run dierent operating systems on the shared hardware. As hardware became less expensive and much of it migrated to the desktop, interest in these original system VMs faded. Today, however, system VMs are enjoying renewed popularity as the large mainframe systems of the past have been replaced by servers or server farms shared by many users or groups. Perhaps the most important current application of system VM technology is the isolation it provides between multiple systems running concurrently on the same hardware platform. If security on one guest system is compromised

CHAPTER 3. VIRTUAL MACHINES

20

Figure 3.2: System Virtual Machine[1] Virtualizing software translates the ISA used by one hardware platform to that of another or if one guest operating system suers a failure, the software running on other guest systems is not aected. The VMM has access to, and manages, all the hardware resources. A guest operating system and its application processes are then managed under (hidden) control of the VMM. When a guest operating system performs a privileged instruction or operation that directly interacts with shared hardware resources, the VMM intercepts the operation, checks it for correctness, and performs it on behalf of the guest. Guest software is unaware of this behind-the-scenes work.

3.2.2

Process Virtual Machines

Process VMs provide a virtual ABI or API environment for user applications. In their various implementations, process VMs oer replication, emulation, and optimization. The most common process VM is so ubiquitous that few regard it as being a VM. Most operating systems can simultaneously support multiple user processes through multiprogramming, which gives each process the illusion of having a complete machine to itself. Each process has its own address space, registers, and le structure. The operating system time-shares the hardware and manages underlying resources to make this possible. In eect, the operating system provides a replicated process-level VM for each of the concurrently executing applications[1].

CHAPTER 3. VIRTUAL MACHINES

21

Figure 3.3: Process Virtual Machine[4] virtualizing software translates a set of OS and user-level instructions composing one platform to those of another

3.3

Virtual Machine Monitors

A virtual machine monitor (VMM) is a thin layer of software that runs directly on the hardware of a machine. The VMM exports a virtual machine abstraction (VM) that resembles the underlying hardware. This abstraction models the hardware closely enough that software which would run on the underlying hardware can also be run in a virtual machine. VMMs virtualize all hardware resources, allowing multiple virtual machines to transparently multiplex the resources of the physical machine. The operating system running inside of a VM is traditionally referred to as the guest OS, and applications running on the guest OS are similarly referred to as guest applications. Traditionally, the VMM is the only privileged code running on the system. It is essentially a small operating system. This style of VMM has been a standard part of mainframe computers for 30 years, and recently has found its way onto commodity x86 PCs. Hosted VMMs like VMware have emerged that run a VMM concurrently with a commodity host OS such as Windows or Linux. In this setting, the virtual machine appears as simply another program running on the host operating system. Despite a radical dierence from the users perspective, traditional and hosted VMMs dier little in implementation. In a hosted architecture the VMM merely leverages a third-party host OS to provide drivers, bootstrapping code, and other functionality common to VMMs and traditional operating systems, instead of being forced to implement all of its functionality from scratch. VMMs have traditionally been used for logical server partitioning, and

CHAPTER 3. VIRTUAL MACHINES

22

are supported for a wide range of architectures; for example, the IBM xSeries (x86 servers), pSeries (Unix), zSeries (mainframes), and iSeries (AS/400) all have VMMs available. Recently, as hosted VMMs have appeared on the desktop, they have begun to nd other applications such as cross-platform development and testing.

3.3.1

VMM Implementation

Although the specics of a VMMs implementation are architecture-dependent, VMMs tend to rely on similar implementation techniques. Among these techniques is conguring the real machine so that virtual machines can safely and directly execute using the machines CPU and memory. By doing this, VMMs can eciently run software in the virtual machines at speeds close to that achieved by running them on the bare hardware. VMMs can also fully isolate the software running in a virtual machine from other virtual machines, and from the virtual machine monitor. A common way to virtualize the CPU is to run the VMM in the most privileged mode of the processor, while running virtual machines in less privileged modes. All traps and interrupts that occur while a virtual machine is running transfer control to the VMM. Attempts by the virtual machines to access privileged operations trap into the VMM; the VMM emulates privileged operations for the VM. In this architecture, the VMM can always control the virtual machine regardless of what the software in the virtual machine does. Memory is commonly virtualized by keeping a virtual MMU for each virtual machine that reects the VMs view of its address space. The VMM retains control of the real MMU, and maps each VMs physical memory in such a way that VMs do not share physical memory with each other, or with the VMM. Through this technique the VMM is able to create the illusion that each VM has its own address space that it fully controls. This also allows the VMM to isolate the VMs from one another and prevents them from accessing the memory of the VMM. In addition to virtualizing the CPU and memory, the VMM intercepts all input/output requests from VMs to virtual devices and maps them to the correct physical I/O device. For memory-mapped I/O, the VMM only allows a virtual machine to see and access the particular I/O devices it is permitted to use[3].

Chapter 4 OPEN ISSUES

4.1 Introduction

Virtualization - A technology that has an enormous eect in todays IT world. It is a technique that divides a physical computer into several partly or completely isolated machines commonly known as virtual machines (VM) or guest machines. Multiple of these virtual machines can run on a host computer, each possessing its own operating system and applications. This gives an illusion to the processes on these virtual machines as if they are running on a physical computer, but in reality they are sharing the physical hardware of the host machine. The software that allows multiple operating systems to use the hardware of the physical machine is called a hypervisor or a control program. Hypervisors sit between the operating system of the host machine and the virtual environment. There are various virtualization technologies available in the market, having their own merits and demerits. In non-virtual environment, the applications running on the machine can see each other, and in some cases can even communicate with each other, whereas in virtual environment the programs running in one guest machine are isolated from the programs running in another guest machine, in other words guest machines "provide what appear to be independent coexisting computers" to their running programs. The degree of isolation should be strong enough that the vulnerabilities in one virtual machine should not aect either the virtual machines or the underlying host machine. The computer that is being virtualized is of no dierence from the computer that is not virtualized. The virtualized environment is vulnerable to

23

CHAPTER 4. OPEN ISSUES

24

all the traditional attacks and exploits that are common to the normal environment. The case is even worse in the virtualized environment, where there are several virtual computers running. The security expectations are higher in here because "there are more systems to protect", more possible points of entry, more holes to patch and there are more interconnection points in the virtualized environment. Attackers and Hackers are already been actively developing new malware programs for virtual machine environment. "Root kit infections, malware that detects a virtual environment and modies itself accordingly" are some of them. "Low-level hypervisor attacks, and deployment of malicious virtual systems" are few possible attacks that are unique to this environment. On the other hand new security protection programs are also emerging in the market every now and then from dierent vendors, but most of these security solutions are mainly focused on hypervisor. Since hypervisor is a new layer between the hosts OS and virtual environment, it creates new opportunities for the malicious programs. And more over, hypervisor is basically a software program, so it has all the traditional software bugs and the security vulnerabilities as any software have. One of such product that hits the market recently is SHype, a new secure hypervisor that binds security policies to the virtual environment. However, virtual machine security is more than just deploying a secure hypervisor to the environment. Virtualization technologies are still evolving. Newer versions with added features are introduced before the security consequences of the older version has been fully studied. This work analyzes the general security threats in a virtual environment and suggests possible solutions for few of the mentioned threats.

4.2

Primary Benets

It is worth mentioning some of the security benets that comes together with virtualization. Two primary benets oered by any virtualization technology are : 1. Resource Sharing 2. Isolation In Resource Sharing unlike in non-virtualized environment where all the resources are dedicated to the running programs, in virtualized environment

CHAPTER 4. OPEN ISSUES

25

the VMs shares the physical resources such as memory, disk and network devices of the underlying host. The resources are allocated to the virtual machine on request. Hypervisors plays a signicant role in resource allocation.In Isolation one of the key issue in virtualization, provides isolation between virtual machines that are running on the same physical hardware. Programs running in one virtual machine cannot see programs running in another virtual machine. This is contrast to non-virtual environment where the running programs can see each other and if allowed can communicate with each other. Virtualization provides a facility of restoring a clean non infected environment even the underlying system is infected by malicious programs. Since, Virtualization provides an isolated environment this can be used for debugging malicious programs and also to test new applications.

4.3

Security Vulnerabilities in Virtualization

Most of security aws identied in a virtual machine environment are very similar to the security aws assoicated with any physical system. The following are some general aws that are unique to the virtual environment.

4.3.1

Communication between VMs or Between VMs and host

One of the primary benets that virtualization bring is isolation. This benet, if not carefully deployed become a threat to the environment. Isolation should be carefully congured and maintained in a virtual environment to ensure that the applications running in one VM dont have access to the applications running in another VM. Isolation should be strongly maintained that break-in into one virtual machine should not provide access either to virtual machines in the same environment or to the underlying host machine. Shared clipboard in virtual machine is a useful feature that allows data to be transferred between VMs and the host. But this useful feature can also be treated as a gateway for transferring data between cooperating malicious program in VMs. In worst case, it is used to "exltrate data to/from the host operating system". Some virtualization avoids isolation, in order to support applications designed for one operating system to be operated on another operating system,

CHAPTER 4. OPEN ISSUES

26

this solution completely exploits the security bearers in both the operating systems. This kind of system, where there is no isolation between the host and the VMs gives the virtual machines an unlimited access to the hosts resources, such as le system and networking devices. In which case the hosts le system becomes vulnerable.

4.3.2

VM Escape

Virtual machines are allowed to share the resources of the host machine but still can provide isolation between VMs and between the VMs and the host. That is, the virtual machines are designed in a way that a program running in one virtual machine cannot monitor, or communicate either with programs running in other VMs or with the programs running in the host. But in reality the organizations compromise isolation. They congure exible isolation to meet their organization needs which exploits the security of the systems. One such example of this kind of attack is VM escape. VM escape is one of the worst case happens if the isolation between the host and between the VMs is compromised. In VM escape, the program running in a virtual machine is able to completely bypass the virtual layer (hypervisor layer), and get access to the host machine. Since the host machine is the root, the program which gain access to the host machine also gains the root privileges basically escapes from the virtual machine privileges. This result in complete break down in the security framework of the environment. SOLUTION - This problem can be solved by properly conguring the host/guest interaction.

4.3.3

VM monitoring from the host

Host machine in the virtual environment is considered to be the control point and there are implications that enable the host to monitors and communicate with the VM applications up running. Therefore it is more necessary to strictly protect the host machines than protecting distinctive VMs. Dierent virtualization technologies have dierent implications for the host machine to inuence the VMs up running in the system. Following are the possible ways for the host to inuence the VMs : 1. The host can start, shutdown, pause and restart the VMs.

CHAPTER 4. OPEN ISSUES

27

2. The host can able to monitor and modify the resources available for the virtual machines. 3. The host if given enough rights can monitor the applications running inside the VMs. 4. The host can view, copy, and likely to modify the data stored in the virtual disks assigned to the VMs And particularly, in general all the network trac to/from the VMs pass through the host, this enables the host to monitor all the network trac for all its VMs. In which case if a host is compromised then the security of the VMs is under question. Basically in all virtualization technologies, the host machines are given some sort of basic rights to control some actions such as resource allocations of the VMs running on top. But care should be taken when conguring the VM environment so that enough isolation should be provided which avoids the host being a gateway for attacking the virtual machine.

4.3.4

VM monitoring from another VM

Isolation plays a vital role in virtualization. It is considered as a threat when one VM without any dicult may be allowed to monitor resources of another VM. Thanks to todays modern CPUs, which comes with a built in memory protection feature. The hypervisor who is responsible for memory isolation can make use of this feature; this memory protection feature prevents one VM seeing the other VMs memory resources. And more over the VMs does not have the possibility to directly access the le system of the host machine, so its impossible for a VM to access the virtual disk allocated to another VM on the host. When comes to the network trac, isolation completely depends on the connection (network) setup of the virtualized environment. If the host machine is connected to the guest machine by means of physical dedicated channel, then its unlikely that the guest machine can sni packets to the host and vice versa. However in reality the VMs are linked to the host machine by means "virtual hub" or by a virtual switch. In which case, it enables the guest machines to sni packets in the network or even worse that the guest machines can use ARP poisoning to redirect the packets going to and coming from another guest.

CHAPTER 4. OPEN ISSUES

28

SOLUTION - Authenticating the network trac could be a solution the problem described above.

4.3.5

Denial of Service

In virtual machine architecture the guest machines and the underlying host share the physical resources such as CPU, memory disk, and network resource. So it is possible for a guest to impose a denial of service attack to other guests residing in the same system. Denial of service attack in virtual environment can be described as an attack when a guest machine takes all the possible resources of the system. Hence, the system denies the service to other guests that are making request for resources, this is because there is no resource available for other guests. SOLUTION - The best approach to prevent a guest consuming all the resources is to limit the resources allocated to the guests. Current virtualization technologies oer a mechanism to limit the resources allocated to each guest machines in the environment. Therefore the underlying virtualization technology should be properly congured, which can then prevent one guest consuming all the available resources, there by preventing the denial of service attack.

4.3.6

Guest-to-Guest attack

As we know that it is important to prevent the host machine than the individual VMs. If an attacker gains the administrator privileges of the hardware then its likely that the attacker can break-in into the virtual machines. It is termed as guest-to-guest attack because the attacker can able to hop from one virtual machine to another virtual machine provided that the underlying security framework is already broken.

4.3.7

External Modication of a VM

There are some sensitive applications exists which rely on the infrastructure of the VM environment. These applications running inside a virtual machine requires the virtual machine to be a trusted environment to execute that application. If a VM is modied for some reason, the applications can still be able to run on the VM but the trust is broken.

CHAPTER 4. OPEN ISSUES

29

SOLUTION - A best solution for this problem is to digitally sign the VM and validating the signature prior to the execution of this sensitive applications.

4.3.8

External modication of the hypervisor

As we know that hypervisor is responsible for providing isolation between the guest machines. The VMs are said to be completely isolated or "self protected" only if the underlying hypervisor behaves well. A badly behaved hypervsior will break the security model of the system. SOLUTION - There are several solutions exists for this problem, one of the recommended solution is to use secure hypervisor like SHype to ensure security in the hypervisor layer. Another solution is to protect the hypervisor from unauthorized modications or enable the guest machines to validate the hypervisor[6].

Chapter 5 CONCLUSION
The report has presented some of the security aws in the virtual machine environment. Some of the threats presented here may be considered as benets in some situations, but they are presented here so that proper care should be taken while designing and implementing the virtual environment. Virtualization brings very little added security to the environment. One of the key issue is that everyone should be aware of the fact that virtual machines represent the logical instance of an underlying system. So many of the traditional computer threats apply the same to the virtual machines also. Another issue that makes the security consequences dicult to understand is that, there are so many dierent types of virtualization technologies available in the market. Each of it has it own merits and demerits, each virtualization deployment is dierent depending on the need for the virtualization. It is common that any single virtualization technology will not provide shield to all the security issues arise. However, the key to create a good virtualization environment is to study carefully the environment that is to be virtualized, the needs and goals of the organization, and taking into consideration all the possible security issues that puts the virtual machines at risk. Finally carefully design the virtual environment with the help of correct virtualization technology that matches the goals. Majority of the security issues presented here concerns the security of the host and the hypervisor. If the host or the hypervisor is compromised then the whole security model is broken. Attacks against the hypervisor becoming more popular among the attackers realm. Therefore after setting up the environment, care should be taken to ensure that the hypervisor is secure enough to the newly emerging threats, if not patches has to be 30

CHAPTER 5. CONCLUSION

31

done. Patches should be done frequently so that the risk of hypervisor being compromised will be avoided. Virtualization is a powerful solution to reduce the operational costs in todays computing but if done wrong it become as a threat to the environment. While implementing, exaggerate the security model to with stand the attacks. And as mentioned earlier keep monitoring for new developments that emerges in this eld and continue to stay up to date[6].

Bibliography
[1] James E. Smith, Ravi Nair.- The Architecture Of Virtual Machines published by IEEE Computer Society in 2005. [2] J. P. Buzen and U. O. Gagliardi - The Evolution of Virtual Machine Architecture.pdf. [3] Tal Garnkel, Mendel Rosenblum - A Virtual Machine Introspection Based Architecture for Intrusion Detection from Computer Science Department,Standford University published in 2003. [4] Understanding Full Virtualization, Paravirtualization, and Hardware Assist published by White Paper in the year 2007 [5] http://www.wikipedia/virtual machine. [6] A Survey On Virtual Macchine Security by Jenni Susan Reuben.

32