Virtualization Techniques to Enable Transparent Access to Peripheral Devices Across Networks

VIRTUALIZATION TECHNIQUES TO ENABLE TRANSPARENT ACCESS TO PERIPHERAL DEVICES ACROSS NETWORKS

By NINAD HARI GHODKE

A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2004 Copyright 2004 by Ninad Hari Ghodke ACKNOWLEDGMENTS I would like to acknowledge Dr Renato Figueiredo for his direction and advice in this work and his patience in helping me write this thesis. I thank Dr Richard Newman and Dr Jose Fortes for serving on my committee and reviewing my work. I am grateful to all my friends and colleagues in the ACIS lab for their encouragement and help. Finally I would thank my family, for where and what I am now. This effort was sponsored by the National Science Foundation under grants EIA-0224442, ACI-0219925 and NSF Middleware Initiative (NMI) collaborative grant ANI-0301108. I also acknowledge a gift from VMware Corporation and a SUR grant from IBM. Any opinions, findings and conclusions or recommenda- tions expressed in this material are those of the author and do not necessarily reflect the views of NSF, IBM, or VMware. I would like to thank Peter Dinda at Northwestern University for providing access to resources.

iii TABLE OF CONTENTS page ACKNOWLEDGMENTS ...... iii LIST OF TABLES ...... vi LIST OF FIGURES ...... vii ABSTRACT ...... viii CHAPTER 1 INTRODUCTION ...... 1 2 APPLICATIONS ...... 4 2.1 Network Computing in Grid and Utility Computing Environments 5 2.2 Pervasive Computing ...... 7 3 SYSTEM CALL MODIFICATION ...... 9 3.1 Introduction ...... 9 3.2 Implementation ...... 9 3.2.1 Architecture ...... 9 3.2.2 Tracing Thread ...... 10 3.2.3 Remote Device Server ...... 11 3.3 Handling of System Calls ...... 11 3.3.1 The open() System Call ...... 12 3.3.2 The close() System Call ...... 13 3.3.3 The read() and write() System Calls ...... 13 3.3.4 The ioctl() System Call ...... 14 3.3.5 The getpid() System Call ...... 14 3.4 Related Work ...... 14 3.4.1 Ufo Global File System ...... 15 3.4.2 Janus ...... 15 3.4.3 User Mode Linux ...... 15 3.5 Conclusions ...... 16 4 INTERCEPTION OF ACCESSES TO ISO9660 IMAGE ...... 17 4.1 Introduction ...... 17 4.2 Implementation and Architecture ...... 19 4.2.1 Architecture ...... 19

iv 4.2.2 Implementation ...... 22 4.2.3 Handling Media Changes ...... 23 4.2.4 Integration with Middleware ...... 24 4.3 Performance Measurements ...... 24 4.3.1 Experimental Setup ...... 25 4.3.2 Benchmarks ...... 26 4.3.3 Results and Analysis ...... 27 4.4 Related Work ...... 30 4.5 Conclusion ...... 31 5 KERNEL DEVICE DRIVER ...... 32 5.1 Introduction ...... 32 5.2 Implementation ...... 33 5.2.1 Architecture ...... 33 5.2.2 Device Driver ...... 35 5.2.3 Sound Server ...... 36 5.2.4 Quality of Audio output ...... 36 5.3 Applications of Remote Sound Transfer ...... 38 5.3.1 Interactive Applications in Network Computing ...... 38 5.3.2 Fair Use of DRM-Enabled Media ...... 39 5.4 Prevention of Illegal Copying ...... 39 5.4.1 Inspection of Hardware ...... 40 5.4.2 Detection Through the Use of Special Instructions ..... 40 5.4.3 Detection Through Timing Analysis ...... 40 5.5 Discussion: Impact of Future Technologies ...... 41 5.6 Related Work ...... 43 5.7 Conclusions ...... 44 6 CONCLUSIONS AND FUTURE WORK ...... 46 6.1 Conclusion ...... 46 6.2 Future Work ...... 46 6.2.1 Virtualization Using Interposition of Libc ...... 47 6.2.2 Filtering Mechanisms for Remote Sound System ...... 47 6.2.3 Virtualization of Block Devices as USB Memory ...... 48 6.2.4 Sound Capture Mechanism for Remote Sound ...... 48 6.2.5 Applications Using Virtual Devices ...... 48 REFERENCES ...... 49 BIOGRAPHICAL SKETCH ...... 52

v LIST OF TABLES Table page 4–1 Configuration of test machines used for LAN and WAN testing .... 25 4–2 Overheard time in seconds for creating ISO images and their transfer . 27 4–3 Measured total execution times for LAN experiments ...... 28 4–4 Speedup of VIRT versus other configurations in LAN environment .. 28 4–5 Measured total execution times for WAN experiments ...... 29 4–6 Speedup of VIRT versus other configurations in WAN environment .. 29 4–7 Sensitivity analysis: Effects of buffer caching for LAN tests ...... 30

vi LIST OF FIGURES Figure page 1–1 Scenario using virtual devices ...... 2 2–1 Setup of a VM-based network computing environment ...... 6 2–2 Setup of a VM-based pervasive computing environment ...... 7 3–1 Architecture and the control ﬂow of system call tracing technique .. 10 4–1 Implementation of a Virtual Remote CD-ROM ...... 21 5–1 Implementation of the remote sound system ...... 34 5–2 Output resulting from playing a 130s sound sample ...... 37

vii Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science VIRTUALIZATION TECHNIQUES TO ENABLE TRANSPARENT ACCESS TO PERIPHERAL DEVICES ACROSS NETWORKS By Ninad Hari Ghodke August 2004 Chair: Renato J Figueiredo Major Department: Computer and Information Science and Engineering We virtualized peripheral devices to allow them to be accessed over a network in a manner that is transparent to applications. The peripherals virtualized work in conjunction with middleware to achieve access, location, and migration transparencies. Such functionality is useful for virtual-machine based network- computing systems that support interactive applications, and for virtual-machine based solutions for ubiquitous computing. We tested three techniques for device virtualization. The first technique used system call interception and modification to perform remote operations on the device. This enables virtualization completely at the user-level, without the need for super-user access. The second technique consists of transparent interception of accesses from a guest operating system, to a virtualized device image file; and mapping of requests to device-specific actions by a user-level server. This solution relies on native host mechanisms Network File System (NFS) client for interception of accesses to an ISO-9660 image file, and a server that reads from the physical device using a generic SCSI interface for CD-ROM access. This solution can potentially be used

viii to access devices other than CD-ROMs (e.g., USB memory or tape drives). A prototype based on the NFS protocol and the CD-burning package “cdrecord” has been implemented and tested on GNU/Linux and can be ported to other systems. The third technique is virtualization at the device driver layer. It has been implemented for the remote transfer of audio streams generated by a virtualized audio device for an Operating System running in a Virtual Machine. The audio stream when played in the guest O/S is intercepted by the VMM, which then writes to the host sound device driver in WAV/PCM format. The host sound driver in this case is the remote sound device driver, which transfers this stream to a remote sound server across the network, where it can then be played on the user’s workstation. This technique was developed for transfer of audio streams over the network in a transparent fashion for arbitrary, unmodiﬁed applications using a virtual sound card. Because the virtual device intercepts raw WAV/PCM audio packets produced by a guest’s device driver, it cannot distinguish DRM-enabled media from unprotected media; thus the remote sound system is unable to enforce DRM protection schemes.

ix CHAPTER 1 INTRODUCTION Classic virtual machines (VMs) [1] create a number of different execution environments on a single computer, each of which exactly emulates the physical hardware of a computer. This gives the user the illusion of running on physical hardware, isolated from other VMs, all on a single physical machine. Virtual devices (in a similar vein) create an illusion of a device for an application, which may map to a physical device. This physical device may be located across a network, and may be a different type of device than the device presented to the application. The primary aim of virtual devices is to make devices attached to a server machine accessible across the network to another client machine in a transparent fashion. Applications using this device do not require any modifications, and are not aware that they are accessing a device attached to a different machine. The machine on which the application runs is the client, and the machine to which the device is attached is the server. The operating systems need not be the same on both machines. It is important that transparencies in terms of applications and in terms of location of client/server be achieved. In other words, the following transparencies [2] are desirable from the virtual device system:

• Access: Hide diﬀerences in data representation and how a resource is accessed.

• Location: Hide where a resource is located.

• Migration: Hide that a resource may be moved to another location. These transparencies can be achieved with the aid of middleware running on both the client and server. A middleware layer running on both machines would

1 2

Figure 1–1: Scenario using virtual devices take care of discovery, identification and the communication between among client and server. Access transparency is provided by the client software, which achieves device virtualization. For location and migration transparencies, middleware support is needed for initial configuration (and reconfiguration as needed in the migration transparency). 1 Figure 1–1 shows how virtual devices would be used. A user can login to any workstation, and the applications running on a remote host will access the devices attached to the user’s workstation. The display of the VM is exported using VNC[3] or VMware remote console, and the rest of the devices are accessed trough virtual device services. Sound is virtualized using a remote sound system (Chapter 5), and storage devices are virtualized using a virtual ISO solution (Chapter 4). Our goal was to design and evaluate low-level software that enables device virtualization for a representative set of devices. These techniques can then be

