virtual machine architecture

8/2/2019 Virtual Machine Architecture

1/35

VIRTUAL MACHINE ARCHITECTURE

Author : Prakhar Sharma

April 4, 2011


2/35

Contents

1 INTRODUCTION 21.1 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Virtual Machine Concept . . . . . . . . . . . . . . . . . . . . . 21.3 Early Virtual Machines . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Processor State Mapping . . . . . . . . . . . . . . . . . 51.3.2 Memory Mapping . . . . . . . . . . . . . . . . . . . . . 61.3.3 I/O Mapping . . . . . . . . . . . . . . . . . . . . . . . 6

2 VIRTUALIZATION 82.1 Introduction To Virtualization . . . . . . . . . . . . . . . . . . 82.2 Virtualization Techniques . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Full virtualization using binary translation . . . . . . . 112.2.2 OS Assisted Virtualization or Paravirtualization . . . . 12

2.2.3 Hardware Assisted Virtualization . . . . . . . . . . . . 132.3 Summarizing the current State of x86 Virtualization techniques 13

3 VIRTUAL MACHINES 163.1 Defination . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Architectured Interfaces . . . . . . . . . . . . . . . . . 163.2 Types of Virtual Machines . . . . . . . . . . . . . . . . . . . 18

3.2.1 System Virtual Machines . . . . . . . . . . . . . . . . . 193.2.2 Process Virtual Machines . . . . . . . . . . . . . . . . 20

3.3 Virtual Machine Monitors . . . . . . . . . . . . . . . . . . . . 213.3.1 VMM Implementation . . . . . . . . . . . . . . . . . . 22

4 OPEN ISSUES 234.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Primary Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 24

i


3/35

CONTENTS ii

4.3 Security Vulnerabilities in Virtualization . . . . . . . . . . . . 25

4.3.1 Communication between VMs or Between VMs and host 254.3.2 VM Escape . . . . . . . . . . . . . . . . . . . . . . . . 264.3.3 VM monitoring from the host . . . . . . . . . . . . . . 264.3.4 VM monitoring from another VM . . . . . . . . . . . . 274.3.5 Denial of Service . . . . . . . . . . . . . . . . . . . . . 284.3.6 Guest-to-Guest attack . . . . . . . . . . . . . . . . . . 284.3.7 External Modification of a VM . . . . . . . . . . . . . 284.3.8 External modification of the hypervisor . . . . . . . . . 29

5 CONCLUSION 30


4/35

List of Figures

1.1 Conventional extended machine organization[2] . . . . . . . . 31.2 Virtual Machine Organisation[2] . . . . . . . . . . . . . . . . . 4

2.1 Summary Timeline of x86 Virtualization Technologies[4] . . . 82.2 x86 Virtualization Layer[4] . . . . . . . . . . . . . . . . . . . . 92.3 Hypervisior manages Virtual Machine Monitors that host Vir-

tual Machines[4] . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 The binary translation approach to x86 virtualization[4] . . . . 112.5 The Paravirtualization approach to x86 Virtualization[4] . . . 122.6 The hardware assist approach to x86 virtualization[4] . . . . . 142.7 Summary comparison of x86 processor virtualization techniques[4] 15

3.1 Computer system architecture[1] . . . . . . . . . . . . . . . . . 17

3.2 System Virtual Machine[1] . . . . . . . . . . . . . . . . . . . . 203.3 Process Virtual Machine[4] . . . . . . . . . . . . . . . . . . . . 21

1


5/35

Chapter 1

INTRODUCTION

1.1 Evolution

In the early 1960s two major evolutionary steps were taken with regard tocomputing systems architecture. These were the emergence of I/O proces-sors and the use of multiprogramming to improve resource utilization andoverall performance. As a consequence of the first step computing systemsbecame multiprocessor configurations where nonidentical processors couldhave access to the common main memory of the system. The second stepresulted in several computational processes sharing a single processor on atime-multiplexed basis while vying for a common pool of resources.

Both these developments introduced very serious potential problems forsystem integrity. An I/O processor executing an "incorrect" channel programcould alter areas of main memory that belonged to other computations or tothe nucleus of the software system. A computational process executing an"incorrect" procedure could cause similar problems to arise. Since abundantexperience had demonstrated that it was not possible to rely on the "correct-ness" of all software, the multi-processing/multiprogramming architecturesof the third generation had to rely on a completely new approach.

1.2 Virtual Machine ConceptFigure 1.1 illustrates the conventional dual state extended machine architec-ture which is responsible for all the difficulties that were cited in the preced-ing section. As can be seen in the Figure1.1, the crux of the problem is that

2


6/35

CHAPTER 1. INTRODUCTION 3

