VIRTUAL MACHINES
A Virtualization Infrastructure that Supports Pervasive Computing Smartphones might well be the most powerful pervasive embedded device and the ideal platform for pervasive computing. Virtualization technology offers a practical means for the widespread deployment of the necessary middleware.
V
Larry Rudolph VMware
2
PER VA SI V E computing
ir t ualization tech nolog y— as applied in embedded devices such as mobile smartphones— is a practical means for the widespread deployment of pervasive computing applications. As anyone who reads this magazine knows, pervasive computing is all about moving beyond the desktop PC to the computational and digital devices that surround us in our daily lives. The “application” is dynamically spread over multiple, physically separate I/O devices, with data streaming between them. These devices are part of or controlled by one or more computers containing the middleware that provides the ability to use I/O devices on remote machines. Deploying pervasive computing applications “in the wild” requires installation of middleware on a range of machines in a safe, secure, and trusted way with minimum effort. This is a challenge as the machines are often embedded computers with any one of a wide range of I/O devices, runtime libraries, operating systems, and outdated software components without support for remote middleware installation. Owners are reluctant to permit remote use of
their devices for fear of potential adverse effects on the machine’s primary function. As if that weren’t difficult enough, the embedded computer or machine that represents the user isn’t a pseudo mobile laptop computer as in many pervasive computing demonstrations; rather, it’s most likely a mobile smartphone that often has a highly restrictive programming environment. There is reason to believe that the situation will improve. The embedded computers that control the devices in the environment are becoming more powerful and might soon be smartphones in disguise. Smartphones are true computers capable of interacting with, controlling, and coordinating other devices in the environment. They’re rich in sensors and actuators and are thus emerging as an ideal pervasive computing building block. For most smartphones, only handset manufacturers and cell network operators can modify the operating system, and it seems unlikely that they’ll install pervasive computing middleware in the foreseeable future. The hope lies in using virtualization technology with features that enable the transparent use of remote I/O resources—a fundamental need in pervasive computing. This article discusses some of these features.
Published by the IEEE CS ■ 1536-1268/09/$26.00 © 2009 IEEE
Figure 1. Two virtual phones within a single handset. The handset on the left contains two virtual phones: a corporate one under the IT department’s control and a personal one under the user’s control. Although they execute within the same handset, these phones are isolated from each other. The personal virtual machine is encapsulated as a single file that can migrate from the corporate handset to a separate, personal one.
Daily handset Corporate phone
Weekend handset
Personal phone
Background A virtualized smartphone or virtualized embedded computer is a physical computer with a low-level software layer on top of which a virtual phone executes. There is a decoupling of software from hardware in which the CPU, memory, and devices appear as if they were real to the software executing in the virtual phone. A virtual phone runs the exact same software as would run on a physical handset; in this way, multiple virtual phones, perhaps running different operating systems, can run on the same handset, each isolated from the other. If you trust this isolation, you are likely to believe that middleware running in its own virtual phone won’t compromise other smartphone operations. Virtualization technology has ignored lower-end machines for various reasons. The CPU in most current virtualized computers, for example, is based on the Intel x86 instruction set, whereas in many smartphones and embedded computers it’s based on ARM instruction sets (http://arm.com/ products/CPUs/index.html). These two architectures are sufficiently different that they require a complete redevelopment of any virtualization software. Moreover, virtualization incurs some overhead in both performance and storage, and smartphones execute very close to their resource limits and can’t withstand any performance degradation. Fortunately, this situation is changing: smartphones are increasingly provi-
OCTOBER–DECEMBER 2009
sioned to handle many available thirdparty applications, and academic studies as well as several industrial efforts have identified several potential revenue sources for virtualized phones (www. ok-labs.com, www.virtuallogix.com, and www.vmware.com/technology/ mobile/index.html).1,2 In addition to isolation, virtualization’s other main benefits of encapsulation and interposition are useful in the mobile space, although for slightly different reasons than in the desktop and server markets.3 Encapsulation makes it easy to deploy middleware on a wide variety of platforms. Interposition lets a pervasive computing application use and harvest remote devices in the local environment; it refers to the fact that all the virtual machine I/O actions are mediated by virtualization software, which can inspect, modify, and redirect these actions. Isolation Several virtual phones can execute on the same machine, yet remain protected from each other as if they were executing on separate machines—a feature that has several potential benefits. It’s especially important in mobile phones to protect the baseband stack— the part that interacts with the cellular network. An application executing in a virtual phone might somehow compromise the operating system in that
virtual phone; however, because of isolation, it can’t compromise the baseband stack. Indeed, many (nonvirtualized) smartphones currently have two distinct processor chips to provide such isolation, with trusted software burned into the ROM controlling one of the processors. Multicore chips and higher-capacity single cores have led to all these functions combined onto a single chip, with virtualization technology as a way to keep them isolated. Many executives routinely carry two phones because of isolation, one for business and the other for personal use. The corporate phone might contain sensitive emails and documents because it has direct virtual private network (VPN) access to the corporate network. Because the company owns this phone, its management is under the IT department’s control; IT personnel dictate security settings, control which applications employees install on it, track communications (such as email, text messages, and phone calls), and encrypt data on the device. A personal phone often has a few of these restrictions, but it’s under the user’s control; he or she might opt for the convenience of riskier operation. As Figure 1 shows, a single handset with virtualization technology can simultaneously support both types of phones. Rather than supplying a corporate phone to all employees, the IT
PER VA SI V E computing
3
VIRTUAL MACHINES
department can install a virtual phone completely under its control within an employee’s virtualization-enabled personal phone. Encapsulation A virtual phone’s entire state can be encapsulated in a single file, a feature that provides checkpointing but also enables deployment and migration. It’s possible to present a standard virtual hardware platform independent from
phones concurrently executing, so the virtualization system must multiplex access to each actual device. Exactly how the multiplexing works depends on the device, of course—some devices can be shared (such as a vibrating battery), whereas others demand exclusive accesses (such as a keyboard). The multiplexor acts something like a network address translator (NAT) as it must route input data to the appropriate destination. Note that the user might have
Pervasive computing applications can benefit from capabilities such as remote device usage and remote execution, which provide privacy, security, and ease of deployment. the actual physical hardware platform so that a virtual phone can execute on any such virtualized physical handset. Many other embedded devices, such as handheld GPS devices, set-top boxes, and digital cameras, have hardware configurations similar to mobile phones—a virtual phone could therefore migrate to such devices as well. One extreme form of encapsulation is a virtual appliance, an application that executes in a dedicated virtual phone that contains “just enough” operating system for that application to run. The promise of virtual appliances is that they make applications easier to deploy: very little is assumed about the platform except that is can support the minimal set of virtual devices a particular virtual appliance requires. Interpositioning A virtual phone has a set of virtual devices; the phone’s operating system interacts with these devices through its device drivers. These virtual devices are software that emulates device behavior and communicates with the host’s device drivers, which in turn interact with the real devices. A handset can have several virtual
4
PER VA SI V E computing
to take action to allocate a device exclusively to a particular virtual phone, for example, a Bluetooth device. Similarly, explicit action might be required when a user attempts to use a remote device or permit a remote handset to use a local device. These multiplexors are instances of a device stream transformer. Another example is a transformer that routes communications from an emulated device to a physically remote machine. The collection of filters, multiplexors, and device selectors and their interconnection structure are referred to as a transformer network.
The Challenge With so many pervasive computing applications available, it’s helpful to consider just a few representative ones that can assume a role for mobile phones even though other platforms are possible as well. The following two examples involve communication and collaboration between distinct devices: r Alice is creating a complex symphony on her phone in a coffee shop, but her battery is dying. As she taps the cash register with her phone, the register’s powerful process takes over the
phone’s resource-consuming computations. Her good friend Bob walks in, and after a few seconds, he hears Alice’s live composition through the headphones attached to his smartphone. r The gang has just sat down at its favorite restaurant, and Debbie decides she wants a group picture. She gives the waiter her cell-phone camera and tells everyone to gather around. After he takes the picture, everyone pushes a few buttons on their own phones and engages their own cameras to magically capture the picture taken with Debbie’s phone. In each situation, computers communicate and use nearby peripheral devices. The pervasiveness comes about by dynamically enabling physically proximate computers to interact in an ad hoc manner. Alice might be happy to let Bob hear her music but not to see her messages, and Bob certainly doesn’t want Alice to hear his phone conversations with his new girlfriend. Debbie’s happy to share the group photo but not the pictures she took yesterday. In other words, permission to use some peripherals is more likely to be granted if it’s under the owner’s control and causes no ill effects. These types of pervasive computing applications can benefit from additional capabilities—such as remote device usage and remote execution— that provide sufficient protection, privacy, security, and ease of deployment. Remote access to devices isn’t new (the X Window4 system is probably the most successful early example), nor is remote execution of code on another computer (for example, via remote procedure call, RPC5). Indeed, we’ve all seen these scenarios demonstrated multiple times and places, and over many years, albeit with desktop computers, laptops, or even handheld computers. However, despite all the advances in device technology, such pervasive computing scenarios still await a practical solution.
www.computer.org/pervasive
How Virtualization Can Help Alice and the Gang Let’s see how virtualization might support the sample scenarios just described. The virtual machine on Alice’s phone can migrate to the cash register, thereby reducing the drain on her battery. Alice still interacts with the phone, but the audio output that’s now transmitted from the register to her phone can be multicast to Bob’s phone using the interpositioning feature. Interposition in Debbie’s phone makes the image that her camera captured available to her friends’ phones; likewise, interposition in her friends’ phones also fools each device into believing that it took the picture, not Debbie’s camera. In other words, each friend snaps the virtual camera in his or her virtual phone and receives a—possibly different but actual—image captured by Debbie’s physical camera. Where’s the Middleware? Pervasive computing middleware provides services such as finding nearby devices and making resources available to others. However, the basic question is where should the middleware reside? The choices are at the application or user level, within the operating system, or at the virtualization layer. Although the first two have their advantages, the latter option might be the most practical, assuming virtualization is present in most handsets and embedded devices. At the user level. User-level applications have access to devices and networking, making them a natural candidate for middleware. However, it isn’t likely that developers will rewrite all their applications to explicitly check and, when available, use these remote devices— perhaps a particular application or two, but not all of them. However, it’s possible to modify a fully software-based virtual machine’s runtime system—for example, the Java Virtual Machine (JVM) could be modified to remote particular devices. In
OCTOBER–DECEMBER 2009
this case, all applications that execute within the JVM need not be modified, but non-Java applications can still access the local devices. A JVM doesn’t present a complete software abstraction of a phone’s hardware, but rather a higher level of abstraction. Consider, for example, the group camera use case. An application on one phone takes the picture and advertises its availability over Bluetooth6 or a local ad hoc Wi-Fi network. All the other phones have an application that searches for this service, registers the device, and receives the picture when available. Of course, to actually communicate requires an authentication mechanism to ensure that the pictures are only sent to those in the group. Unfortunately, other camera application features aren’t similarly available—for example, some GPS-enabled phones tag images, whereas others might have the ability to add notes directly to the picture. An application that merely fetches an image from a remote location might not be able to exploit such sophisticated applications. At the operating system level. An alter-
native approach is to directly modify an operating system and its device drivers so that the applications need not know
actual devices, and remote devices can use this functionality. Naturally, it isn’t a good idea to allow arbitrary third-party software to be inserted into the virtualization system because it must be the most secure and reliable software in the system. Fortunately, we only require some combination of enabling or disabling some standard transformers and multiplexors within the virtualization layer. The more specialized user-level software handles the specific application needs. An appropriately designed transformer network, for example, allows incoming control to continue in either the forward or reverse direction. Each transformer has a set of function pointers specifying the next step in the flow, and the logic inside the management software can tell the transformer to remote a device, multicast it with data, or use an actual device.
Putting the Pieces Together Pervasive computing middleware in a virtualized device is partly implemented at the user level and partly in the trusted virtualization layer (see Figure 2). The user-level software might be best implemented as a virtual appliance so that it only affects the data streams for particular devices. For this
It isn’t likely that developers will rewrite all their applications to explicitly check and, when available, use these remote devices. about remote devices. However, it’s a challenge to modify operating systems: many mobile and embedded devices simply don’t allow it, or the system must be signed, and signing keys aren’t readily available. Unlike personal computers, you can’t install a new operating system on a phone. At the virtualization level. The virtu-
alization system already controls the data streams between emulated and
article’s purposes, let’s call this PerCom-VA. A machine can contain multiple instances and versions depending on the particular pervasive computing application; this discussion assumes a single one. The virtualization layer support consists of a transformation network and a method to route data streams to and from the PerCom-VA. The transformer network can be configured at boot time or dynamically configured, provided
PER VA SI V E computing
5
VIRTUAL MACHINES
VM
VM
Percom virtual appliance
Guest Apps Guest OS
Management server
Guest device driver
Guest device driver
Device emulator
Management client
Guest device driver
Device emulator Device emulator
Transformer
Transformational network
Device driver
Device driver
Device
Device
Virtualization software
any affected streams are quiescent during the reconfiguration. The transformers themselves are all trusted software. In and of itself, PerCom-VA does very little and is only useful when the virtualization layer explicitly directs I/O device streams to flow through it. Its installation is thus more likely to be acceptable to the owner. Moreover, the same virtual appliance can execute on any device that has the virtualization infrastructure, regardless of the host machine’s operating system or runtime libraries. A machine that contains PerComVA will be able to make its I/O devices available to any other machine with a compatible PerCom-VA. The I/O stream passes between machines over a Bluetooth, Wi-Fi, or some other wireless communication device, which is akin to a virtual network computer,7 remote desktop, GoToMyPC, or even X11 remote windows. PerCom-VA, however, will do this in a way that’s transparent to the operating system and the applications in a virtual phone or virtual machine. It’s natural that a device’s owner will have ultimate control over how it and
6
PER VA SI V E computing
its components are used; equally obvious is that an altruistic owner shouldn’t suffer. Let’s look at how to install PerCom-VA and control the transformer network. Management Details A machine can either install PerComVA itself from a central, universally accessible repository or receive a copy from a nearby machine that initiated the pervasive computing application. Virtualization, in theory, provides stronger isolation than processes, but it’s still likely that each PerCom-VA will be signed. Within a single machine, the biggest challenges are who controls the I/O stream and how much trust is required. The path between an I/O device and PerCom-VA isn’t easy to protect. Even with complete faith in the virtualization software and device drivers contained therein, it’s still possible that an I/O device stream is directed to one PerCom-VA instance before reaching the intended PerCom-VA. Presumably, the transformation network can tag each packet with its last entry, but a stream could pass through many vir-
Figure 2. Virtualized embedded machine. The structure contains trusted software that can reroute I/O device streams. Management software, either trusted remote code or explicit user actions, controls the rerouting. A rerouted data stream flows through a virtual appliance that contains thirdparty code for the specific pervasive computing application.
tual appliances. A further complication involves several remote machines simultaneously using shared devices. The level of isolation and protection required isn’t clear—for example, should a PerCom-VA be allowed to know of this sharing? Moreover, some monitoring is needed to avoid a circular chain that might result when the same data stream flows through more than one remote machine. Inserting, deleting, modifying, enabling, or disabling a transformer is a serious operation because it compromises the entire machine’s security, isolation, integrity, and reliability. The challenges are similar to those in the Denali project,8 which let programmers interpose on and modify events at the virtual architecture level in an extensible and programmable fashion. However, the limited resources in a mobile and embedded space require a much lighter-weight solution, which should be possible because the interposition is limited to device flows and not arbitrary virtual machine monitor events. Issues Creating an efficient mechanism that addresses isolation and security concerns while making remote use of I/O devices easy for users and developers is still an open problem. Passwords and group access rights are the obvious awkward initial solutions to security. Users must be able to easily and clearly enable and disable remote sharing of resources, giving permission to remote devices as well as getting access to them. One step in this direction is
www.computer.org/pervasive
the AUTHOR
presenting information about nearby devices to users with a graphical interface and a join-the-dots metaphor.9 Limited screen area, imprecise user input devices, limited attention spans, and the fact that many smartphone users are technically naive are just a few of the remaining challenges.
OCTOBER–DECEMBER 2009
even be cloned can reduce user effort in keeping such devices coherent. Virtualization technology is now present in servers and personal computers; it’s only a matter of time before mobile handsets and other nontrivial embedded computers embrace it.
REFERENCES 1. L.P. Cox and P.M. Chen, “Pocket Hypervisors: Opportunities and Challenges,” Proc. Mobile Computing Systems and Applications, IEEE CS Press, 2007, pp. 46–50. 2. D.R. Ferstay, Fast Secure Virtualization for the ARM Platform, master’s thesis, Computer Science Dept., Univ. British Columbia, 2006. 3. M. Rosenblum and T. Garfinkel, “Virtual Machine Monitors: Current Technology and Future Trends,” Computer, vol. 38, no. 5, 2005, pp. 39–47. 4. R.W. Scheier and J. Gettys, “The X Window System,” ACM Trans. Graphics, vol. 5, no. 2, 1986, pp. 79–109. 5. J.E. White, “A High-Level Framework for Network-Based Resource Sharing,” Proc. Nat’l Computer Conf. and Exposition, ACM Press, 1976, pp. 561–570. 6. A.S. Huang and L. Rudolph, Bluetooth
Essentials for Programmers, Cambridge Univ. Press, 2007. 7. T. Richardson et al., “Virtual Network Computing,” IEEE Internet Computing, vol. 2, no. 1, 1998, pp. 33–38. 8. A. Whitaker et al., “Constructing Services with Interposable Virtual Hardware,” Proc. 1st Symp. Networked Systems Design and Implementation, Advanced Computing Systems Association, 2004, pp. 169–182. 9. R. Want et al., “Dynamic Composable Computing,” Proc. HotMobile 2008, ACM Press, 2008, pp. 17–21. 10. E. Kohler et al., “The Click Modular Router,” ACM Trans. Computer Systems, vol. 18, no. 3, 2000, pp. 263–297. 11. B.-G. Chun and P. Maniatis, “Augmented Smartphone Applications through Clone Cloud Execution,” Proc. 12th Workshop Hot Topics in Operating Systems, Advanced Computing Systems Association, 2009; www.usenix.org/event/ hotos09/tech/full_papers/chun/chun.pdf. 12. K.C. Barr and K. Asanovic, “EnergyAware Lossless Data Compression,” ACM Trans. Computer Systems, vol. 24, no. 3, 2006, pp. 250–291. For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/csdl.
Questions? Comments? Email
S
o far, research in device stream control and low-overhead, dynamic interpositioning of fi lters, transformers, and redirectors is mostly specific to particular operating systems and nonembedded computing platforms.10 Because pervasive computing applications also use devices embedded in the environment and in our pockets, it’s time for a more general mechanism. The biggest differences between mobile phones and their larger counterparts are their extreme resource limitations and location awareness. Mobile phone users must constantly worry about power and battery life; memory is limited as well. In a pervasive computing environment, it might be advantageous to offload computation11 to a non-battery device to use memory and CPU freely, but wireless transmission itself consumes a lot of power—sometimes, the transmission of one byte can require a thousand times more energy than a single 32-bit computation.12 Adapting to local conditions requires constant evaluation of such trade-offs. Today’s mobile phones have cameras, but it won’t be long before cameras contain mobile phones. Device manufacturers are already adding GPS and networking functions to cameras, as well as touchscreens with full computational capabilities. Mobile phones and PDAs can act as ebook readers, whereas dedicated ebook readers have cellular network connectivity—some even run Linux. The list goes on, and the diversity of convergent devices implies that many people will have many more devices than they already do. A virtual machine that can migrate or
Larry Rudolph is senior staff engineer at VMware. His research interests include high-performance computing; optical interconnection networks; and pervasive, human-centric mobile computing. Rudolph has a PhD in computer science from the Courant Institute, NYU. Contact him at rudolph@vmware. com.
[email protected] PER VA SI V E computing
7
