Been reading some older Inquirer artcles on Intel's and AMD's respective
virtualization technologies (start by following links from here
<http://theinquirer.net/default.aspx?article=35011>).
The last of the series on Intel's Vanderpool
<http://www.theinquirer.net/default.aspx?article=21451> tries to explain
some of the things you might use it for. E.g.
The user side of the world may have some changes, but they are far out.
The first class of things revolves around corporate user and machine
management. If your VMM is part of your management package, you can
load, unload, and tweak things right under the nose of the user.
If they are using resources in a non-approved way, you can throttle them
down, load or unload things on their HD, and even potentially patch
programs on the fly. If they manage to muck the OS up to a degree that
is all to common in modern corporate life, you simply blow the OS
instance away and load up another snapshot.
As a management tool, it can be everything a BOFH dreams of.
Unintrusive unless you want it to be, undetectable, and impenetrable by
clueless users. Spyware? Viruses? No problem, they can go away with the
click of a mouse on a management console half a continent away.
This assumes that you give users admin access on their desktop OS, but not
of course on their desktop hypervisor, otherwise that puts you right back
where you started. But what's to stop users demanding such access? It seems
to me simpler to deny them admin access in the first place.
Then:
Further out in the nebulous timeline of IT progress comes the more
interesting uses of virtualization. Instead of having your OS be
completely virtualized, imagine a partially virtualized OS. Every
program can be run in its own virtual machine, and messages passed back
and forth in shared memory. It would be like hardware enforced threads,
you spawn a new VM and run the program in it.
But isn't this how properly-designed protected OSes work in the first place?
(Yes, there are definite uses for virtualization in server/hosting type
application scenarios, but all the extracts I'm quoting here are referring
to deployments on the desktop.)
But then things become clearer:
Other than the stability issue, haywire programs can not get out of the
VM and step on critical processes. This is a huge security benefit. The
best is was one that will probably be a moot point by the time it
happens. Three years ago, MS promised us in two years or so that they
would have security under complete control, it is after all a Bill Gates
proclamation.
In the off chance that MS is not 100% secure by this time a year ago,
VMs can help. One of the ideas tossed out by the Intel engineers was
running IE in a VM. When you are done browsing, you shut down the VM,
and all the malware and crud that comes along with running that browser
goes off into the ether with nary a poof.
If you set things up right so that the browser has specific information
pulled from it before it shuts down rather than it writing all over the
OS, it would be very hard for a virus to spread. When you run IE next
time, it loads up a clean image, and has information like bookmarks and
cookies pushed to it. While it is not an uncorruptible paradigm, it will
certainly be much harder to circumvent controls that VT could put into
place. Luckily, this will be a moot point by then, MS promised.
Really, it seems like this virtualization thing originates from _giving up_
on the idea that Microsoft, specifically, is capable of designing a
securely-written OS running securely-written applications. And instead,
trying to patch up the problems with Windows by adding another layer below
it.
But then, who is going to provide this layer for Windows? If Microsoft is
involved, how can you ensure they won't stuff it up again?
|