Figure 1.1: Conventional extended machine organization[2]

conventional systems contain only one basic machine interface and thus areonly 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 cansupport several extended machine interfaces. If it were possible to constructa privileged software nucleus which supported several copies of the basic ma-chine interface rather than the extended machine interface, then a differentprivileged software nucleus could be run on each of the additional basic ma-chine interfaces and the problems mentioned in the proceding section couldbe eliminated.

A basic machine interface which is not supported directly on a bare ma-chine but is instead supported in a manner similar to an extended machineinterface is known as a virtual machine. As illustrated in Figure 1.2, theprogram which supports the additional basic machine interfaces is known as

a virtual machine monitor or VMM. Since a basic machine interface sup-ported by a VMM is functionally identical to the basic machine interface ofthe corresponding real machine, any privileged software nucleus which runson the bare machine will run on the virtual machine as well. Furthermore, a


7/35


Figure 1.2: Virtual Machine Organisation[2]


8/35


privileged software nucleus will have no way of determining whether it is run-

ning on a bare machine or on a virtual machine. Thus a virtual machine is,in a very fundamental sense, equivalent to and functionally indistinguishablefrom its real machine counterpart.

In practice no virtual machine is completely equivalent to its real machinecounterpart. For example, when several virtual machines share a single pro-cessor on a time multiplexed basis, the time dependent characteristics of thevirtual and real machine are likely to differ significantly. The overhead cre-ated by the VMM is also apt to cause timing differences. A more significantfactor is that virtual machines sometimes lack certain minor functional ca-pabilities of their real machine counterparts such as the ability to executeself-modifying channel programs. Thus the characterization of virtual ma-

chines presented in the preceding paragraph must be slightly modified inmany cases to encompass all entities which are conventionally referred to asvirtual machines.

1.3 Early Virtual Machines

Virtual machine monitors for computers with dual state architecture firstappeared in the mid 1960s. Early VMMs12,13 were most noteworthy for themanner in which they controlled the processor state, main memory and I/Ooperations of the virtual machines which ran under their control. This section

presents a brief description and analysis of the special mapping techniquesthat were employed in these early systems.

1.3.1 Processor State Mapping

The mapping of processor state was probably the most unusual feature ofearly virtual machine monitors. If a VMM did not maintain proper controlover the actual state of the processor, a privileged software nucleus execut-ing on a virtual machine could conceivably enter privileged mode and gainunrestricted access to the entire system. It would then be able to interfereat will with the VMM itself or with any other virtual machine present in thesystem. Since this is obviously an unacceptable situation, some mapping ofvirtual processor state to actual processor state was required.

The solution that was adopted involved running all virtual machine pro-cesses in the non-privileged state and having the virtual machine monitor


9/35


maintain a virtual state indicator which was set to either privileged or non-

privileged mode, depending on the state the process would be in if it wereexecuting directly on the bare machine. Instructions which were insensitiveto the actual state of the machine were then allowed to execute directly onthe bare machine with no intervention on the part of the VMM. All other in-structions were trapped by the VMM and executed interpretively, using thevirtual system state indicator to determine the appropriate action in eachcase.

1.3.2 Memory Mapping

Early virtual machine monitors also mapped the main memory addresses

generated by processes running on virtual machines. This was necessarybecause each virtual machine running under a VMM normally has an addressspace consisting of a single linear sequence that begins at zero. Since physicalmemory contains only one true zero and one linear addressing sequence, someform of address mapping is required in order to run several virtual machinesat the same time.

Another reason for address mapping is that certain locations in mainmemory are normally used by the hardware to determine where to transfercontrol when an interrupt is received. Since most processors automaticallyenter privileged mode following an interrupt generated transfer of control,it is necessary to prevent a process executing on a virtual machine fromobtaining access to these locations. By mapping these special locations invirtual address space into ordinary locations in real memory, the VMM canretain complete control over the actual locations used by the hardware andthus safeguard the integrity of the entire system.

1.3.3 I/O Mapping

The final problem which early VMMs had to resolve was the mapping of I/Ooperations. As in the case of main memory addresses, there are a number ofreasons why I/O operations have to be mapped. The primary reason is that

the only addresses which appear in programs running on virtual machines arevirtual (mapped) addresses. However, existing I/O channels require absolute(real) addresses for proper operation since timing considerations make itextremely difficult for channels to dynamically look up addresses in pagetables as central processors do. Thus all channel programs created within


10/35


a particular virtual machine must have their addresses "absolutized" before