1 Relocation transparency (hiding that a resource may be moved to another location while still in use) can be achieved, but would involve using a proxy server. 3 complemented by middleware and used in network computing Grid systems and in pervasive computing applications (Chapter 2). Our study explored three different techniques of device virtualization. The first technique, system call tracing (Chapter 3) can be used for virtualizing USB and character devices. The second virtualization technique, ISO 9660 format and NFS (Chapter 4) can be used for virtualizing any block device. The third technique, remote sound for transferring audio streams, is discussed in Chapter 5. Chapter 5 also discusses the fact that current platforms used to deliver DRM-enabled audio media are susceptible to malicious end-user type attacks. CHAPTER 2 APPLICATIONS This chapter discusses applications and systems that might be conceived if a device virtualization service layer exists. A device virtualization system would consist of device clients and servers controlled by a middleware layer (responsible for discoverng, identifying and setting up communication channels between clients and servers). Using virtual machines along with virtual devices allows for transparency to be achieved for both user-level and kernel-level applications. The first application considers the advantages of virtual devices in Grid [4] environments. Virtualization can enable improved job scheduling by decoupling the job and its peripheral hardware requirements. For instance, when scheduling a job, if a particular I/O hardware is required, then the hardware dependency can constrain job-scheduling decisions. In contrast, with the availability of virtual devices, the I/O hardware could be made accessible over the networka, imposing fewer scheduling constraints. The second application is in ubiquitous computing, where virtual devices would allow a user to integrate his/her universally accessible desktop with the peripherals attached to any/all computing devices that are accessible to him or her. “Classic” virtual machines (VMs [1]) have desirable properties that have moti- vated their use originally in mainframe systems (IBM VM/370 [5] and successors), and more recently, in servers and desktops (VMware [6], VirtualPC). The indirection introduced by VM systems at the instruction-set level is at the core of their ability to provide (with high efficiency) features such as time-sharing across multiple O/Ss, checkpointing and migration, and virtual devices (local or remote). This indirection also has implications on an often implicit system-design assumption of

4 5 direct access to hardware by the O/S. With VMM emulation of privileged instructions (possibly combined with dynamic binary translation), it becomes possible to present to a conventional O/S an eﬃcient duplicate of the physical machine, where all privileged instructions (including I/O) go through additional layers of software between an O/S device driver and the hardware. 2.1 Network Computing in Grid and Utility Computing Environments

A fundamental goal of a utility computing model is to support secure and flexible sharing of physical resources. Classic virtual machines are desirable as execution environments in this model: they support sharing of physical resources by wide-area users with high flexibility in terms of application configuration, legacy applications (including their preferred O/S environment), and enhanced resource security against untrusted code and users (if independent security mechanisms are implemented at the VM monitor and the operating system). The enhanced security and flexibility of a VM-based solution enables privileges and applications to be offered to users of a distributed system that are not typically found in conventional setups (for example, including administrative privileges and installation of user- provided applications, including the O/S itself). This lets VMs be used to execute interactive applications in a network- computing “Grid” system [4, 7]. Figure 2–1 shows a typical setup of a network computing system. A VM-based execution environment allows users to customize an execution environment for an application, encapsulate its virtual state, and replicate it across distributed resources by means of dynamic instantiation of virtual machine “clones”. In contrast, execution environments based on physical machines are typically setup by local administrators and are difficult to customized to individual user needs. Users of a VM-based distributed system can be given environments that can be highly customized; and the middleware is capable of archiving, replicating, and instantiating such environments on any available 6

Figure 2–1: Setup of a VM-based network computing environment physical resource capable of supporting VMs. With respect to customization, there are several challenges that arise in allowing user access to middleware-scheduled remote VMs. First, support for interactive sessions may become necessary. Second, the users may not know the name and/or location of the host servers where VMs are scheduled. Third, even if the server is known, users may not have physical access to its devices. Previous work has shown that support for interactivity in the presence of Grid-scheduled remote sessions can be achieved by integrating remote display applications (e.g., VNC) with resource-management middleware that supports dynamic account allocation, e.g., as implemented in PUNCH [8]. Although necessary for supporting interactivity, remote displays are not suﬃcient for applications that require additional functionality. For example, access to USB and FireWire ports and the ability to install system software from a physical CD-ROM are not supported. 7

Figure 2–2: Setup of a VM-based pervasive computing environment

Virtual device service can enable mechanisms that enable users to customize the VM environment to support access to remote storage devices such that they are perceived as if they were CD-ROM devices local to the VM guest using the virtual ISO solution described in Chapter 4. 2.2 Pervasive Computing

Recent advances in mobile computing have allowed devices to be more powerful and to access the internet with greater bandwidth and still have small form factor. Wireless networking has also become pervasive, allowing the connection of a mobile device to a network with minimal conﬁguration. It should be possible for a user to access his/her computing sessions from anywhere and from any device and be able to utilize the peripherals attached to any computing device in a ubiquiotous way. Accessing a computing session is currently possible by using VNC by exporting the display but the ability to access the peripherals attached to these devices through VNC session on the client is not yet possible. Access to 8 local peripherals is possible using the Internet Suspend Resume [9] method which uses virtual machines to handle migration. However, it is not possible to access the peripherals of another computing device. Figure 2–2 depicts how a pervasive computing solution with virtual devices allows access to peripherals of the PDA and of the user’s workstation irrespective of where they are accessing the desktop. The desktop is installed in a VM and is accessible using VNC from the PDA. It can be running on the user’s desktop using the method explained in Internet Suspend Resume. In the example, a CD- ROM attached to the user’s workstation is accessible to the VM (e.g., using the virtual ISO solution of Chapter 4), the memory card attached to the PDA is also accessible to the VM (e.g., as a CD-ROM drive) which also uses the virtual ISO solution of Chapter 4. The remote sound system from Chapter 5 can be used for transfer of audio streams from the VM executing in the VM server to the user’s desktop or PDA. CHAPTER 3 SYSTEM CALL MODIFICATION 3.1 Introduction

This is the ﬁrst of the three techniques presented in the thesis, that is a completely user-space solution and does not need kernel changes or super-user access to be deployed. This technique intecepts the system call that an application would make on a virtualized device and translates them into remote operations. The device is virtualized for an application that accesses it. From the application’s perspective it accesses the virtual device as if it were a regular device. This is achieved by attaching a system call tracing thread to the application; all the system calls made by the application are intercepted and those that access the device are modiﬁed. The system calls that this application makes on the virtualized device are transferred to a remote device server. The device server then makes the system calls on the attached (physical) device and the results are transferred back to the tracing thread, which then inserts these results into the applications address space. This does not require any recompilation or relinking of the application; however it relies on the availability of a system call tracing infrastructure such as ptrace which is available in GNU/Linux OS and /proc available on Solaris. 3.2 Implementation

3.2.1 Architecture

The system consists of two parts: the tracing thread and the remote device server as shown in Figure 3–1. The application running is the target of virtualization and is attached to the tracing thread. The tracing thread communicates with the remote device server over TCP. The tracing thread uses the ptrace [10, 11]

9 10

Figure 3–1: Architecture and the control ﬂow of system call tracing technique system call for attaching the process and also for intercepting the system calls of the attached process. 3.2.2 Tracing Thread

The tracer is the component which creates the illusion of a device for the application. It also offers access, location and migration transparencies to these devices. It uses the ptrace system call available on GNU/Linux to trace the system calls of the attached process. The application that wants to access the virtualized device is specified as a command-line argument when invoking the tracer. The tracer also needs the IP address and port number of the remote device server. Once executed, the tracer on execution immediately forks and the child sets itself up to the traced and the parent attaches itself to the child process. The child then executes the application program specified on the command-line using the exec() system call. The parent is 11 then able to intercept all the system calls of the application. This is a mechanism similar to those used in Ufo [12] and Janus [13]. The function of the tracer thread is to intercept the system calls made from the target application and recognize those that need remote operation. These are changed to a getpid() call, so that the process completes its system call. The reason it has to be changed to a getpid is that there is no way to cancel the system call; getpid is a system call that has no side effects and is fast. This technique was inspired by the UML[14] design. The system call is intercepted in two places: once before the kernel operates on the system call, and once again before the results of the system call are returned to the process. The tracing thread can change the system call before the kernel operates on it and then before the system call is returned to the process the tracer can insert the results it wants into the running process. 3.2.3 Remote Device Server

The remote device server accepts connections from the tracer program and executes the system calls that are requested in the incoming data packets. The server is designed to be a multithreaded stateful server so it can potentially service multiple tracer clients. A new thread is created whenever a new connection is established; it is destroyed once the client closes the socket or when an error on the socket occurs. Open() is the ﬁrst system call that is sent by the client to be executed. On receiving a data packet, the server performs the operation as requested in the packet and sends back the return packet containing the results of the operation. 3.3 Handling of System Calls

The tracer does not modify all system calls that it intercepts. All the system calls are checked for the type of the system calls: the open(), close(), read(), write() and ioctl() calls are checked for their parameters, and only those accessing the 12 virtual devices are modiﬁed. The system calls make use of registers to hold pointers to data and results when the transition is made from user-level to kernel-level. This section explains the signiﬁcance of these registers in each system call and how they are utilized to introduce the indirection and the operations needed for each system call. The register eax contains the system call number and the registers not mentioned in the discussion below are not used. 3.3.1 The open() System Call

Contents of the registers.The registers used in the open system call are: • eax: System call number • ebx: Pointer to ﬁlename • ecx: Mode and permission bits

Operations.

• The register ebx is used for extracting the filename. Since the open system call does not contain the information for the length of the filename we have to keep checking for the null character to determine the end of filename.

• The ﬁlename is checked to see whether it matches the name of the virtualized device. If it does then the call is changed to getpid and a remote open is called.

• The exact processing of the remote open is

1. Connect to the device server.

2. The remote device server opens the device and returns the results.

3. The tracer stores the results and the socket descriptor.

4. The tracer on the return of the getpid system call inserts a ﬁle descriptor into applications user space.

