Cells: A Virtual Mobile Smartphone Architecture
Cells: A Virtual Mobile Smartphone Architecture
-
Jeremy Andrus
-
Christoffer Dall
-
Alexander Van’t Hof
-
Oren Laadan
-
Jason Nieh
Paper Overview
-
Old idea meets new application paper (another new type)
-
OS virtualization (aka Docker)
-
Smartphones!
What’s A Virtual Phone?
Cells runs multiple VPs on a single hardware phone. Each VP runs a standard Android environment capable of making phone calls, running unmodified Android applications, using data connections, interacting through the touch screen, utilizing the accelerometer, and everything else that a user can normally do on the hardware. Each VP is completely isolated from other VPs and cannot inspect, tamper with, or otherwise access any other VP.
Why Do This?
-
Security: apps running in one virtual phone have no visibility into virtual phones—useful for "bring your own device" work environments.
-
Encapsulation: can distribute an entire virtual phone image preloaded with a bunch of useful software—again, think of a corporate setting.
Why Not Use Existing Virtualization Approaches?
While VMs are useful for desktop and server computers, applying these hardware virtualization techniques to smartphones has two crucial drawbacks. First, smartphones are more resource constrained, and running an entire additional operating system (OS) and user space environment in a VM imposes high overhead and limits the number of instances that can run. Slow system responsiveness is less acceptable on a smartphone than on a desktop computer since smartphones are often used for just a few minutes or even seconds at a time.
Second, smartphones incorporate a plethora of devices that applications expect to be able to use, such as GPS, cameras, and GPUs. Existing approaches provide no effective mechanism to enable applications to directly leverage these hardware device features from within VMs, severely limiting the overall system performance and making existing approaches unusable on a smartphone.
What Does Container Virtualization Virtualize?
-
For hardware virtualization we virtualize the hardware interface: certain instructions change the state of the VM rather than the hardware itself.
-
For container virtualization the OS interface is shared by all virtual "machines" (or phones).
-
The OS name space.
Mi /home/foo No Es Su /home/foo
Name space virtualization requires that we isolate several name spaces between VPs:
-
The file system name space: all virtual phones must see their own root partition containing no files owned by other virtual phones.
-
The process name space: all virtual phones must see only processes running in their own name space and not others.
-
The network name space: IP addresses, port mappings, etc.
-
The device name space (similar to the file system name space): all virtual phones must have access to the same underlying devices through the
/dev/name space.
Cells uses four techniques to isolate all VPs from the root namespace and from one another, thereby securing both system and individual VP data from malicious reads or writes. First, user credentials, virtualized through UID namespaces, isolate the root user in one VP from the root user in the root namespace or any other VP. Second, kernel-level device namespaces isolate device access and associated data; no data or device state may be accessed outside a VP’s device namespace. Third, mount namespaces provide a unique and separate FS view for each VP; no files belonging to one VP may be accessed by another VP. Fourth, CellD removes the capability to create device nodes inside a VP, preventing processes from gaining direct access to Linux devices or outside their environment, e.g., by re-mounting block devices. These isolation techniques secure Cells system data from each VP, and individual VP data from other VPs.
Device Virtualization
3/4 of these problem had already been solved by existing container virtualization approaches.
-
Device virtualization.
Cells meets all three requirements in the tightly integrated, and often proprietary, smartphone ecosystem. It does so by integrating novel kernel-level and user-level device virtualization methods to present a complete virtual smartphone OS environment. Kernel-level mechanisms provide transparency and performance. User-level mechanisms provide portability and transparency when the user space environment provides interfaces that can be leveraged for virtualization. For proprietary devices with completely closed software stacks, user-level virtualization is necessary.
User- and Kernel-Level Virtualization
-
I have to make changes to the OS kernel. (Duh.)
-
I also have to make changes to the user-space processes, in this case the Android runtime.
The entire radio baseband system is proprietary and closed source, starting from the user-level RIL vendor library down to the physically separate hardware baseband processor. Details of the vendor library implementation and its communication with the baseband are well-guarded secrets. Each hardware phone vendor provides its own proprietary radio stack. Since the stack is a complete black box, it would be difficult if not impossible to intercept, replicate, or virtualize any aspect of this system in the kernel without direct hardware vendor support. Furthermore, the vendor library is designed to be used by only a single RilD and the radio stack as a whole is not designed to be multiplexed.
Multiple Phone Numbers
While some smartphones support multiple SIM cards, which makes supporting multiple phone numbers straightforward, most phones do not provide this feature. Since mobile network operators do not generally o↵er multiple phone numbers per SIM card or CDMA phone, we o↵er an alternative system to provide a distinct phone number for each VP on existing unmodified single SIM card phones, which dominate the market. Our approach is based on pairing Cells with a VoIP service that enables telephony with the standard cellular voice network and standard Android applications, but with separate phone numbers.