they can be executed.The VMM performs this mapping function by trapping the instructionwhich initiates channel program execution, copying the channel program intoa private work area, absolutizing the addresses in the copied program, andthen initiating the absolutized copy. When the channel program terminates,the VMM again gains control since all special memory locations which governinterrupt generated transfers are maintained by the VMM. After receivingthe interrupt, the VMM transfers control to the address which appears in thecorresponding interrupt dispatching location of the appropriate virtual ma-chines memory. Thus I/O completion interrupts are "reflected back" to thevirtual machine in the same manner that out-of-bounds memory exceptions

are[2].


11/35

Chapter 2

VIRTUALIZATION

2.1 Introduction To Virtualization

In 1998, VMware figured out how to virtualize the x86 platform, once thoughtto be impossible, and created the market for x86 virtualization. The solutionwas a combination of binary translation and direct execution on the processorthat allowed multiple guest OSes to run in full isolation on the same com-puter with readily affordable virtualization overhead. While hardware assistis a valuable technique that will mature and expand the envelope of work-loads that can be virtualized, paravirtualization is not an new technologythat offers an order of magnitude greater performance. Figure 2.1 providesa summary timeline of x86 virtualization technologies from VMwares bi-nary translation to the recent application of kernel paravirtualization andhardware-assisted virtualization.

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

8


12/35

CHAPTER 2. VIRTUALIZATION 9

Figure 2.2: x86 Virtualization Layer[4]

The term virtualization broadly describes the separation of a service re-quest from the underlying physical delivery of that service. With x86 com-puter virtualization, a virtualization layer is added between the hardware

and the operation system as shown in figure 2.2. This virtualization layerallows multiple operation system instances to run concurrently within VMon a single computer, dynamically partitioning and sharing the availablephysical resources such as CPU, storage, memory and I/O devices. As desk-top and server processing capacity has consistently increased year after year,virtualization has proved to be a powerful technology to simplify software de-velopment and testing, to enable server consolidation, and to enhance datacenter agility and business continuity.

Virtualization approaches use either a hosted or a hypervisor architec-ture. A hosted architecture installs and runs the virtualization layer as anapplication on top of an operating system and supports the broadest range ofhardware configurations. In contrast, a hypervisor (bare-metal) architectureinstalls the virtualization layer directly on a clean x86-based system. Since ithas direct access to the hardware resources rather than going through an op-erating system, a hypervisor is more efficient than a hosted architecture and


13/35


Figure 2.3: Hypervisior manages Virtual Machine Monitors that host Vir-tual Machines[4]

delivers greater scalability, robustness and performance. VMware Player,ACE, Workstation and Server employ a hosted architecture for flexibility,while ESX Server employs a hypervisor architecture on certified hardwarefor data center class performance.

As depicted in Figure 2.3, the virtualization layer is a hypervisor run-ning directly on the hardware. The functionality of the hypervisor variesgreatly based on architecture and implementation. Each VMM running onthe hypervisor implements the virtual machine hardware abstraction and isresponsible 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 clarified below, three alternative techniques now exist for handling sensi-tive 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 (first generation)


14/35


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 ofbinary translation and direct execution techniques. This approach, depictedin Figure 2.4, translates kernel code to replace nonvirtualizable instructionswith new sequences of instructions that have the intended effect on the virtualhardware. 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 notaware it is being virtualized and requires no modification. Full virtualizationis the only option that requires no hardware assist or operating system assistto virtualize sensitive and privileged instructions. Full virtualization offersthe best isolation and security for virtual machines, and simplifies migrationand portability as the same guest OS instance can run virtualized or onnative hardware. VMwares virtualization products and Microsoft VirtualServer are examples of full virtualization.


15/35


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 hy-pervisor to improve performance and efficiency. Paravirtualization, as shownin Figure 2.5, involves modifying the OS kernel to replace nonvirtualizable in-structions with hypercalls that communicate directly with the virtualization

layer hypervisor. The hypervisor also provides hypercall interfaces for othercritical kernel operations such as memory management, interrupt handlingand time keeping.

Paravirtualization is different from full virtualization, where the unmodi-fied OS does not know it is virtualized and sensitive OS calls are trapped us-ing binary translation. The value proposition of paravirtualization is in lowervirtualization overhead, but the performance advantage of paravirtualizationover full virtualization can vary greatly depending on the workload. As par-avirtualization cannot support unmodified operating systems (e.g. Windows2000/XP), its compatibility and portability is poor. Paravirtualization canalso introduce significant support and maintainability issues in production

environments as it requires deep OS kernel modifications. The open sourceXen project is an example of paravirtualization that virtualizes the proces-sor and memory using a modified Linux kernel and virtualizes the I/O usingcustom guest OS device drivers.


16/35


While it is very difficult to build the more sophisticated binary translation