• When inserting the file descriptor into the running process, the tracer has to keep a record of it so that the read(), write() and other system calls using the file descriptor are handled correctly. We achieve this by inserting a file descriptor whose value is above 1000. The reason we choose such a high value is that the OS always returns the lowest value descriptor; under normal circumstances it does not exceed 1000, and hence we can check in the other system calls whether the file descriptor is for remote operation. 13

• The dup() system call would also need to be handled because a new ﬁle descriptor would be generated and the operations on this would also need to be modiﬁed. 3.3.2 The close() System Call

Contents of the registers.The registers used in the close system call are: • eax: System call number • ebx: File descriptor

Operations. For the close() system call the tracer checks whether the ﬁle descriptor is the remote descriptor. If it is, the tracer converts the call to getpid() and simply closes the socket descriptor and the remote device server would know that a close has happened. 3.3.3 The read() and write() System Calls

Contents of the registers.The registers used in the read and write system calls are: • eax: System call number • ebx: File descriptor • ecx: Buﬀer pointer • edx: Buﬀer size Operations.

• Whenever a read or write system call is encountered, the ﬁle descriptor is checked in the list maintained by the tracer. If it matches, then the system call is changed into a getpid() and the remote operation is performed.

• For the read system call, the results of the remote read, the data returned and the size of the data, have to be inserted into the application process space.

• For the write system call the data to be written is extracted from the application’s process space and sent as a parameter to the remote write.

• For the write system call the number of bytes actually written is inserted after the getpid() returns. 14

3.3.4 The ioctl() System Call

Contents of the registers.The registers used in the ioctl system call are: • eax: System call number • ebx: File descriptor • ecx: Ioctl number • edx: Buﬀer pointer

Operations. The handling of the ioctl() is similar to the write system call, except the tracer has to send the ioctl number also as an argument. The number of bytes to be transferred from the buﬀer pointer(ebx), which is a void pointer, varies from device to device. Because of this non-uniformity in the ioctl() system call for various devices, implementing this solution would require reimplementation of the ioctl handling routine for diﬀerent devices. BSD-based UNIX systems do not have this non-uniformity because the number of bytes to be transferred is encoded into the ioctl number and hence a generic ioctl() routine would work. 3.3.5 The getpid() System Call

Contents of the registers.The registers used in the getpid system call are: • eax: System call number

Operations. When system calls are modified, they are changed to a getpid() and allowed to proceed to the kernel. These calls need to be modified when they return so that the results from the remote calls can be inserted into the running application process. A flag is used to determine whether the getpid() system call that returns is the result of a modified system call. If it is then the results are inserted into in the traced application process. 3.4 Related Work

System call tracing has been used for various tasks from integrating remote ﬁle-systems into the current environment to using it for detecting malicious code 15 and providing a sand-box environment to foreign code. It is also used for creating Application Binary Interface (ABI) [15] virtual machines like User Mode Linux. 3.4.1 Ufo Global File System

Ufo [12] extends the functionality of the operating system by integrating remote filesystems using interception of selected system calls at user level. They achieve this by modifying the behaviour of some system calls to implement the new functionality. This approach allows Ufo to implement a global file system, which allows the users to access remote files using ftp and http protocols as if they are local files. This approach also does not require the application to be modified and also works without super-user privileges. 3.4.2 Janus

Janus [13] makes use of system call tracing for sand-boxed execution of untrusted code. Janus traces the system calls of the untrusted application and regulates them. Whenever a application makes a system call, control is passed to janus, it decides whether to allow or deny the system call. It accomplishes by maintaing a dispatch table indexed by the system call number. Each entry has a linked-list which determines under what conditions the system call is allowed to proceed. Later work by Garﬁnkel[16] has shown that, if such a tool is not carefully implemented, the sandbox can be circumvented. 3.4.3 User Mode Linux

The User Mode Linux (UML) [14] is a user-mode kernel port of the Linux kernel to the system call interface. It is an ABI virtual machine which consists of the user-mode kernel and a tracing thread. The processes running in the UML are running on the host OS and the tracing thread intercepts the system calls and modiﬁes them to give them a view as if they are running on the UML kernel. For this the UML kernel supports the notion of virtual memory, shared by all the processes, by using a memory-mapped ﬁle. 16

3.5 Conclusions

The approach outlined in this Chapter can be used for virtualizing any kind of device. This approach based in user-level and without requiring super-user access would be utilized for faster prototyping of virtual devices. However, this approach suffers from the overhead of system call interception. The overhead is significant since we are intercepting all the system calls though only small number of them would be modified. This presents a problem when virtualizing devices for large applications such as a classic VMs like VMware. An advantage of this approach is illustrated by the following scenario. If a user has a device and associated drivers are available for a particular OS “X”, then this device can be made available for some other OS “Y” by porting the user level application to OS “Y” and running that in conjunction with the tracer program. In this scenario, the device is attached to the host “X”, which has the driver and the remote device server running on it. There exists a demand for integrating applications whose source is not available in a middleware to enable collaboration and sharing of files. For instance, applications like Document Editors could be integrated into the Distributed Confer- encing System (DCS) [17]. This can be implemented if we can run the editor using the tracer and the required system calls would be reinterpreted. Here instead of communicating with the remote device server we can communicate with the middleware even if the middleware is written in a particular language such as “java”. Because a middleware is used, authentication, encryption, compression, replication and fault tolerance can be achieved and is transparent to the application. For instance, whenever the tracer transmits data we could potentially multicast the data so it is stored at multiple places. A similar scenario could be conceived where multiple servers are employed to support fail-over. CHAPTER 4 INTERCEPTION OF ACCESSES TO ISO9660 IMAGE 4.1 Introduction

This Chapter describes a technique that allows a VM that is instantiated and controlled by distributed computing, Grid middleware, as discussed in Chapter 2 to seamlessly access a remote read-only storage device. The technique builds on three major components: a monitor that supports virtualization of a physical storage device by means of a file system image (e.g., ISO9660, Universal Disk Format- UDF); a distributed file system client that intercepts accesses to such image, and a user-level server that maps requests against a virtual image to physical device requests. This technique is based upon the notion of a virtual ISO image that can be accessed on-demand by a distributed file system client. It is, however, not limited to CD-ROMs and can be applied to provide support for other read-only remote storage devices, allowing such devices to appear as virtual CD-ROMs to the VM guest. A key aspect of the proposed solution is that it decouples the VMs host and guest O/Ss from remote device idiosyncrasies: the guest perceives the remote device as a CD-ROM, while the host perceives it as an NFS-mounted image. Device-specific information is delegated to a customized user-level server that resides next to the device itself neither within the VM guest, nor the host. Such decoupling is beneficial for both the end-user of a virtual resource (many guest O/Ss can tap into virtualized remote devices) and for the administrator of its corresponding physical (a single network file system setup is necessary to support a variety of devices).

17 18

An initial solution that supports a virtual remote CD-ROM device for the VMware hosted I/O environment [18] via Network File System (NFS) [19] client access interception and a user-level device-specific server is proposed and evaluated. The objective of this solution is to allow for a user to customize the environment of a remote VM guest (through the installation of software distributed in CD- ROM media), while providing a user interface equivalent to that of a local device, and in a manner that integrates with middleware without requiring kernel-level modifications. To this end, it can leverage existing middleware techniques for establishing and managing on-demand, per-user distributed virtual file systems [7]. It supports applications that include the installation of a base operating system (O/S), installation of conventional user applications, and the execution of a full- blown O/S from a bootable CD-ROM. Experimental results based on a prototype implementation show that its performance ranges from 10% slower to 195% faster than alternative options for remote device access (based on NFS and SCP) in a wide-area environment, and 27% slower to 76% faster in a local-area environment. This Chapter describes the architecture of this solution and presents experiments that evaluate the performance of a prototype implementation. The experiments consider the execution time and setup latencies of three different methods of providing access to a remote CD-ROM (virtual, NFS-based and SCP- based). The benchmarks considered in the experiments include the installation of Red Hat Linux, and Microsoft Office XP, execution of an application from the CD-ROM, and copy of a large file from CD-ROM to the virtual machines disk. Both local-area and wide-area network scenarios are evaluated. The rest of the Chapter is organized as follows: Section 2 describes the architecture and implementation of the virtual remote CD-ROM. Section 3 describes the experimental setup and presents results from performance analysis 19 based on a prototype implementation. Section 4 discusses related work, and Section 5 presents conclusions. 4.2 Implementation and Architecture

4.2.1 Architecture

The overall architecture of the network-computing system organization targeted by this technique is illustrated in Figure 2–1, where VM servers run virtual machine guests that can be accessed remotely by a user. Virtual machines are controlled by middleware, and once instantiated are accessible to users via a remote display. This section describes a virtual remote CD-ROM that has been architected to fulﬁll the following design goals:

• The solution needs to support CD-ROM use for applications without requiring the presence of a guest operating systems including the installation of the VM guest O/S itself.

• It should be possible to integrate the solution with distributed computing and Grid middleware, supporting protocols and solutions available across many platforms, user-level implementations, and reusing existing mechanisms for establishing data transfer sessions.

• The solution needs to present an interface to the user that is equivalent to that provided by a local, physical system.

• The solution should be such that transformation of devices should be possible (i.e., A device like USB memory key can be presented as a CD-ROM drive to the VM).

