|| ||"Martin C. Atkins" <martin-AT-mca-ltd.com>|
|| ||Articlelet: On the dangers Virtual Machines pose to freedom|
|| ||Thu, 4 Aug 2005 18:47:29 +0530|
--- Start ---
On the dangers Virtual Machines pose to freedom
Martin C. Atkins
There has been much enthusiasm surrounding the recent rise of Xen as
the OpenSource Virtual Machine Monitor (VMM, or hypervisor), most of
which I have joined in.
There have also been several comments along the lines of "Virtual
machines are the ultimate weapon against DRM/NGSCB/etc", since we
will just virtualise the controlled devices along with the virtual
processor. I used to think that too.
However, I recently realised that there are some significant dangers
lurking in these developments, especially when Intel's Vanderpool,
and AMD's Pacifica come into the picture.
How long will it be before Intel, or a BIOS manufacturer, puts a VMM
into the BIOS of a motherboard designed for a Vanderpool/Pacifica-capable
processor? This has many attractions, in addition to the "normal"
ones (multiple simultaneous OSs), for example, one would be able to
access BIOS/etc functionality, such as DVD playing, independently of any
OS, and without stopping the other operating systems that are already
running. One could also standardise many device interfaces, etc...
However, it is only a small step to a BIOS/VMM that *only* allows OSs
to run in virtual machines! Suddenly the VMM has immense power, and
the company who controls the VMM also has immense power! The VMM
becomes the natural seat for DRM technologies, and we wouldn't even
be able to argue that we couldn't boot Linux (or whatever) - but the
capabilities of any "untrusted" operating system could be severely
The next obvious step would be to put the VMM into ROM, rather than
flash memories, making it even more difficult to replace with a
"normal" BIOS. Ultimately, the VMM ROMS could be built into the CPU
chips, and we have (almost) completely unhackable computers, with a
semblance (but only a semblance) of openness. Complete control over
how we use the computer would rest in the CPU manufacturers'
hands [see also note2].
Lesser risks also include things like: does the VMM provide the
facilities I need?. An example would be: does the VMM guarantee
real-time responsiveness? If it does not, and you need guarantees,
well tough! Go and find another computer/architecture/planet!
Another potential risk is simply the quality (or lack of) of the VMM
If you think this is far fetched, ponder for a moment the PS3, which
apparently always runs "applications", such as games and Linux, in a
virtual machine. To quote Ken Kutaragi in  "The kernel runs on
Cell (Cell OS hypervisor) and it takes the style in which multiple
OSes as applications run on top of that (virtual machine)". The
future is with us today!
I'm also reliably informed that IBM pSeries and iSeries mainframes
are already configured this way. I am told that the IBM hypervisor
(pHype) is (virtually) impossible to remove (no pun intended!).
Fortunately, DRM hasn't been high on the feature lists of these
machines thus far.
Executive summary: Virtual Machine Monitors are very nice, but we
need to have a real choice about whether or not to boot one and/or
which one to boot. Whoever controls this choice, controls the machine!
[Note1] I've found that  touched on these ideas back in 2003, but
didn't, in my opinion, go nearly far enough.
[Note2] A more viable alternative might be to build a BIOS ROM
signature check into the CPU, so that only BIOSs signed by the CPU
manufacturer would run. This would allow field updates, bug fixes,
etc., but still make it (nearly) impossible to substitute a less
--- END ---
Comments (10 posted)
|| ||"Hyre, Max" <Max.Hyre-AT-cardiopulmonarycorp.com>|
|| ||Ratings are fine (Open Enterprise, 9 August 2005)|
|| ||Wed, 10 Aug 2005 10:38:49 -0400|
Dear Mr. McAllister:
In your column ``Does a Ratings Standard Make Sense for Open
Source?'' (9 Aug. '05,
A rating says to potential users: Watch out. Think
twice. Double check. Get the facts.
It warns off potential users in exactly the way a full and
accurate bug list does: not at all---rather the reverse. In
both cases, you /are/ getting the facts: a clear, honest
evaluation of the program, something impossible to find for
Users recognize and appreciate this: they know what they're
getting. They know most proprietary software has failings worse
(often far worse) than the most severe bug found in a Free
Software bug list.
But if promoting open source is the goal, is it really the
best message to lead with?
Yes. Free Software is competing by different rules, ones
fairer to the user. Its ``promotion'' is so much more than
advertising budgets and PR departments.
Comments (none posted)
Page editor: Jonathan Corbet