support necessary for full virtualization, modifying the guest OS to enableparavirtualization is relatively easy. VMware has used certain aspects of par-avirtualization techniques across the VMware product line for years in theform of VMware tools and optimized virtual device drivers. The VMwaretools service provides a backdoor to the VMM Hypervisor used for servicessuch as time synchronization, logging and guest shutdown. VMware is help-ing develop paravirtualized versions of Linux to support proofs of conceptand product development.

2.2.3 Hardware Assisted Virtualization

Hardware vendors are rapidly embracing virtualization and developing newfeatures to simplify virtualization techniques. First generation enhancementsinclude Intel Virtualization Technology (VT-x) and AMDs AMD-V whichboth target privileged instructions with a new CPU execution mode featurethat allows the VMM to run in a new root mode below ring 0. As depicted inFigure 2.6, privileged and sensitive calls are set to automatically trap to thehypervisor, removing the need for either binary translation or paravirtualiza-tion. The guest state is stored in Virtual Machine Control Structures (VT-x)or Virtual Machine Control Blocks (AMD-V). Processors with Intel VT andAMD-V became available in 2006, so only newer systems contain these hard-ware assist features. Due to high hypervisor to guest transition overhead

and a rigid programming model, VMwares binary translation approach cur-rently outperforms first generation hardware assist implementations in mostcircumstances. The rigid programming model in the first generation imple-mentation leaves little room for software flexibility in managing either thefrequency or the cost of hypervisor to guest transitions1. Because of this,VMware only takes advantage of these first generation hardware features inlimited cases such as for 64-bit guest support on Intel processors.

2.3 Summarizing the current State of x86 Vir-

tualization techniquesVMware is currently utilizing all of these x86 virtualization techniques ei-ther in production or in the development lab to deliver the best balancebetween performance and functionality. With the overview of virtualization


17/35


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


18/35


Full Virtualization with Binary Translation

Technique Binary Translation and Direct ExecutionGuest Modification / Compatibility Unmodified Guest OS Excellent compatibilityPerformance Good Fai

Used By VMware, Microsoft, ParallelsGuest OS Hypervisor Independent? Yes

Figure 2.7: Summary comparison of x86 processor virtualizationtechniques[4]

techniques covered, the summary comparison in Figure 2.7 is useful for un-derstanding the high-level strengths and weaknesses of each technique.

Full Virtualization with Binary Translation Hardware Assisted Virtual-ization OS Assisted Virtualization / Paravirtualization Technique BinaryTranslation and Direct Execution Exit to Root Mode on Privileged Instruc-tions Hypercalls Guest Modification / Compatibility Unmodified Guest OSExcellent compatibility Unmodified Guest OS Excellent compatibility GuestOS codified to issue Hypercalls so it cant run on Native Hardware or otherHypervisors Poor compatibility; Not available on Windows OSes Perfor-mance Good Fair Current performance lags Binary Translation virtualiza-tion on various workloads but will improve over time Better in certain casesUsed By VMware, Microsoft, Parallels VMware, Microsoft, Parallels, Xen

VMware, Xen Guest OS Hypervisor Independent? Yes Yes XenLinux runsonly on Xen Hypervisor VMI-Linux is Hypervisor agnostic[4].


19/35

Chapter 3

VIRTUAL MACHINES

3.1 Defination

A virtual machine (VM) is a software implementation of a machine (i.e. acomputer) that executes programs like a physical machine. Virtual machinesare separated into two major categories, based on their use and degree ofcorrespondence to any real machine. A system virtual machine provides acomplete system platform which supports the execution of a complete oper-ating system (OS). In contrast, a process virtual machine is designed to runa single program, which means that it supports a single process[5].

An essential characteristic of a virtual machine is that the software run-ning inside is limited to the resources and abstractions provided by the virtualmachineit cannot break out of its virtual world. A virtual machine can sup-port individual processes or a complete system depending on the abstractionlevel where virtualization occurs. Some VMs support flexible hardware us-age and software isolation, while others translate from one instruction set toanother.

A virtual machine was originally defined by Popek and Goldberg as "anefficient, isolated duplicate of a real machine". Current use includes virtualmachines 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 inthe pure sense of the term. Because VM implementations lie at architected

16


20/35

CHAPTER 3. VIRTUAL MACHINES 17

Figure 3.1: Computer system architecture[1]Key implementation layers communicate vertically via the instruction setarchitecture (ISA), application binary interface(ABI), and application pro-gramming interface (API).

interfaces, a major consideration in the construction of a VM is the fidelitywith which it implements these interfaces.

