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.
http://www.itarchitect.com/shared /article/showArticle.jhtml ?articleId=172302134&classroom=
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.
(MS drops code name)
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
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
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
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.
Where I found that..
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).
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
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
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
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.
A short article about IBM's experimentation with virtualizing TPM.
Xen mailing list were IBM researcher announced IBM's intentions with Xen
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.
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
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.
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.
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.
If this page was useful to you, please help others find it:
More Articles by Drag Sidious
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.