Over the last few months, details have been trickling out about Intel's latest processor family, Haswell. Just this week, pricing information was leaked for desktop and mobile processors, and we've also seen feature charts and some benchmarks on pre-release hardware. I'm no processor wonk, so don't expect me to start spouting off about the die size or the innards of the memory addressing scheme or whatever bloody things are new, but I did hear that Haswell will include something we've been after for a long time: direct VT support for nested VMs.
The idea of running virtual machines inside virtual machines isn't new. We've been able to do that in unsupported, emulated ways for many years, but the performance has always until recently bordered on terrible. At the very best, you could say it wasn't production-worthy. The reason for this is that any virtualization done from within an already-virtualized machine had to be 100% emulated by virtual hardware that wasn't designed (or even able) to support virtualization in the first place. The fact that it worked at all was almost accidental (or a testament to the resiliency of the hypervisor).
Because of that, certain solutions are limited to working on physical hardware, like Bromium vSentry. (Tal is the person that got me thinking about this.) vSentry requires ownership of VT, which is just fine on a physical machine. In a virtualized environment, though, the hypervisor owns VT, and cannot relinquish control of it to a VM. It appears that's about to change with the Haswell processors that Intel is due to release soon, which will include a feature called VMCS Shadowing.
VMCS Shadowing, at least as I understand it, allows multiple VMMs (or hypervisors) to have access to the VT extensions on the processor, either by direct access or via what I'll call a passthrough (although I'm not sure if that's the appropriate description). There is also Extended Page Table Shadowing, which does something similar but in memory. Essentially, this all means that VMMs (or hypervisors, or microvisors in the case of Bromium) can have the access they need to VT to make the requests directly, rather than emulating them.
This could be huge for Bromium because the fact that vSentry only works on physical hardware right now is a limiting factor in its adoption. I've written before about vSentry, but the short description is that it uses micro-VMs to isolate browser threads from the OS, which means that even if a user browses to a malicious website, the machine itself is protected. Bromium can do much more than isolation with this approach, too, like allowing exploits to play out while monitoring them in order to discover how they work, all without allowing the exploit to actually see or do anything harmful to the desktop or data.
Currently, the only way to deploy vSentry into a VDI desktop is to publish Internet Explorer from an RDSH server, but even then the RDSH server must be a physical box (VT ownership doesn't discriminate between servers and desktop OSes). For the organizations that just use the locally-installed browser in VDI environments this seems to be a show-stopper, while for others pushing out browsers via RDSH to desktops (physical or VDI) seems to be standard practice. To be honest, I'm not entirely sure what the industry-wide best practice is in this scenario, but I can understand both approaches. Still, my guess is that using vSentry on RDSH servers is a tough sell as well because most RDSH servers are virtualized.
This is all the more reason that I think Haswell will be the lift Bromium needs to see widespread adoption, but will Bromium head down that path? It sounds like Haswell PC-oriented chips have already started shipping to OEMs, so we might not have to wait long to find out. In the meantime, is publishing browsers from vSentry-enabled physical RDSH servers a good enough solution for your organization?
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.