Architecture, as applied to computer systems, refers to a formal specifica-tion of an interface in the system, including the logical behavior of resourcesmanaged via the interface. Implementation describes the actual embodimentof an architecture. Abstraction levels correspond to implementation layers,whether in hardware or software, each associated with its own interface orarchitecture. Figure 3.1 shows some important interfaces and implementa-tion layers in a typical computer system. Three of these interfaces at or nearthe HW/SW boundarythe instruction set architecture, the application bi-

nary interface, and the application programming interfaceare especiallyimportant for VM construction.

Figure 3.1 - Computer system architecture. Key implementation layerscommunicate vertically via the instruction set architecture (ISA), application


21/35


binary interface(ABI), and application programming interface (API).

3.1.1.1 Instruction set architecture

The ISA marks the division between hardware and software, and consistsof interfaces 3 and 4 in Figure 3.1. Interface 4 represents the user ISAand includes those aspects visible to an application program. Interface 3,the system ISA, is a superset of the user ISA and includes those aspectsvisible only to operating system software responsible for managing hardwareresources.

3.1.1.2 Application binary interface

The ABI gives a program access to the hardware resources and services avail-able in a system through the user ISA (interface 4) and the system call in-terface (interface 2). The ABI does not include system instructions; rather,all application programs interact with the hardware resources indirectly byinvoking the operating systems services via the system call interface. Systemcalls provide a way for an operating system to perform operations on behalfof 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 avail-able in a system through the user ISA(interface 4) supplemented with high-level language (HLL) library calls (interface 1). Any system calls are usuallyperformed through libraries. Using an API enables application software tobe ported easily, through recompilation, to other systems that support thesame API.

3.2 Types of Virtual Machines

To understand what a virtual machine is, it is first necessary to consider themeaning of machine from both a process and system perspective. Fromthe perspective of a process executing a user program, the machine consistsof a logical memory address space assigned to the process along with user-level instructions and registers that allow the execution of code belongingto the process. The machines I/O is visible only through the operating


22/35


system, and the only way the process can interact with the I/O system is

through operating system calls. Thus the ABI defines the machine as seenby a process. Similarly, the API specifies the machine characteristics as seenby an applications HLL program.

From the perspective of the operating system and the applications it sup-ports, the entire system runs on an underlying machine. A system is a fullexecution environment that can support numerous processes simultaneously.These processes share a file system and other I/O resources. The system en-vironment persists over time as processes come and go. The system allocatesreal memory and I/O resources to the processes, and allows the processesto interact with their resources. From the system perspective, therefore, theunderlying hardwares characteristics alone define 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 under-

lying platform that supports the VM is the host. The virtualizing softwarethat implements a process VM is often termed the runtime, short for run-time software. The virtualizing software in a system VM is typically referredto as the virtual machine monitor (VMM)

3.2.1 System Virtual Machines

System virtual machines (sometimes called hardware virtual machines) allowthe sharing of the underlying physical machine resources between differentvirtual machines, each running its own operating system. The software layerproviding the virtualization is called a virtual machine monitor(VMM) orhypervisor.

System VMs emerged during the 1960s and early 1970s and were theorigin of the term virtual machine. At that time, mainframe computer sys-tems were very large, expensive, and usually shared among numerous users;with VM technology, different user groups could run different operating sys-tems on the shared hardware. As hardware became less expensive and muchof 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 farmsshared 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 onthe same hardware platform. If security on one guest system is compromised


23/35


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 suffers a failure, the software running onother guest systems is not affected.

The VMM has access to, and manages, all the hardware resources. Aguest operating system and its application processes are then managed un-der (hidden) control of the VMM. When a guest operating system performsa privileged instruction or operation that directly interacts with shared hard-ware 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 offer replication, emulation,and optimization. The most common process VM is so ubiquitous that fewregard it as being a VM. Most operating systems can simultaneously supportmultiple user processes through multiprogramming, which gives each processthe illusion of having a complete machine to itself. Each process has its ownaddress space, registers, and file structure. The operating system time-shares

the hardware and manages underlying resources to make this possible. Ineffect, the operating system provides a replicated process-level VM for eachof the concurrently executing applications[1].


24/35


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

3.3 Virtual Machine Monitors

A virtual machine monitor (VMM) is a thin layer of software that runs di-rectly on the hardware of a machine. The VMM exports a virtual machineabstraction (VM) that resembles the underlying hardware. This abstractionmodels the hardware closely enough that software which would run on the un-derlying hardware can also be run in a virtual machine. VMMs virtualize allhardware resources, allowing multiple virtual machines to transparently mul-tiplex the resources of the physical machine. The operating system running

inside of a VM is traditionally referred to as the guest OS, and applicationsrunning on the guest OS are similarly referred to as guest applications.