• The solution should provide for good performance. In order to develop a user-transparent technique to access the CD-ROM on the local workstation, one needs to look at the mechanisms used by a virtual machine monitor to access a device. There are two approaches taken by virtual machine solutions: the classic approach is to access a physical device through VM monitor drivers; another is to access physical devices through drivers of the host O/S (hosted I/O). In the case of a CD-ROM, a hosted I/O VM such as VMware can provide access in two diﬀerent ways: the physical CD-ROM device of the virtual 20 machine host or it can use an ISO image stored as a ﬁle accessible to the host as a virtual CD-ROM device. In the setup of Figure 2–1 the VM host server is located at a remote site, and the user does not have physical access to the CD-ROM drive. In this scenario, the current ways of allowing a guest virtual machine to access data from a remote CD-ROM are

• Use a kernel component (e.g., NBD [20] Network Block Device) that supports remote devices as one of its own block devices. An NBD device can be created on the host server and be used as a CD-ROM device, while the NBD server runs on the users workstation.

• Transfer the data from the CD-ROM to the virtual machine guest (e.g., via FTP, SCP or mounting the CD-ROM by means of NFS or SMB).

• Create an ISO image of the CD-ROM, and transfer it to the VM host server (e.g., via FTP or SCP) and use it as a CD-ROM.

• Create an ISO image, export it via NFS, mount the share containing the ISO image on the host server and use it as a CD-ROM.

Several limitations are associated with the above approaches. The option of using NBD is operating system dependent, limiting it currently to Linux-based systems, and it would only be useful for block devices like CD-ROM and cannot be used with other devices. Transferring the data directly into the O/S installed in the virtual machine guest requires the presence of an O/S, and does not allow a user to install an operating system of their own. The options of using ISO images have an inherent disadvantage of the setup latency of creating (and transferring) the image; they also require signiﬁcant hard disk space for creating and storing the ISO images. Long setup latency (e.g., minutes) has a negative impact on user interface: it corresponds to the time from insertion of physical media into the CD-ROM drive by a user, to the time the CD-ROM can be accessed (e.g., its table of contents). If the actual amount of data accessed is small then sending the entire contents of the CD-ROM is expensive. 21

Figure 4–1: Implementation of a Virtual Remote CD-ROM

In contrast, the virtual remote CD-ROM of this Chapter is designed as a user- level component; it is built on top of NFS, a de-facto standard that works across heterogeneous platforms, and can be deployed on platforms that are supported by NFS and cdrtools (e.g., Windows, Linux, Solaris). Unlike alternative solutions, it is independent from the configuration of the VM guest. Unlike NFS/SCP solutions, the transfer of data occurs on-demand as sectors from the CD-ROM are requested, and unlike NFS solution, the creation of an ISO image does not take place but a virtual ISO image is available on-demand. A read-only ISO filesystem can be created of many device (e.g., floppy drive to a USB memory key). The filesystem need not be created in its entirety, but only the table of contents and the custom NFS server can then access into the appropriate files. The design goals are achieved using an architecture that is based on techniques used by Grid middleware to establish the dynamic creation/destruction of distributed virtual file systems. Figure 4–1 depicts the virtual remote CD-ROM architecture. The basic idea is to introduce a software layer that presents a virtual ISO image to the VMM. The physical CD-ROM is accessed from the virtual ISO 22 image by transforming NFS requests issued by the clients O/S (as a result of system calls issued by the hosted I/O VMM) into commands to control the physical device at the server side. 4.2.2 Implementation

The approach taken in the implementation of the virtual remote CD-ROM is that NFS read requests are transformed into a raw read of the CD-ROM using SCSI commands. A directory named cdrom having a zero-length cdrom.iso file present is exported. This directory is exported with the cdrom.iso functioning as the virtual ISO image. The perception of a virtual ISO image is created in the following way: the stat function of the NFS server is modified so that whenever the stat of the ISO file is requested it returns the stat of the CD-ROM inserted in the drive. For size it returns the size of the CD-ROM in the drive, for access time it returns the time when the CD-ROM was inserted. This implementation of the stat function makes the client think it is accessing the ISO image of the CD-ROM. For reads, the offset supplied by the NFS read call is transformed into sectors number to be accessed and read from the CD-ROM using the generic SCSI driver. The NFS client sees an ISO file with a size equal to the size of the CD-ROM and this is used by the VM as the CD-ROM for the guest operating system. The virtual CD-ROM server is implemented as a user space NFS V2 server based on UNFSD (nfs server version 2.2 beta 37). The methods of interest that have been utilized are NFSPROC NULL, GETATTR, ROOT, LOOKUP, READ, and STATFS. The rest of the methods were implemented but returned appropriate error messages that reflect the read-only nature of the CD-ROM filesystem. The complete NFS V2 protocol was implemented so that it could be used from any NFS v2 or higher compliant client. The mount protocol did not need any modifications. The NFSPROC LOOKUP and the NFSPROC ROOT methods were not modified and return the directory and the file. The modified stat functionality for the 23 cdrom.iso file is utilized in the NFSPROC LOOKUP, NFSPROC GETATTR, and NFSPROC READ calls. The second part of the virtual CD-ROM is the integration of the readcd program of the cdrtools package program into the NFS server. The readcd program uses the generic SCSI interface on Linux and it also needs a configuration file con- taing the SCSI bus, target and lun information to identify CD-ROM device among all the SCSI devices. It implements a server side cache by buffering 256KBytes read from the physical media. Whenever a request for NFSPROC READ is received, it tries to satisfy the request from the buffer if the requested block is in the buffer otherwise the read is converted into a series of SCSI commands which read the appropriate sectors of the CD-ROM based on the requested offset, it reads in 256Kbytes of data to fill the buffer and returns the requested data. 4.2.3 Handling Media Changes

In operating systems such as Microsoft Windows, a CD-ROM can be ejected from the drive without notifying the operating system; in contrast, Unix-based O/Ss require explicit umount or eject commands to be used to remove the media. These semantics have been achieved in the virtualization layer by using the perl scripting API of the VMware GSX server and the use of a generic SCSI device. The generic SCSI driver is used to read the data so the CD-ROM drive is not locked when it is accessed (i.e., it can be ejected even when the CD-ROM is being accessed)1 .This allows the user to eject the CD-ROM asynchronously (i.e., no special action for ejecting the CD-ROM is required in the virtual CD-ROM software). At the same time the semantics of locking of the CD-ROM drive used by Unix (i.e., the user cannot eject the cdrom without using the eject or umount

1 In contrast, an open of /dev/cdrom would lock the device and the process opening the ﬁle would need to be killed for ejecting the CD-ROM. 24 commands in the Linux VM) is not implemented in the present version since it is possible to manually eject the CD-ROM even when the Linux running on the virtual machine guest is still accessing it. In order to transmit media changes to the running VM, a media change script that runs on the VM host has been designed. This media change script routinely polls the creation time of the virtual ISO image; if it detects a change in creation time of the ISO image, it signals the VM monitor by issuing disconnect media/connect media commands through the VMMs perl scripting API. These actions simulate the change media signals for the operating systems running as guests. 4.2.4 Integration with Middleware

The virtual remote CD-ROM can leverage Grid middleware that supports on- demand creation of proxy-based distributed virtual file systems: from a middleware standpoint, the virtual CD-ROM server can be perceived as equivalent to the NFS proxy described in. The basic mechanisms necessary to create a virtual CD-ROM session include server-side scripts to instantiate and terminate the user-level NFS and mount servers, and client-side scripts to mount and unmount the file system. These have been in use in the context of the proxy-based PUNCH virtual file system since the Fall of 2000. On-going efforts to extend the virtual file system to support client-side caching, pre-fetching and cross-domain encrypted transfers over SSH tunnels can also be leveraged by the virtual remote CD-ROM. 4.3 Performance Measurements

Measurements were carried out to ﬁnd out how the Virtual Remote CD-ROM performs against a regular CD-ROM and other conﬁgurations possible with the hosted I/O VMM. The tests carried out were chosen to be representative of the type of applications that would be utilizing a CD-ROM in a network computing infrastructure. 25

Table 4–1: Conﬁguration of test machines used for LAN and WAN testing Role of Sys- Processor Memory Operating VMware CD-ROM tem System version speed LAN VM Pentium 4 2Ghz 512 MB Mandrake Workstation 40x host Linux 9.1 4.0.0 build- 4460 WAN VM Dual Pentium- 1 GB Red Hat GSX N.A. host III 1 Ghz Linux 7.3 Server 2.0.1 Virtual Pentium 4 2Ghz 512 MB Red Hat Not Re- 40x remote CD- Linux 7.3 quired ROM server

The tests were carried out in LAN as well as WAN environments. The experimental framework is summarized in Table 4–1 (Physical access to CD-ROM not available for WAN tests, VMware not required for the virtual remote CD-ROM server). In the LAN environment, machines are connected by 100Mbit/s switched Ethernet. In the WAN environment, the VM host is located at Northwestern University, and the physical CD-ROM drive is located at the University of Florida. Since the other conﬁgurations using the ISO image as CD-ROM have signiﬁcant setup times, they are also included in the comparisons. 4.3.1 Experimental Setup

The conﬁgurations considered in the performance analysis are as follows

• PHY (Physical CD-ROM): This setup uses the physical CD-ROM of the VM host server in the virtual machine conﬁguration.

• VIRT (Virtual Remote CD-ROM): In this setup the virtual CD-ROM server exports a cdrom.iso file that is mounted on the VM host machine. The virtual ISO file is then used as a file-based virtual CD-ROM device by the VM.

• NFS (NFS-exported ISO image): In this setup the ISO image file of the CD- ROM is first generated using the readcd program and exported using NFS. This ISO image is mounted on the VM host server and used as a file-based virtual CD-ROM device. 26

• SCP (SCP-based transfer of ISO image): In this setup the ISO image ﬁle of the CD-ROM is generated using the readcd program and transferred to the VM host server using the scp program.

