How DRM prepared the way for Xen/Vmware
How DRM prepared the way for Xen/Vmware virtualization efforts, or how Microsoft may have shot themselves in the foot with Palladium
I found a interesting article that is full of nice technical tidbits on Intel's and AMD's virtualization features among other things.
I found it very educational and it helped me understand a lot of what is going on with DRM/TPM/Xen/Vmware/Ring 0/Ring 1/Ring-1/ etc etc.
(link dead, sorry)
Keep in mind that I am NOT a security expert in any manner. These are just my personal conclusions based on researching various articles around the net with assistance from Google. It is bound to be full of misinformation, misunderstandings, and bad conclusions. The goal is to provide some useful information and links that other people can use to learn more about the subject themselves.
For those that don't know Palladium was a effort on Microsoft to implement 'Trusted Computing' features. It was originally slated to be included in Vista/Longhorn operating systems, but it has been dropped (or at least trimmed down heavily) in later beta releases.
What the goal was was that for secure computing Microsoft would setup a special operating system that you would use to execute programs. It would prevent software exploits, like say in IE, from being used to further compromise your system. Also, and probably more importantly, it would be used as a vehicle to implement DRM. That is this special operating system would be out of the control of Window's users, but be in control by Microsoft and it's business partners. This would allow people to create 'protected' content that would then be played in this special environment where you could implement very secure restrictions on what the end user can and cannot do with the items they've obtained.
So theoretically you could allow access to a streaming server that implements DRM and 'software pirates' wouldn't then be able record the stream or retransmit the data to other computer.. but end users would be able to pay for it and watch it fairly transparently. Or you could create legal documents using Microsoft's tools that would only be decrypt-able by certain end users.
Or something like that. I don't follow MS stuff that closely on items such as this because to me the concept seemed fairly useless for mere mortals and not something not too interesting. And Microsoft wasn't to eager to tell people how it worked either.
My understanding on how they were planning on running this stuff was by creating a hypervisor that would be built into the hardware that would help host a special operating system for executing code in a secure-from-the-end-user manner. You would play these 'DRM' multimedia applications or execute programs in this 'trusted' environment.
However there is this problem with x86 platform were it's very hard to virtualize. There are certain instructions that can only be executed by software running in 'Ring 0'.. that is closest to the hardware. They couldn't really be abstracted. So on normal computers Microsoft couldn't just insert a hypervisor underneath Windows XP and expect things to work.
Other products have run into similar problems. It's a well known side effect of using x86 and it's legacy nature.
Vmware's solution for their server editions (that ran their hypervisor) for this was to run stuff they would translate instructions as much as possible down to ring0, but then they would have to emulate the stuff they couldn't abstract in software.
Xen's solution to this was to create 'paravirtualisation', were the kernels of operating systems had to be ported slightly to Xen to avoid the items that couldn't be abstracted easily.
Vmware's advantage was that it could run any x86 compatible software with no problem were with Xen you could only run ported kernels. Xen's advantage was that it was much faster for certain operations since there was no software emulation layer. Also this made Xen quite a bit simpler.
Microsoft's (being the overwhelming force that they are) solution was to have Intel and AMD change how the processor operated slightly. That the hardware would assist the hypervisor on abstracting the x86 processor.
Microsoft's approach advantages was that it made it's virtualization approach as fast as Xen's setup, but that it also could run unported software like Vmware's hypervisor does. So it had both the advantages of Xen and Vmware server without much of the drawbacks.
However the downside to Microsoft's approach was, ironically, that it introduces a HUGE security hole in all x86 platforms. That is a rootkit that could be created that could execute a possible vulnerability and insert itself down underneath the operating system kernel down in the new 'Ring-1' that MS's (and Intel VT/AMD Pacifica) approach introduced. This would lead to a much superior exploit then that is currently possible with the most sophisticated driver/module-based root kits that are currently available. Instead of running on the x86 computer you'd run the entire OS hosted inside of the rootkit and it would be impossible for any system software to EVER detect this. Even uninstalling and reinstalling the OS wouldn't necessarily get rid of it and it is platform independent. That is a virus made for Windows would work just as well inside OS X or Linux.
And this threat doesn't go away if you're not running in the hypervisor either. Theoretically it will still work out well on a x86 operating system running directly on the hardware. All you'd need would be some way to lift the system onto the rootkit and the effect would be the same. Like a bootable cdrom with a toy operating system to play around with.
Microsoft Research and Michigan University created a proof-of-concept VM virus called 'subvert' that does exactly this. A PDF outlining their conclusions are available at (link dead, sorry)
These things work so well that a researcher accidentally infected himself without even noticing it...
The solution for this is Trusted Platform Modules (TPM).
TPM creates a new x86 feature that can't be virtualized... This will work with a hypervisor and system kernels that will check hashes on executed kernel code and other programs to make sure that it's not modified by something like a VM-based rootkit.
And, of course, Microsoft liked this solution to the problem because the TPM is required to make sure that in their special 'Palladium' DRM-using operating system/software or whatnot isn't modified by end users and allow people to circumvent DRM restrictions.
So that works out great. You have the virtualization created that makes it easier to take away control from end users, while requiring x86 based operating systems to support TPM controls, which again is required for DRM, or otherwise increase those 'alternative OSes' their end-user's risk for VM-based rootkits.
However Palladium, as it was envisioned, never made it to market. Microsoft basically dropped it. It may still exist a bit as a product called 'Bitlocker' for TPM-enforced file system encryption features.
Also it may be related to Vista's 'Protected Mode' that uses new Mandatory Access Control-like features (MAC as opposed to normal Unix DAC (discretionary access controls).. used in things like Novell's AppArmor or Linux/Redhat/NSA's SElinux. (yes, that National Security Agency from the U.S. federal government).
Vista's protected mode can be used to help secure end users from programming flaws in IE7 (as well as probably other software). Protected Mode in Vista IE7
I don't know that though. But in the past Microsoft has used stuff from failed products/features in stuff that actually makes it to market. (such as previous WinFS efforts and current NTFS stuff). Don't know how exactly the Protected Mode stuff works.
However for the previous Virtualization software like Vmware and Xen goes this Palladium stuff has been a huge boon. The VT from Intel and Pacifica from AMD seems like is a direct result from Palladium project. By using these new instructions Xen can gain the ability to run unported software and gain more speed. Vmware's products now should be able to provide much better support then what is currently possible.
And the TPM stuff should provide the hooks necessarily to make sure that a compromise on one hosted system can't be used to break into another OS.
Ultimately this should allow uses to migrate away from Microsoft systems (and probably move to Microsoft systems if they felt like it). It will provide a way for Apple to market OS X much more aggressively and successfully as a Windows-replacement and for people wanting to use Linux they don't have to worry about the odd program that is not yet available or doesn't have a suitable replacement for the Linux platform.
Also the need for a hosted environment to control the hypervisor with Xen puts Linux is a unique position. If OEM-style vendors begin shipping VM-equipped systems Linux is a ideal system to provide a stripped down environment irregardless what OS was requested to be installed on the hardware.
Also VT/Pacifica should eventually allow operating systems to use their own drivers to access hardware... However this requires PCI-SIG development on specifications and then all new PCI hardware to support such things. It's going to be a long long time before that's going to be possible. Right now in Xen they use Linux to provide direct hardware access for things like display drivers, sound, network, and disk access. Other operating systems don't have this access. Also there is a big tie into DRM for this one also
Some more stuff.
Linux has supported TPM since 2.6.12 kernel.
sHype a research implementation of a secure hypervisor (link dead, sorry).
A short article about IBM's experimentation with virtualizing TPM. (link dead, sorry)
Xen mailing list were IBM researcher announced IBM's intentions with Xen and sHype. Xen mailing list archive
There are a bunch of 'PowerPoint' style PDFs available from the Xen Summit 2005 and 2006. Unfortunately being Power-Point style they are virtually devoid of any any really useful information. Of particular interest are the PDFs dealing with TPM and security. They are mentioned in Intel and sHype related items. Also interesting is the Linux's support for IOMMU. (restricted content)
As for Microsoft's own virtualization stuff... Currently Microsoft has their 'Microsoft Virtual Server' that they offer. It is not a hypervisor product like Vmware Server editions or Xen is. It's more like Vmware's workstation products and is probably based on their Virtual PC stuff they received when they acquired Connectix early in 2003. It requires that you have Windows XP Pro SP2 (for "non-production" work), Microsoft Windows Server 2003 Standard Edition/Enterprise Edition/Datacenter Edition, or Microsoft Small Business Server 2003 standard and premium editions. (link dead, sorry ) Recently they released Microsoft Virtual Server R2. The new things with this item is that now it is offered as a no-cost download that you can add to those supported platforms. Also the more remarkable item is that Microsoft is now officially supporting deploying Redhat or Suse Linux on it. Previously it was possible to install Linux systems on a virtual server, but it was a unsupported configuration. (link dead, sorry) This is obviously a result of increased interest in the virtualization in the enterprise environments and in response to the efforts from Vmware and Xen. Maybe between Xen and MS VS they are hoping to put a nice big damper on Vmware's parade. Microsoft currently plans to offer their own hypervisor virtual server as part of the R2 release of Longhorn server. Longhorn server itself isn't due out until 2007 and the R2 isn't probably going to be out until 2009 or so (link dead, sorry). So that's how that goes.
Funny how Microsoft trying to develop hardware extensions in a attempt to lock down users even further has allowed things like Xen to open up more possibilities to end users while Microsoft seemed to have dropped it's original Palladium stuff off the map.
Reminds me of a quote...
"The more you tighten your grip, Tarkin, the more star systems will slip through your fingers."
-- Princess Leia to Grand Moff Tarken, Imperial Governer and Commander of the Death Star. Star Wars 1977. Quotes: Star Wars: Episode IV - A New Hope
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
More Articles by Drag Sidious © 2011-06-29 Drag Sidious