Traditionally, the VMM is the only privileged code running on the sys-tem. It is essentially a small operating system. This style of VMM hasbeen a standard part of mainframe computers for 30 years, and recently hasfound its way onto commodity x86 PCs. Hosted VMMs like VMware haveemerged that run a VMM concurrently with a commodity host OS suchas Windows or Linux. In this setting, the virtual machine appears as simplyanother program running on the host operating system. Despite a radicaldifference from the users perspective, traditional and hosted VMMs differlittle in implementation. In a hosted architecture the VMM merely lever-

ages a third-party host OS to provide drivers, bootstrapping code, and otherfunctionality common to VMMs and traditional operating systems, insteadof being forced to implement all of its functionality from scratch.

VMMs have traditionally been used for logical server partitioning, and


25/35


are supported for a wide range of architectures; for example, the IBM xSeries

(x86 servers), pSeries (Unix), zSeries (mainframes), and iSeries (AS/400) allhave VMMs available. Recently, as hosted VMMs have appeared on thedesktop, they have begun to find other applications such as cross-platformdevelopment and testing.

3.3.1 VMM Implementation

Although the specifics of a VMMs implementation are architecture-dependent,VMMs tend to rely on similar implementation techniques. Among these tech-niques is configuring the real machine so that virtual machines can safely anddirectly execute using the machines CPU and memory. By doing this, VMMs

can efficiently run software in the virtual machines at speeds close to thatachieved by running them on the bare hardware. VMMs can also fully isolatethe software running in a virtual machine from other virtual machines, andfrom the virtual machine monitor.

A common way to virtualize the CPU is to run the VMM in the mostprivileged mode of the processor, while running virtual machines in less priv-ileged modes. All traps and interrupts that occur while a virtual machine isrunning transfer control to the VMM. Attempts by the virtual machines toaccess privileged operations trap into the VMM; the VMM emulates priv-ileged operations for the VM. In this architecture, the VMM can alwayscontrol the virtual machine regardless of what the software in the virtualmachine does.

Memory is commonly virtualized by keeping a virtual MMU for eachvirtual machine that reflects the VMs view of its address space. The VMMretains control of the real MMU, and maps each VMs physical memory insuch a way that VMs do not share physical memory with each other, or withthe VMM. Through this technique the VMM is able to create the illusionthat each VM has its own address space that it fully controls. This alsoallows the VMM to isolate the VMs from one another and prevents themfrom 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 thecorrect physical I/O device. For memory-mapped I/O, the VMM only allowsa virtual machine to see and access the particular I/O devices it is permittedto use[3].


26/35

Chapter 4

OPEN ISSUES

4.1 Introduction

Virtualization - A technology that has an enormous effect in todays ITworld. It is a technique that divides a physical computer into several partlyor completely isolated machines commonly known as virtual machines (VM)or guest machines. Multiple of these virtual machines can run on a hostcomputer, each possessing its own operating system and applications. Thisgives an illusion to the processes on these virtual machines as if they arerunning on a physical computer, but in reality they are sharing the physicalhardware of the host machine. The software that allows multiple operatingsystems to use the hardware of the physical machine is called a hypervisoror a control program. Hypervisors sit between the operating system of thehost machine and the virtual environment. There are various virtualizationtechnologies available in the market, having their own merits and demerits.

In non-virtual environment, the applications running on the machine cansee each other, and in some cases can even communicate with each other,whereas in virtual environment the programs running in one guest machineare isolated from the programs running in another guest machine, in otherwords guest machines "provide what appear to be independent coexistingcomputers" to their running programs. The degree of isolation should be

strong enough that the vulnerabilities in one virtual machine should notaffect either the virtual machines or the underlying host machine.

The computer that is being virtualized is of no difference from the com-puter that is not virtualized. The virtualized environment is vulnerable to

23


27/35

CHAPTER 4. OPEN ISSUES 24

all the traditional attacks and exploits that are common to the normal envi-

ronment. The case is even worse in the virtualized environment, where thereare several virtual computers running. The security expectations are higherin here because "there are more systems to protect", more possible points ofentry, more holes to patch and there are more interconnection points in thevirtualized environment. Attackers and Hackers are already been activelydeveloping new malware programs for virtual machine environment. "Rootkit infections, malware that detects a virtual environment and modifies itselfaccordingly" are some of them. "Low-level hypervisor attacks, and deploy-ment of malicious virtual systems" are few possible attacks that are uniqueto this environment.

On the other hand new security protection programs are also emerging

in the market every now and then from different vendors, but most of thesesecurity solutions are mainly focused on hypervisor. Since hypervisor is anew layer between the hosts OS and virtual environment, it creates newopportunities for the malicious programs. And more over, hypervisor is ba-sically a software program, so it has all the traditional software bugs and thesecurity vulnerabilities as any software have. One of such product that hitsthe market recently is SHype, a new secure hypervisor that binds securitypolicies to the virtual environment.

