In November 2008 VMware announced the acquisition of Trango Virtual Processors, a startup focused on hardware virtualization for embedded devices.
At that time the company also announced its plan to deliver a mobile hypervisor called Mobile Virtualization Platform (MVP).
VMware remained mum and under the radar about MVP, also because its initial plan to deliver by the second half of 2010 doesn’t seem feasible anymore. The cellphone industry radically changed in the last two years, with new forces and platforms dominating the market. These changes may have obliged VMware to completely reconsider its go-to-market strategy and the timing to execute it.
The company also made significant changes in the MVP architecture as reported by virtualization.info in mid September:
…the MVP architecture has been radically changed compared to the original plans: in its early demos VMware suggested that the mobile hypervisor (a type-1 VMM) would run side by side two VMs with real-time operating systems (RTOS).
The new architecture instead adopts a hosted virtualization platform (a type-2 VMM) that runs on top of the native RTOS installed on the phone. This one is considered the “personal environment” while the VM running on top of it contains the “business environment”…
Now, additional detalis are coming from the VMware’s major competitor in the mobile virtualization arena: Open Kernel Labs (OKLabs), which is coincidentally funded by Citrix.
In a recent blog post OK Labs assessed the MVP architecture and focused exactly on the decision to use a type-2 architecture (emphasis our):
…A system call performed by an application is a privileged operation which is intercepted by the hypervisor, which (after deciding that this is an operation which should be handled by the guest) forwards it to the guest OS. The return to user mode from the guest takes a similar detour through the hypervisor…
…In the case of a Type-1 hypervisor, this results in a total of four mode switches and two context switches. However, in the case of a Type-2 hypervisor, the system call is trapped by the host OS, which delivers it to the hypervisor, and a return from the hypervisor to either the guest or the app similarly takes a detour via the host. All up, the number of mode switches and context switches is double…
…Note that ARM’s forthcoming architecture extensions to support virtualization [http://virtualization.info/en/news/2010/09/arm-announces-cortex-a15-cpu-with-virtualization-capabilities.html] help to reduce the overheads of a Type-1 hypervisor, but do little to help a Type-2…
VMware understands this, and has taken a different approach in MVP….
Fundamentally, the high cost of Type-2 virtualization stems from the fact that the hypervisor effectively consists of two parts, the host OS and the hypervisor proper, that each (logical) hypervisor invocation bounces twice between those layers, and that the host mechanisms used for this bouncing are inefficient. So, what VMware does in MVP is to merge the hypervsior back in with the host.
This is done by loading a MVP module (called “MVPkm”) into the host OS kernel…
…The MVP module effectively hijacks the host, by re-writing the exception vectors, so it obtains control whenever the guest kernel is entered. (Note: this is exactly what a piece of malware would do.) The process turns the host kernel into a hypervisor.
The result is not really a Type-2 hypervisor any more, as it actually runs native, not on top of a host OS (but inside) and has direct control over physical resources (rather than the virtualized resources provided to it by the host). However, it it isn’t a Type-1 hypervisor either, as it does not have exclusive control over the hardware, this is shared with the rest of the host, and any code inside the host kernel can interfere with the operation of the hypervisor module.
So, if this hypervisor is neither a Type-2 nor a Type-2, what is it? I call it a hybrid hypervisor, as it is somewhat of a blend of the two basic types. A better-known representative of the hybrid hypervisor type is the widely-used KVM (often falsely referred to as a Type-2 hypervisor). It operates very similarly, although KVM is dependent on virtualizaiton extensions to the architecture (MVP is not, but can make use of them)…The hybrid hypervisor can achieve similar performance as a Type-1 hypervisor, so this scheme seems pretty neat at first glance…
…The one advantage a Type-2 hypervisor has over a Type-1 is that it can be easily installed: for the host OS it’s just another app, and it is installed just like an app, without requiring any special privileges.
This advantage is lost with the hybrid approach. It requires inserting a kernel module into the host OS, which is a highly security-critical operation (after all, it is the same as installing a root kit into the kernel!) As such it requires special privileges. On a mobile phone it requires cooperation witth the device vendor or network operator, as they try very hard to prevent the unauthorised insertion of malware-like code into the OS!…the hybrid hypervisor inherits all the other drawbacks of the Type-2 hypervisor, especially the huge size of the trusted computing base. Everything in the host OS (all of a million or so lines of code!) needs to be trusted, a huge attack surface…
In an older post, OK Labs evaluates MVP’s security from a different angle:
…VMware say they encrypt the guest’s data on flash and also use an encrypted VPN tunnel to connect to the enterprise network. Surely, this will protect the data from attacks?
Surely not…‘Cause in order to be processed, the data is loaded into memory and decrypted. And there it is fully accessible by the OS, and if that OS is infected, there’s no way to stop the malware from seeing (and leaking) your data.
Last but not least, in the most recent post above, OK Labs confirms that VMware is working to bring MVP on Google Android, an obvious choice considering the low chances that Apple would ever authorize such architecture and the uncertain destiny of other mobile OSes like Nokia Symbian, RIM Blackberry OS and even the new Microsoft Windows Phone 7.