The performance analysis considers the setup time and total execution time for the benchmarks described in the following subsection. For the NFS configuration, the setup time is the time required to create the ISO image of a CD-ROM and store it in an NFS-exported file system. For the SCP scenario the setup time includes the creation of the ISO image and its transfer to the VM host server using scp. There is no setup time for the VIRT configuration, as the virtual ISO image is constructed and exported on-demand. 4.3.2 Benchmarks

The performance of the proposed solution has been evaluated by measuring the execution time of a set of 4 benchmarks on the conﬁgurations described in the previous section. The benchmarks have been chosen to represent a set of applications of a remote CD-ROM model to the network-computing environment of Figure 2–1.

• Installation of Operating System. This benchmark models the installation of an operating system into a virtual machine. The Linux Red Hat 7.3 Workstation O/S has been installed using the kickstart method, wherein all configuration options are specified in a file (ks.cfg) used during the installation process. The baseline execution time is measured as the time required installing the RPM packages and does not include the time required for disk formatting and hardware detection, where the CD-ROM device is not accessed. The installation required two CD-ROMs and the time of changing the media is not included in the measurements.

• Running an Application from the CD-ROM. This benchmark models the performance of booting an O/S and executing an application directly from the CD-ROM. For this experiment, the baseline execution time is measured as the time to boot a Knoppix [21] Linux O/S directly from the CD-ROM and starting the OpenOﬃce.org application.

• Installation of Software from CD-ROM. This benchmark models the performance of a software installation from a CD-ROM. For this experiment, all components of Microsoft Oﬃce XP are installed to the disk of a virtual 27

Table 4–2: Overheard time in seconds for creating ISO images and their transfer Test Create ISO image Transfer(LAN) Transfer(WAN) Install OS 300 120 2369 Run Application 164 76 1303 Install Software 129 45 843 Copy Large File 161 77 1329

machine running Windows XP pro. The baseline execution time is the time measured between selecting the type of install and completion of installation.

• Copying a Large File. This benchmark models the use of the CD-ROM as a media for transferring a large archived data set to a remote VM, and exercises the throughput of the proposed solution. The size of the data was chosen to be large so that the effect of caching is negligible; a 728-MB file is copied from a CD-ROM to the local file system of a Linux Red Hat 7.3 installation. The baseline execution time is measured using the UNIX command time for copying the file from the CD-ROM to the /tmp directory.

The CD Winbench 99 benchmark was evaluated as a candidate application. However, since it does not report results in terms of execution times (rather, it reports Winbench scores); it is not straightforward to factor in the substantial differences in setup times among the VIRT, NFS and SCP configurations. The setup time is a key differentiator between remote CD-ROM solutions, hence this benchmark was not considered in the analysis. 4.3.3 Results and Analysis

The performance analysis primarily compares Virtual CD-ROM against possible alternatives for remote access (NFS and SCP conﬁgurations), with the physical CD-ROM serving as a reference. The analysis assumes that ISO images need to be generated for every physical CD-ROM. Table 4–2 displays the setup (overhead for ISO creation and transfer) for each benchmark. The UNIX command time is used to measure the time required for creation of an ISO image from the CD-ROM (readcd program) and transfer (scp command). The setup time is measured for both LAN and WAN conﬁgurations. 28

Table 4–3: Measured total execution times for LAN experiments Conﬁg Install OS Run Application Install Software Copy Large File PHY 373 147 367 171 VIRT 463 285 384 454 NFS 676 279 431 329 SCP 813 362 472 519

Table 4–4: Speedup of VIRT versus other conﬁgurations in LAN environment Test Install OS Run Application Install Software Copy Large File PHY/VIRT 0.81 0.52 0.96 0.38 NFS/VIRT 1.46 0.98 1.12 0.73 SCP/VIRT 1.76 1.27 1.23 1.14

It can be interpreted as the user-perceived latency between the insertion of the CD-ROM into the drive and its actual access (e.g., to its table of contents). The VIRT and PHY configurations can immediately be accessed by a user, while for the NFS configuration the CD-ROM has to be converted into an ISO image, and for SCP an additional transfer to the host server is required before the CDs table of contents can be accessed. Table 4–3 shows, for each benchmark, the setup and the total execution times in a LAN environment. The total execution time is the sum of setup and the baseline time required for running the tests. Table 4–4 presents the relative performance of the virtual remote CD-ROM with respect to the other configurations (with values greater than 1 indicating speedups). Results show that the performance of the VIRT is better than alternatives when the CD-ROM is not accessed in its entirety as in O/S installation, application run and software installation. The reasons are twofold: first, only data that is needed is actually transferred (in contrast with SCP). In addition, the latency seen by the user when opening the CD-ROM is substantially smaller because the virtual ISO image is always available on insertion of a CD-ROM (in contrast with NFS). Overall the VIRT configuration is 27% slower to 46% faster than NFS and 14% to 76% faster than SCP. 29

Table 4–5: Measured total execution times for WAN experiments Conﬁg Install OS Run Application Install Software Copy Large File VIRT 2810 539 1047 1788 NFS 3051 533 1179 1656 SCP 5021 1592 1407 1611

Table 4–6: Speedup of VIRT versus other conﬁgurations in WAN environment Test Install OS Run Application Install Software Copy Large File NFS/VIRT 1.09 0.99 1.13 0.93 SCP/VIRT 1.79 2.95 1.34 1.90

The performance is worse than NFS and SCP for the application that needs the entire content of the CD-ROM (Copy Large File). The virtual remote CD- ROM has the additional overheads of network, RPC, the server software itself and possibly the CD-ROM access latency. The performance of the virtual remote CD-ROM is worse than that of the physical CD-ROM. However, the virtual remote CD-ROM would be used in circumstances where physical access to the host server is not available. Table 4–5 and Table 4–6 present the performance measurements for the experiments performed in the WAN environment. In this scenario, measurements for the physical CD-ROM configuration are not available because of lack of physical access to the host server. The same overall behavior is seen in that WAN configuration: speedups are larger where the entire content of the CD-ROM is not transferred (Install OS, Run Application, Install Software) because of on-demand transfers For these applications, the speedups with respect to SCP are larger than in the LAN environment. Overall, the VIRT configuration is 7% slower to 13% faster than NFS and 10% slower to 195% faster than the SCP configuration. The effect of file system caching was observed in the experiments. Table 4–7 shows results from a sensitivity analysis that considers buffer cache effects: in the first run the cache is cold, and in the second run the cache is warm. The impact of caching on performance is most noticeable in the VIRT configuration for the 30

Table 4–7: Sensitivity analysis: Effects of buffer caching for LAN tests Config Run Application Install Software Copy Large File 1st Run 2nd Run 1st Run 2nd Run 1st Run 2nd Run PHY 147 147 367 367 171 161 VIRT 285 101 384 367 454 436 NFS 115 93 302 298 168 164 SCP 122 97 298 295 281 197

Knoppix (application run) benchmark. In this application, the actual data being transferred (about 150MB) is smaller than the size of a typical CD-ROM and can be cached in the memory buﬀer of the LAN VM host. 4.4 Related Work