However, virtual machine security is more than just deploying a securehypervisor to the environment. Virtualization technologies are still evolving.Newer versions with added features are introduced before the security con-sequences of the older version has been fully studied. This work analyzesthe general security threats in a virtual environment and suggests possiblesolutions for few of the mentioned threats.

4.2 Primary Benefits

It is worth mentioning some of the security benefits that comes together withvirtualization. Two primary benefits offered by any virtualization technologyare :

1. Resource Sharing2. Isolation

In Resource Sharing unlike in non-virtualized environment where all the re-sources are dedicated to the running programs, in virtualized environment


28/35


the VMs shares the physical resources such as memory, disk and network

devices of the underlying host. The resources are allocated to the virtualmachine on request. Hypervisors plays a significant role in resource allo-cation.In Isolation one of the key issue in virtualization, provides isolationbetween virtual machines that are running on the same physical hardware.Programs running in one virtual machine cannot see programs running inanother virtual machine. This is contrast to non-virtual environment wherethe running programs can see each other and if allowed can communicatewith each other.

Virtualization provides a facility of restoring a clean non infected environ-ment even the underlying system is infected by malicious programs. Since,Virtualization provides an isolated environment this can be used for debug-

ging malicious programs and also to test new applications.

4.3 Security Vulnerabilities in Virtualization

Most of security flaws identified in a virtual machine environment are verysimilar to the security flaws assoicated with any physical system. The fol-lowing are some general flaws that are unique to the virtual environment.

4.3.1 Communication between VMs or Between VMs

and hostOne of the primary benefits that virtualization bring is isolation. This ben-efit, if not carefully deployed become a threat to the environment. Isolationshould be carefully configured and maintained in a virtual environment toensure that the applications running in one VM dont have access to the ap-plications running in another VM. Isolation should be strongly maintainedthat break-in into one virtual machine should not provide access either tovirtual machines in the same environment or to the underlying host machine.

Shared clipboard in virtual machine is a useful feature that allows datato be transferred between VMs and the host. But this useful feature can also

be treated as a gateway for transferring data between cooperating maliciousprogram in VMs. In worst case, it is used to "exfiltrate data to/from thehost operating system".

Some virtualization avoids isolation, in order to support applications de-signed for one operating system to be operated on another operating system,


29/35


this solution completely exploits the security bearers in both the operating

systems. This kind of system, where there is no isolation between the hostand the VMs gives the virtual machines an unlimited access to the hosts re-sources, such as file system and networking devices. In which case the hostsfile system becomes vulnerable.

4.3.2 VM Escape

Virtual machines are allowed to share the resources of the host machine butstill 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 runningin one virtual machine cannot monitor, or communicate either with programs

running in other VMs or with the programs running in the host. But in realitythe organizations compromise isolation. They configure flexible isolation tomeet their organization needs which exploits the security of the systems.

One such example of this kind of attack is VM escape. VM escape isone of the worst case happens if the isolation between the host and betweenthe VMs is compromised. In VM escape, the program running in a virtualmachine is able to completely bypass the virtual layer (hypervisor layer),and get access to the host machine. Since the host machine is the root, theprogram which gain access to the host machine also gains the root privilegesbasically escapes from the virtual machine privileges. This result in completebreak down in the security framework of the environment.

SOLUTION - This problem can be solved by properly configuring thehost/guest interaction.

4.3.3 VM monitoring from the host

Host machine in the virtual environment is considered to be the control pointand there are implications that enable the host to monitors and communicatewith the VM applications up running. Therefore it is more necessary tostrictly protect the host machines than protecting distinctive VMs. Differentvirtualization technologies have different implications for the host machine

to influence the VMs up running in the system. Following are the possibleways for the host to influence the VMs :

1. The host can start, shutdown, pause and restart the VMs.


30/35


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 thevirtual disks assigned to the VMs

And particularly, in general all the network traffic to/from the VMs passthrough the host, this enables the host to monitor all the network traffic forall its VMs. In which case if a host is compromised then the security of theVMs is under question. Basically in all virtualization technologies, the host

machines are given some sort of basic rights to control some actions such asresource allocations of the VMs running on top. But care should be takenwhen configuring the VM environment so that enough isolation should beprovided which avoids the host being a gateway for attacking the virtualmachine.

4.3.4 VM monitoring from another VM

Isolation plays a vital role in virtualization. It is considered as a threat whenone VM without any difficult may be allowed to monitor resources of anotherVM. Thanks to todays modern CPUs, which comes with a built in memoryprotection feature. The hypervisor who is responsible for memory isolationcan make use of this feature; this memory protection feature prevents oneVM seeing the other VMs memory resources. And more over the VMs doesnot have the possibility to directly access the file system of the host machine,so its impossible for a VM to access the virtual disk allocated to another VMon the host.

