Cells: a Virtual Mobile Smartphone Architecture
Total Page：16
File Type：pdf, Size：1020Kb
Cells: A Virtual Mobile Smartphone Architecture Jeremy Andrus, Christoffer Dall, Alexander Van’t Hof, Oren Laadan, and Jason Nieh fjeremya, cdall, alexvh, orenl, [email protected] Department of Computer Science, Columbia University Technical Report CUCS-022-11 May 2011 Abstract of corrupting it or even leaking it to third parties [41]. Cellphones are increasingly ubiquitous, so much so that For this reason, companies often lock down the smart- many users are inconveniently forced to carry multiple phones they allow to connect to the company network, cellphones to accommodate work, personal, and geo- resulting in many users having to carry separate work graphic mobility needs. We present Cells, a virtual- and personal phones. Application developers also often ization architecture for enabling multiple virtual smart- carry additional phones for development to avoid having phones to run simultaneously on the same physical cell- a misbehaving application prototype corrupt their pri- phone device in a securely isolated manner. Cells in- mary phone. Parents sometimes wish they had additional troduces a usage model of having one foreground vir- phones when they let their children use their smartphones tual phone and multiple background virtual phones. This as entertainment devices to play educational games and model enables a new device namespace mechanism and end up with unexpected charges due to accidental phone novel device proxies that integrate with lightweight op- calls or unintended in-application purchases. erating system virtualization to efficiently and securely To address these problems, a few approaches have multiplex phone hardware devices across multiple virtual started leveraging traditional virtual machine mecha- phones while providing native hardware device perfor- nisms to enable two separate and isolated instances of the mance to all applications. Virtual phone features include entire software stack of a smartphone to run on the same fully-accelerated graphics for gaming, complete power ARM hardware phone [25, 3, 6, 14]. These approaches management features, and full telephony functionality require substantial modifications to both user and ker- with separately assignable telephone numbers and caller nel levels of the software stack, and paravirtualization ID support. We have implemented a Cells prototype that is used in all cases because ARM is not virtualizable supports multiple Android virtual phones on the same and proposed ARM virtualization extensions are not yet phone hardware. Our performance results demonstrate available in hardware. While virtual machines provide that Cells imposes only modest runtime and memory important benefits in the context of desktop and server overhead, works seamlessly across multiple hardware computers, applying these hardware virtualization tech- devices including Google Nexus 1 and Nexus S phones niques to smartphones as done by existing approaches and NVIDIA tablets, and transparently runs all existing has two crucial drawbacks. First, smartphones are much Android applications without any modifications. more resource constrained and running an entire addi- tional operating system (OS) and user-space environment 1 Introduction in a virtual machine imposes high overhead and limits the The preferred platform for everyday computing needs is number of instances that can run. Second, smartphones shifting from traditional desktop and laptop computers incorporate a plethora of devices that applications expect toward mobile smartphone and tablet devices [5]. Smart- to be able to use, such as GPUs for providing acceler- phones are becoming an even more important work tool ated graphics. Existing approaches provide no effective for mobile professionals as they often primarily rely on mechanism for enabling applications to directly leverage them for telephone, text messaging, and email commu- these hardware device features from within virtual ma- nication, Web browsing, contact and calendar manage- chines, severely limiting the performance of such appli- ment, and news, travel-related, and location-specific in- cations and making them unusable on a smartphone. formation. Many of these same functions as well as We present Cells, a new, lightweight virtualization the ability to play music, movies, and games also make architecture for enabling multiple virtual phones (VPs) smartphones a useful personal tool. In fact, hundreds of to run simultaneously on the same physical smartphone thousands of smartphone applications are available for hardware with high performance and securely isolated users to download and try through various online ap- from one another. Cells does not require running multi- plication stores. The ease with which users can down- ple OS instances, but instead uses lightweight OS virtu- load new software imposes a risk on users as malicious alization to provide virtual namespaces that can run and software can easily access sensitive data with the risk securely isolate multiple VPs on a single OS instance. 1 The isolation between VPs ensures that buggy or mali- and only modest memory overhead on benchmarking ap- cious applications running in one VP cannot adversely plications designed to stress the system. Cells works impact other VPs. Cells provides a novel file system lay- seamlessly across multiple hardware devices including out based on unioning to maximize sharing of common the Google Nexus 1 and Nexus S systems as well as read-only code and data across VPs, minimizing memory an NVIDIA tablet. It is the first virtualization system consumption and enabling additional VPs to be instanti- that fully supports available hardware devices with na- ated without much overhead. tive performance including GPUs, sensors, cameras, and Because smartphones have small display form factors touchscreens, and transparently runs all Android appli- and are designed to only allow a single application to cations in VPs without any modifications. be visible at a given time, Cells takes advantage of this characteristic to introduce a usage model of having one 2 Usage Model foreground VP that is displayed and multiple background Cells runs multiple VPs on a single hardware phone. VPs that are not being displayed at any given time. This Each VP runs a full standard Android system capable of simple yet powerful model enables Cells to provide a making phone calls, running standard applications, using novel kernel-level device namespace mechanism to ef- data connections, interacting through the touch screen, ficiently and securely multiplex phone hardware devices utilizing the accelerometer and everything else that a user across multiple VPs while providing native hardware de- can normally do on the available hardware. Each VP is vice performance to all applications. Cells also provides completely isolated from other VPs and cannot inspect, a user-level device namespace proxy mechanism that of- tamper with, or otherwise access any other VP. fers similar functionality for devices such as the base- Given the limited size of smartphone screens and the band processor that are proprietary and entirely closed ways in which smartphones are used, Cells only allows a source. These hybrid mechanisms ensure that the fore- single VP to be displayed at any time, referred to as the ground VP is always given direct access to hardware de- foreground VP. All other running instances are referred vices. Background VPs are only given shared access to to as background VPs. Background VPs are still running hardware devices when the foreground VP does not re- on the system and are capable of receiving system events quire exclusive access. Visible applications are always and performing tasks, but will simply run in the back- running in the foreground VP and those applications can ground and not render content on the screen. A user can take full advantage of any available hardware support, easily switch between VPs by selecting one of the back- such as hardware-accelerated graphics. Since foreground ground VPs to become the foreground one. This can be applications have direct access to hardware, they perform done using a custom key-combination to cycle through as fast as when they are running natively. the set of running VPs, or by swiping up and down on Another key aspect of Cells is that it provides full tele- the home screen of a VP. Each VP also has a simple ap- phony functionality with separately assignable telephone plication running in it that can be launched to see a list numbers per VP and caller ID support. Cells achieves of available VPs, the selection of which switches the re- this by integrating a cloud VoIP service to provide indi- spective VP to the foreground. The system can also force vidual telephone numbers for each VP without the need a new VP to become the foreground VP as a result of for multiple SIM cards. Incoming and outgoing calls an event, such as an incoming call or text message. For are performed in the standard manner on the smartphone security and convenience reasons, a no-auto-switch can using the cellular network, but are routed through the be set to prevent background VPs from being switched cloud VoIP service as needed to provide both incom- to the foreground without explicit user action, depend- ing and outgoing caller ID functionality for each VP. In ing the type of events. As discussed in Section 3, the other words, basic telephony is provided using the stan- foreground-background VP usage model is fundamental dard cellular network and standard Android applications, to the Cells virtualization