The Network Block Device (NBD) [20] consists of kernel-level client-server software that can provide access to block devices of remote servers as if they were a block device local to a client. The remote server opens a block device node and this is used as a block device by the NBD. An alternative approach to the one presented in this Chapter is to use NBD to export a servers /dev/cdrom to the VM host. The device /dev/nbd0 made available by NBD would then be used as a physical CD-ROM by the virtual machine. A key disadvantage of using this approach is that NBD is an O/S specific solution it is currently available on Linux only thus not supporting physical CD-ROMs of non-Linux user workstations. GeomGate (http://kerneltrap.org/node/view/742) is software available on BSD, which allows mounting of remote disks using the network, in a way similar to NBD on Linux. This also is a platform specific solution and would require a BSD host server and local workstation. The Windows Terminal Service [22] and Citrix ICA [23] allow for local storage devices to be accessible from applications running on Windows Terminal Service server. This solution is also platform-specific and would work only on Windows-based O/Ss. 31

4.5 Conclusion

The main advantage of the virtual CD-ROM lies primarily in access latency, ease of use and transparency, since it does not need manual intervention other that changing of the media. A user would utilize the virtual CD-ROM in an identical way as the physical CD-ROM; in other configurations, the user has to manually create an ISO image file for every CD-ROM or the device to be virtualized. Although the virtual remote CD-ROM performs slower than a physical CD- ROM, results show that its performance in a wide-area environment is slower by no more than 10% (and up to 195% faster) than alternative solutions in cases where physical device access is not possible. The core mechanisms employed by the virtual remote CD-ROM can also be used for virtualizing other read-only remote storage devices (e.g., floppy drives, zip drives and USB storage devices). For non-CD-ROM devices, a similar NFS-based server, which can additionally construct an ISO-9660 compliant table of contents for the file system stored in the device, could be used. Such virtual ISO image would be presented to the NFS client in a manner equivalent to the remote virtual CD-ROM of this technique; the server would then transform the lookups and reads of the virtual ISO image into appropriate reads for files from the devices. Additional applications of remote virtual devices include mobile computing [24], ubiquitous computing [25] and alternate interface access [26]. Mobile and ubiquitous computing scenarios can benefit from continuous access to a device even when users migrate and no longer have physical access to it. The concept of a universal remote console allows people with disabilities to remotely control devices from specially-equipped consoles. In this situation, the user always has physical access to the devices that are part of the console, but such devices should seamlessly interface with remote hosts (e.g., an ATM machine or a digital photo kiosk). CHAPTER 5 KERNEL DEVICE DRIVER 5.1 Introduction

This chapter explores a technique of device virtualization where a device driver is used for indirection. This technique supports remote transfer of audio streams generated by a Virtual Machine Monitor (VMM) to achieve network transparency for audio devices. The technique is based on the implementation of hosted I/O VMMs that intercept device I/O instructions executed by a “guest” O/S and emulate them through system calls processed by device drivers of a “host” O/S. The design consists of a virtual audio device driver that forwards sound streams to a user-level network server. Because (1) the virtual device intercepts audio data in an unprotected format (WAV), regardless of which application and file format are in use by the guest O/S, and (2) modern virtual machine-based systems already achieve performance levels that allow for real-time audio playback, there are important implications of machine and device virtualization on future system support for DRM-enabled media. To avoid the need for application recompilation and O/S modifications, the solution described creates a virtual remote sound device (and associated driver) which is attached to a hosted I/O VMM (e.g., VMware) and connects to a user-level network audio server. The resulting system is one where unmodified applications within the VM guest interface with a virtual audio hardware (e.g., a SoundBlaster compatible emulated device), and audio data is captured and transferred by the host virtual remote sound device in pulse code modulation (PCM/WAV) format. It supports a wide variety of “guest” O/Ss and applications that can drive a Sound Blaster device, and requires no modification from them.

32 33

The original intent of this design was to enable a higher degree of interactivity for network-computing systems based in VM execution environments, by making the sound system location and migration transparent. It is observed that it is possible for current systems to use machine and device virtualization for fair use [27] of audio media in a way that is transparent to an O/S and its applications (including the DRM-enabled [28] features that they implement). An important implication of this conclusion is that DRM- enabled applications in general-purpose computers need to be able to distinguish whether a machine is virtualized or not to prevent the use of similar techniques for unauthorized content copying in current and future systems. Some mechanisms that allow for such distinction in certain situations are presented here; a generic solution, however, needs to be investigated in light of proposed next-generation general-purpose systems that are slated to provide hardware extensions both for efficient virtualization, and for trusted computing bases. Experiments with the system are conducted to evaluate its functionality and performance. In a local-host environment, the system is able to capture arbitrary sound sources played by guest applications, send and store these as PCM/WAV audio files. Inspection of the audio output shows that, using current desktop VM implementations and a low-entry laptop system, the system delivers bandwidth sufficient to capture playback audio without loss (except for mili-second pauses at opening and closing of the virtual audio device). 5.2 Implementation

5.2.1 Architecture

The Remote Sound System consists of two parts: the Remote Sound Device Driver and a Remote Sound Server. The remote sound server is a TCP/IP based multi-threaded server which accepts audio data from the device driver. The driver connects to this server when the device is opened by the application and 34

Figure 5–1: Implementation of the remote sound system disconnects when the device is closed by the application. The device driver is based on ALSA (Advanced Linux Sound Architecture http://www.alsa-project.org) and plugs into the ALSA framework. It has been tested on the 2.4.21-0.13 kernel on Mandrake 9.1 Linux OS. Only raw audio data is transferred to the sound server; no control data (such as the IOCTL commands) and no mixer data (volume or balance) are currently processed. At the sound server the data is saved as a WAV file. The flow of data is shown in Figure 5–1. The VMM virtualizes the sound card for the VM, which may be running any operating system. The design has been tested with VMware Workstation 3.1.1 build-1790, a virtual Sound Blaster card and both Windows 2000 and Linux guest O/Ss. The sequence of events that allows the conversion of media played on the guest to a WAV file stored on the host is

1. An application running in the guest OS plays an audio clip.

2. The application converts the clip into PCM/WAV format. 35

3. The application writes the data to the audio device driver in the guest O/S.

4. The guest O/S then writes the data to the ports of the virtualized sound card (e.g., Sound Blaster virtual device).

5. All accesses to this virtualized device use privileged I/O instructions that are intercepted by the VMM. This includes output instructions to set up direct memory access (DMA) transfers of raw audio data to a device.

6. The VMM then transfers the data to the sound device driver on the host OS using the host’s system call interface.

7. The remote sound driver captures this data and transfers it to the remote sound server at the host.

8. The remote sound server saves this data as a WAV ﬁle.

5.2.2 Device Driver

The “Dummy” Sound card driver provided with the ALSA package was used as a basis for the Remote Sound Device Driver. Networking was added to the driver to enable it to access the Sound Server. TCP was used for the communication because of the need to maintain sessions, packet sequencing and avoid bookkeeping tasks such as retransmissions and reordering of the packets. For real time transmission in interactive applications UDP may be used instead. The main modifications made to the code were: adding the socket structure to the card structure and a flag to detect whether attribute information has already been sent. Communication is established whenever the remote sound device is opened by the application. The alternative to this would have been to establish communication when the driver is loaded but this would mean that it would be utilizing resources and maintaining the connection even when no media is being played. Initially the attribute information about the sound data - the number of channels, sampling rate and the bits per sample; are sent to the sound server. For every write to the audio device the playback copy procedure is called which in turn calls the remote send method to send the data to the server. Here the fact that all 36 the audio applications convert the data into WAV format aids in writing the Sound Server and the generation of the audio files. The present implementation connects to a well known port on the local host. 5.2.3 Sound Server

The Sound Server is a user space TCP server listening on a port which is known in the device driver. It is a multi-threaded server so that for every new connection a new process is forked which services that connection and saves the data being transferred into a WAV file. The forked thread first gets the attribute information about the sound data and stores it in a temporary buffer. After all the raw sound data has been transferred and the connection is closed it writes the header of the WAV file (the first 44 bytes of the file). It does this at the end because it has to write the size of the file also in the header. A unique file is created for every session, which corresponds to the music file being played in the VM or the application. 5.2.4 Quality of Audio output

The remote sound system implements digital copying of data. Theoretically there should be no loss of data, a behaviour observed when media is played on the host O/S using the remote sound driver. But when the media is played in the VM there are potential losses, which can be introduced by various components and factors as enumerated below:

1. The media player may apply ﬁlters before playing an audio clip (e.g., Windows media player converts a single channel audio ﬁle to a dual-channel one).

2. The load on the system when the media is being played may be high. The audio driver in the guest O/S would drop packets that have not been played by the deadline.

3. VM virtualization of audio device and interception of the audio data. A virtual machine diﬀers from an emulator in that it supports fast, native execution of non-privileged code (e.g., during the decompression of MP3 streams). However, privileged I/O instructions need to be emulated, and may 37

Figure 5–2: Output resulting from playing a 130s sound sample

require order-of-magnitude larger number of CPU cycles than native instructions do. The authors have observed that these overheads do not prevent the VM from playing real-time audio. In addition, VM-level optimizations can be employed to speed up the handling of virtual I/O devices. A virtual network interface can deliver throughput close to the physical machine for network sends over a fast Ethernet card: 90Mbit/s for 512-Byte TCP packets [18], a level of throughput higher than that demanded from a sound device.

4. The overhead of setting up the network connection, sending the attribute information and the fact that the application is in the process of reading the ﬁle when the sound device is opened, contributes to the initial load and hence the guest device driver may drop some audio data at the beginning of a ﬁle.

An experiment was carried out to observe the quality of music copied as follows. A sine wave sampled at 44100 kHz and of length 130 seconds was generated by Matlab and played in a Linux guest O/S. A sine wave was chosen to facilitate visual inspection of glitches, and the “sox” player was chosen since it is a program that does not apply any filter to a WAV file when playing it: it copies the file’s data to the sound device after sending the attribute information of the file to the sound driver. A patch of null bytes with duration of 30ms was observed 175ms before end- of-file from inspection of time-domain plots of the output file. A shorter silence is also observed at the beginning of the file, as illustrated in Figure 5–2. This result was reproducible across multiple runs - the “diff” tool reported no difference among these outputs. While the exact reason behind the occurrence of the silence is not 38 known to the authors, it may be due to the way in which the virtual audio device is opened and closed. The testing of this system was carried out on a laptop. The configuration is a modest one: AMD Athlon XP 1500+, 512 Mb RAM, 20 GB 4200rpm hard- disk(TOSHIBA MK2018GAP). If the tests would have been carried out on a more powerful system there might not be any glitches. Several songs were copied with no audible problems. The write to the file involves a number of copies from user space to kernel space and vice versa. In this implementation the number of copies as they happen in the guest O/S are:

1. Copy into the kernel (from VMM to remote sound driver).

2. Send across the network (from the remote sound driver to network).

3. Copy from the kernel to the user process (from the network sub system to remote sound server).

4. Copy again to kernel to write the ﬁle (remote sound server to a ﬁle).

There are several ways in which storage from the device driver to a file could have been carried out to reduce the overheads. For instance, the file may be created directly by the driver instead of transferring it over the network. This would have been efficient because the number of times the data has to be copied is once as opposed to 4 times in case of the remote sound solution. Since the primary goal of the design is to facilitate remote transfer of audio it has been implemented with the overheads mentioned above as tradeoffs for the flexibility obtained with the solution. 5.3 Applications of Remote Sound Transfer

5.3.1 Interactive Applications in Network Computing

Virtual Machines can be used for running interactive applications with several VMs hosted on the same server. The Remote Sound System can present an 39 individual sound card for every VM. To this end the Remote Sound card needs to be setup with the remote server’s host and port identiﬁcation (e.g., via a special IOCTL command). The remote host name can be made optional since the audio can be transferred to the local host and the user level server process then can act as a proxy. One of the issues with the user space remote sound server is that the data is copied from the kernel space to user space (socket receive) and then again back into kernel space (write to the sound driver). This can be avoided by keeping the remote sound server in the kernel and directly transferring the data to the sound device. However, this would make the remote sound server Linux-speciﬁc. 5.3.2 Fair Use of DRM-Enabled Media

With DRM-enabled media there are various restrictions on their use. Par- ticularly, transfer of media from one system to another and also rights such as copying of radio songs using a tape recorder as available in the analog world are not allowed. Using this system it is possible to copy media in another format for fair use and consequently, for playing media on non-supported systems. 5.4 Prevention of Illegal Copying

This section describes possible steps to prevent potential illegal copying of audio media through virtual/remote devices in existing systems. These techniques may be complemented by additional hardware support in future systems as discussed in Section 5. At the core of possible solutions to prevent unauthorized copy using this technique is the capability of detecting that the O/S is runnning on top of a virtual, rather than physical machine. If the Operating System can determine that it is running on a Virtual Machine then it may disable the playback of protected content or degrade the playback (e.g., via sampling down). The various techniques that can be used to detect that the system it is running on is a VM are: 40

5.4.1 Inspection of Hardware

Inspecting the system conﬁguration for “clues” of Virtual Machine presence, for example:

• The bios can contain the ID for the Virtual Machine Vendor.

• The hard disks and the CD-ROM drives have been virtualized and can suggest the presence of a VM.

• The pointing device and the display would have VM vendor speciﬁc information.

For instance, currently VMware provides a utility to detect whether it is running on a VM which can be used for this purpose. A malicious VM monitor may however attempt to conceal this information. 5.4.2 Detection Through the Use of Special Instructions

Idiosynchracies of VM implementation may allow for detection by running a certain sequence of instructions and observing the resulting state. For instance, VMware cannot be installed on an operating system already running under a VM. So a test along similar lines can determine whether the Operating System is running in a VM. However, in an architecture that allows for recursive virtualization [29], such as IBM z/VM (and potentially future generations of x86 systems based on recently-announced Intel plans for virtualization extensions), an ISA-based test may not be able to reveal the presence of a VM. 5.4.3 Detection Through Timing Analysis

A heuristic program that could utilize some known overheads of a VM in handling privileged operations. One such method is to use memory bound functions [30] which would utilize the known overhead in handling of memory allocation [6]. The idea would be to check the test results against a database of system performance. If the benchmark takes more than some threshold time the the media player can assume that it is running on a VM. 41

However, there is a potential of generating false positives or negatives. Fur- thermore, the process of the process of creating, updating and providing access to such databases may be substantially complex given the wide variety of system conﬁgurations possible. 5.5 Discussion: Impact of Future Technologies

This technique enables an application-transparent, legitimate functionality for audio-over-network in virtualized network computing systems. It also raises issues that need to be addressed by operating system designers and content providers of DRM-enabled media: O/Ss need to be able to determine that a DRM-enabled media player is not running on top of a VM to guarantee that data written to its drivers reaches the device unmodified (even if the drivers are signed and trusted by the O/S). Content providers need to be aware of the potential implications of virtualization to determine the desired functionality expected from applications and O/Ss they trust to play media. With current system configurations and performance it is possible to support virtualized audio devices as described here. Enhancements in system and virtualization performance may enable similar systems to emerge in the future to support other forms of media (e.g., DVD-quality video) to be captured. It is therefore important to understand how techniques similar to the one presented here can be deployed in a way that allows for fair use and prevents illegal use. An emerging technology that may address some of the issues raised here is the Next Generation Secure Computing Base (NGSCB [31, 32, 33]). While there is limited documentation available, and no commercial implementation of the hardware Security Software Component (SSC) nor the software “Nexus” to date, the following discussion is based on key aspects of current NGSCB specifications. NGSCB relies on capabilities provided by a hardware Trusted Platform Mod- ule (TPM) to provide specialized functions such as storing unique private/public 42 key pairs generated and signed by a manufacturer, generating cryptographic hashes and storing them in write-once memory, and supporting curtained memory that can only be accessed by a system’s unique “Nexus” One can expect these capabilities to be exposed to software via additions to a processor’s instruction set or via an I/O interface. The authors believe that existing techniques for instruction trapping (possibly complemented by binary pre-scanning and translation, as done by x86-based VMs) will allow a VMM to also virtualize TPM devices or processor extensions. However, the virtualized TPM will not have the credentials for the private key of the physical hardware manufacturer, but that of the VMM manufacturer. In principle, these techniques can then be used to determine whether, for example, a “guest” O/S is running on top of a VMM during attestation, and policies can be established for applications to deal with such scenario. For instance, a DRM provider may allow the playback of a track if the TPM is signed by a hardware manufacturer, but not by a VMM software developer. If the DRM provider finds the above policy to be restrictive, because it prevents legitimate usage in a system that does not have a virtualization layer that intercepts and stores protected content, it may decide to accept VMM vendor certificates. However, this would imply trust that the VMM vendor can fulfil requirements of a trusted platform. This can prove difficult, especially in environments with hosted VMMs and if recursive virtualization is possible. The above scenario illustrates a case where the VMM is not malicious and uses its certificates to sign a virtualized TPM. A malicious user able to break hardware tamper resistance mechanisms to obtain hardware-signed keys, and install them in the virtualized TMP of a malicious VMM may be able to support NGSCB-enabled guests and transparently capture data from a virtualized device. Although hardware tampering may be a non-trivial process, once obtained these 43 keys can potentially be distributed and used by other virtual TPM systems, until a revocation mechanism is able to recognize the compromised key. Given the lack of actual hardware implementations and attestation/revocation mechanisms it is difficult to assert the difficulty involved in realizing the above scenario, beyond what has been speculated. The discussion illustrates, however, that virtualization should be taken into consideration in the design of these systems. In principle, virtual machines provide “an efficient, isolated duplicate of a real machine [...] with the possible exception of differences caused by timing dependen- cies” [29]; hence systems that need to differentiate VM from non-VM environments may need to resort to timing analysis. The physical clock as presented to the VM “guest” is virtualized by the VMM, So the VMM can force or speedup the signals given to the clock trap handler routine of the VM guest. So the timing analysis can also be defeated if it depends only on one kind of benchmark. A modification to this technique would be to use two kinds of benchmarks: (1) A benchmark that would perform the same on the two systems (2) A benchmark that uses known overheads of VMM. The idea would then be to compare these two benchmarks, but this would be a hueristic only. 5.6 Related Work

There are several systems that play sound over the network. Only the systems that allow several diﬀerent applications to utilize this feature are compared; systems that implement streaming solutions which work only with closed-source media players are not considered in the discussion. The Windows Interface Client by Citrix has a capability of transferring the sound to the client on which the “wﬁca” application is opened. This is available only for the Windows operating system and requires the use of Terminal Server Capabilities. 44

Rplay (http://rplay.doit.org/) is a network audio system that allows sounds to be played to and from local and remote Unix systems over UDP or TCP. The Network Audio System NAS (http://radscan.com/nas.html) is a network transparent client/server audio transport system and is supposed to be the audio equivalent of an X server. Audioﬁle[34] is also a similar system; however, these systems require that the applications be compiled using the API and linked with a custom library. In contrast, the technique presented here application transparent. Also some of the systems need the knowledge of the audio formats to be encoded which is not needed in the Remote Audio System. Audio Forwarder (http://www.osc.edu/˜ pw/afwd/) is an audio forwarding system which runs on machines without built in sound cards. It does not interpret the audio being transferred nor store it anywhere. This runs only on systems which do not have a audio driver already present. In contrast, the Remote Sound System would work even if another driver is present and since it is based on ALSA any number of remote sound cards can be inserted for each VM guest. 5.7 Conclusions

This technique shows the feasibility of audio virtualization to achieve network transparency. It also shows virtualization can be a means of circumvention and/or fair use of DRM-enabled media. Similar techniques of using device drivers could be used for virtualizing other peripherals like the USB, serial and parallel ports. The present generation of DRM enabled players as available on current operating systems are vulnerable to the technique described here. Though the current offerings of DRM media allow songs to be converted into an audio CD- ROM so someone could possibly rip the CD into WAV and MP3 formats, the fact that the WAV file is obtained just by playing the media makes implementation of other business plans (e.g., offering inexpensive songs with added restrictions like 45 playable only a certain number of times or no/restricted option for creating an audio CD-ROM) impossible to implement in the presence of this technique. A “guest” device-driver based approach along the lines of the technique mentioned here can also be used for transferring of audio data and potentially copying of audio. However, it would be guest-specific and may not work if the guest requires device driver signing. This technique shows that it is key for DRM-enabled applications to detect whether they run on a physical or virtual machine environment. Proposed hardware and software extensions to support trusted computing bases can potentially be used by applications to make such a distinction between a system running on top of physical hardware or non-malicious virtual machines. However, further analysis of hardware specifications are needed to address the question of whether such extensions will be virtualizable. It may then become possible for malicious virtual machines to pose as physical machine duplicates and intercept data in the path between a signed device driver and the device itself. CHAPTER 6 CONCLUSIONS AND FUTURE WORK This chapter discusses future work, enhancements to the techniques discussed in the previous chapters and new techniques for virtualization and the conclusions drawn from the experience of implementing the techniques described in the previous Chapters. 6.1 Conclusion

This thesis presented three techniques for device virtualization, device virtualization using system call tracing, storage device virtualization using ISO 9660 image and NFS, and virtualization at the device driver level. These were success- fully designed, implemented and their performance was measured. For the virtual ISO solution, experimental results in WAN environment show that in the absence of physical access from a user to the CD-ROM device, the performance of virtual CD-ROM ranges from 10% slower to 195% faster than alternative NFS-based and SCP-based solutions. For the remote sound system, when playing a 130s sound sample, two patches of null data (silence) with duration of tens of miliseconds are observed at the begining and end of ﬁle. The techniques implement low-level virtualization that can be used to support a paradigm where devices are made accessible transparently over the network. With such low-level support, middleware in the form of device virtualization services can be conveived to address the applications and requirements described in Chapter 2. 6.2 Future Work

This section discusses the work that can be done to enhance the techniques already discussed in the previous chapters, new techniques that can be used

46 47 for virtualization of devices, and systems that can be built on top of a device virtualization layer. 6.2.1 Virtualization Using Interposition of Libc

This technique would be similar to the system call tracing, but instead of tracing a process, we would create a new libc to be used by the application. A similar technique is used in Condor [35] for checkpointing and process migration. This libc would be loaded before the system libc is loaded and the application would be making use of modiﬁed library calls. We take advantage of the fact that the system calls that the application makes do not go the kernel directly, but are library calls provided in the libc. The parameters are actually setup in the registers and the trap routine is called. 6.2.2 Filtering Mechanisms for Remote Sound System

The user space design allows the Sound Server to transfer and/or ﬁlter the data to a remote host at the user level. This transformation would be needed if the host server and the user’s workstation are connected by a low bandwidth data pipe and there is a need to maintain the quality of service; ﬁlters can be applied to reduce the sampling rate or convert the data into lossy encoded formats like MP3[36] or Ogg Vorbis (http://www.vorbis.com). There are essentially two ways this transfer can take place.

• The audio data can directly be transferred to the user’s workstation. The disadvantage of this approach is that it would utilize a large amount of available bandwidth and there could be glitches when the data does not reach the server because of network congestion. If real-time playback is need then UDP should be used so that the packets that do not arrive on time or late according to timing considerations can be discarded at the server’s end. The sound data can be ﬁltered in the Remote Sound Driver so that lower quality data can be sent (i.e., CD quality data can be converted into radio quality data before sending to the sound server).

• The audio data can be stored in a buﬀer in a user level proxy (remote sound server can be used as a proxy) on the host server and then suitable ﬁlters can be applied to it for reducing the size. The downside would be the 48

considerable overhead of applying the ﬁlters and also the overhead of copying the data several times from kernel space to user space and back. 6.2.3 Virtualization of Block Devices as USB Memory

The virtual ISO technique discussed in chapter 4 allows devices to be repre- sented as a read-only medium. A CD-RW solution cannot be provided currently by existing VMMs such as VMware. To offer a writable device abstraction, a USB memory based system can be provided. For this a USB kernel module would need to be built which acts like a proxy between the USB bus and the middleware. The middleware would have the following responsibilities: (1) Convert the Remote Device into an USB memory abstraction. (2) Send signals to the kernel module to emulate USB memory, and (3) Buffer the data if the remote device expects a fixed size of data or buffered data. 6.2.4 Sound Capture Mechanism for Remote Sound

The current implementation of the remote sound system is able to transfer audio from a VM located remotely, to the user’s workstation. It should also be capable of transferring the microphone input from the user’s workstation to the VM. This can be achieved by enhancing the remote sound system. 6.2.5 Applications Using Virtual Devices

Chapter 2 introduced two applications (Network Computing systems and ubiquitous computing) that can be enhanced if there exists a middleware capable of device virtualization. Such a service could be developed to measure the scalability and performance of virtual devices. REFERENCES [1] Robert P. Goldberg. Survey of Virtual Machine Research. IEEE Computer Magazine, 7(6):34–45, 1974. [2] Andrew S Tanenbaum and Maarten van Steen. Distributed Systems Principles and paradigms. Prentice Hall, 2002. [3] Tristan Richardson, Quentin Staﬀord-Fraser, Kenneth R. Wood, and Andy Hopper. Virtual network computing. IEEE Internet Computing, 2(1):33–38, 1998. [4] I. Foster, C. Kesselman, and S. Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organization. Journal of Supercomputer Applications, 15(3), 2001. [5] R. J. Creasy. The Origin of the VM/370 Time-Sharing System. IBM Journal of Resarch and Development, 25(5):pp483–490, 1981. [6] Carl A Waldspurger. Memory Resource Management in VMware ESX Server. Proceedings of the 5th Symposium of Operating Systems Design and Implementation, December 2002. [7] Renato J Figueiredo, Peter A Dinda, and Jose A. B. Fortes. A Case for Grid Computing on Virtual Machines. Proceedings of International Conference on Distributed Computing Systems, May 2003. [8] Renato J Figueiredo, Nirav H Kapadia, and Jose A. B. Fortes. The PUNCH Virtual File System: Seamless Access to Decentralized Storage Services in a Computational Grid. Tenth IEEE International Symposium on High Performance Distributed Computing, August 2001. [9] M. Kozuch and M. Satyanarayanan. Internet Suspend Resume. Proceedings of the Workshop on Mobile Computing Systems and Applications, pages 40–46, June 2003. [10] Pradeep Padala. Playing with ptrace, Part I. Linux Journal, 103:78–85, November 2002. [11] Pradeep Padala. Playing with ptrace, Part II. Linux Journal, 104:86–91, December 2002.

49 50

[12] Albert D. Alexandrov, Maximilian Ibel, Klaus E. Schauser, and Chris J. Scheiman. Extending the Operating System at the User-Level: the Ufo Global File System. pages 77–90, 1997. [13] David A. Wagner. Janus: An Approach for Confinement of Untrusted Applications. Technical Report CSD-99-1056, 12, 1999. [14] Jeff Dike. A user-mode port of the Linux kernel. October 2000. [15] James E. Smith. An Ooverview of Virtual Machine Architecture. White Paper, University of Wisconsin, October 2001. [16] Tal Garfinkel. Traps and Pitfalls: Practical Problems in in System Call Interposition Based Security Tools. February 2003. [17] Richard E. Newman-Wolfe, C. L. Ramirez, Harsha K. Pelimuhandiram, M. Montes, M. L. Webb, and D. L. Wilson. A Brief Overview of the DCS Distributed Conferencing System. pages 437–452, 1991. [18] Jeremy Sugerman, Ganesh Venkitchalam, and Beng-Hong Lim. Virtualizing I/O devices on VMware Workstation’s Hosted Virtual Machine Monitor. Proceedings of the 2001 USENIX Annual Technical Conference, Boston, MA, US, June 2001. [19] Brent Callaghan. NFS - NFS Illustrated. Addison-Wesley, December 1999. [20] P. T. Breuer, A. M. Lopez, and A. G. Ares. The network block device. Linux Journal, page (73), May 2000. [21] Klaus Knopper. Building a self contained auto-configuring Linux system on an iso9660 filesystem. Annual Linux Showcase, 2000. [22] Windows 2000 Terminal Services: An Integrated, Service-based Computing Solution. Technical White Paper. [23] Mike Bursell and Jon Rolls. Citrix Metaframe for UNIX Operating System and ICA: Performance Characteristics. Technical White Paper. [24] Zhenyu Wang and David Garlan. Task-Driven Computing. Technical Report CMU-CS-00-154, Computer Science Department, Carnegie Mellon University, May 2000. [25] Roy Want, Bill Schilit, Norman Adams, Rich Gold, Karin Petersen, John Ellis, David Goldberg, and Mark Weiser. The PARCTAB Ubiquitous Computing Experiment. Technical Report CSL-95-1, Xerox Palo Alto Research Center, March 1995. 51

[26] Gottfried Zimmermann, Gregg Vanderheiden, and Al Gilman. Universal Remote Console - Prototyping the Alternate Interface access standard. Center On Disabilities Technology and Persons with Disabilities Conference, 2000. [27] Pamela Samuelson. DRM {AND, OR, VS.} the Law. Communications of the ACM, 46:4, April 2003. [28] Qiong Liu, Reihaneh Safavi-Naini, and Nicholas Paul Sheppard. Digital Rights Management for Content Distribution. Australasian Information Security Workshop, 21, 2003. [29] G. Popek and R. Goldberg. Requirements for Virtualizable Third Generation Architectures. Communication of the ACM, 17(7), July 1974. [30] Cynthia Dwork, Andrew Goldberg, and Moni Naor. On Memory-Bound Functions for Fighting Spam. Proceedings of Crypto 03, 2729:426–444, August 2003. [31] Microsoft. Security Model for the Next-Generation Secure Computing Base. Windows Platform Design Notes, 2003. [32] Microsoft. NGSCB: Trusted Computing Base and Software Authentication. Windows Platform Design Notes, 2003. [33] Ahmad-Reza Sadeghi and Christian Stüble. Bridging the Gap between TCPA/Palladium and Personal Security. Technical report, Saarland University, 2003. [34] Thomas M. Levergood, Andrew C. Payne, James Gettys, G. Winfield Treese, and Lawrence C. Stewart. Audiofile: A Network-Transparent System for Distributed Audio Applications. Proceedings of the USENIX Summer Conference, pages 219–236, June 1993. [35] Michael Litzkow and Miron Livny. Supporting checkpointing and process migration outside the UNIX kernel. In Proceedings of the Winter 1992 USENIX Conference, pages 283–290, San Francisco, CA, January 1992. [36] Karlheinz Brandenburg. MP3 and AAC Explained. AES 17th International Conference on High Quality Audio Encoding, 2001. BIOGRAPHICAL SKETCH Ninad Ghodke was born on April 6th, 1975 in Pune, Maharashtra, India. He received his undergraduate degree, Bachelors of Engineering, Electronics Engineering, from University of Mumbai, Mumbai, India, in July 1996. Ninad’s interests primarily lie in distributed, virtual and pervasive computing. His work in the software industry has primarily been in systems programming on various flavors of Unix and security. He joined University of Florida in Fall 2002 to pursue his Masters Degree. More details about him can be found at http://www.cise.ufl.edu/~nghodke