When comes to the network traffic, isolation completely depends on theconnection (network) setup of the virtualized environment. If the host ma-chine is connected to the guest machine by means of physical dedicated chan-nel, then its unlikely that the guest machine can sniff packets to the host and

vice versa. However in reality the VMs are linked to the host machine bymeans "virtual hub" or by a virtual switch.

In which case, it enables the guest machines to sniff packets in the networkor even worse that the guest machines can use ARP poisoning to redirect thepackets going to and coming from another guest.


31/35


SOLUTION - Authenticating the network traffic could be a solution the

problem described above.

4.3.5 Denial of Service

In virtual machine architecture the guest machines and the underlying hostshare the physical resources such as CPU, memory disk, and network re-source. So it is possible for a guest to impose a denial of service attack toother guests residing in the same system.

Denial of service attack in virtual environment can be described as anattack 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 virtu-alization technologies offer a mechanism to limit the resources allocated toeach guest machines in the environment. Therefore the underlying virtual-ization technology should be properly configured, which can then prevent oneguest consuming all the available resources, there by preventing the denialof service attack.

4.3.6 Guest-to-Guest attack

As we know that it is important to prevent the host machine than the indi-vidual VMs. If an attacker gains the administrator privileges of the hardwarethen its likely that the attacker can break-in into the virtual machines. It istermed as guest-to-guest attack because the attacker can able to hop fromone virtual machine to another virtual machine provided that the underlyingsecurity framework is already broken.

4.3.7 External Modification of a VM

There are some sensitive applications exists which rely on the infrastructure

of the VM environment. These applications running inside a virtual machinerequires the virtual machine to be a trusted environment to execute thatapplication. If a VM is modified for some reason, the applications can stillbe able to run on the VM but the trust is broken.


32/35


SOLUTION - A best solution for this problem is to digitally sign the VM

and validating the signature prior to the execution of this sensitive applica-tions.

4.3.8 External modification of the hypervisor

As we know that hypervisor is responsible for providing isolation betweenthe guest machines. The VMs are said to be completely isolated or "selfprotected" only if the underlying hypervisor behaves well. A badly behavedhypervsior will break the security model of the system.

SOLUTION - There are several solutions exists for this problem, one ofthe recommended solution is to use secure hypervisor like SHype to ensure

security in the hypervisor layer. Another solution is to protect the hypervisorfrom unauthorized modifications or enable the guest machines to validate thehypervisor[6].


33/35

Chapter 5

CONCLUSION

The report has presented some of the security flaws in the virtual machineenvironment. Some of the threats presented here may be considered as bene-fits in some situations, but they are presented here so that proper care shouldbe taken while designing and implementing the virtual environment.

Virtualization brings very little added security to the environment. Oneof the key issue is that everyone should be aware of the fact that virtualmachines represent the logical instance of an underlying system. So many ofthe traditional computer threats apply the same to the virtual machines also.Another issue that makes the security consequences difficult to understand isthat, there are so many different types of virtualization technologies available

in the market. Each of it has it own merits and demerits, each virtualizationdeployment is different depending on the need for the virtualization. It iscommon that any single virtualization technology will not provide shield toall the security issues arise. However, the key to create a good virtualizationenvironment is to study carefully the environment that is to be virtualized,the needs and goals of the organization, and taking into consideration all thepossible security issues that puts the virtual machines at risk. Finally care-fully design the virtual environment with the help of correct virtualizationtechnology 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 compromisedthen the whole security model is broken. Attacks against the hypervisorbecoming more popular among the attackers realm. Therefore after settingup the environment, care should be taken to ensure that the hypervisoris secure enough to the newly emerging threats, if not patches has to be

30


34/35

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 intodays computing but if done wrong it become as a threat to the environ-ment. While implementing, exaggerate the security model to with stand theattacks. And as mentioned earlier keep monitoring for new developmentsthat emerges in this field and continue to stay up to date[6].


35/35

Bibliography

[1] James E. Smith, Ravi Nair.- The Architecture Of Virtual Machinespublished by IEEE Computer Society in 2005.

[2] J. P. Buzen and U. O. Gagliardi - The Evolution of Virtual MachineArchitecture.pdf.

[3] Tal Garfinkel, Mendel Rosenblum - A Virtual Machine IntrospectionBased Architecture for Intrusion Detection from Computer Science De-partment,Standford University published in 2003.

[4] Understanding Full Virtualization, Paravirtualization, and HardwareAssist 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

virtual machine architecture

Documents