Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Posted Jul 20, 2006 11:37 UTC (Thu) by drag (guest, #31333)In reply to: Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization by copsewood
Parent article: Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Ya. With newer hardware it will be possible to run unmodified systems on Xen.
The whole point of Xen's 'paravirtualization' was that there was a certain class of x86 instructions that couldn't be virtualized. With Vmware the work around was complex software emulation of those instructions. With Xen you modified the kernel to assist in working around the problem.
So that with Vmware you had higher compatability, but lower speed. With Xen you had higher speed, but lower compatability.
With the newer chips they modified how the proccessor worked to make these things easier to abstract. Xen should be able to run any operating system with no software emulation and with no paravirtualization, although I think that operating systems will still benifit from being ported for other reasons.
As a side effect this made it possible for a whole new set of operating system exploits. Now with new hardware it is possible 'lift' the OS onto a hypervisor like Xen with complete transparency. (keep in mind that Xen loads first, that Linux runs on top of Xen and other systems run on top of Xen/Linux combo)
With these new VT/Pacifica stuff is now possible to get 100% compatability in a VM with only a 5% or so drop in performance. A admin isn't going to notice this.
So if you build hypervisor capability into a rootkit a attacker now can get UNDERNEATH then the kernel. Even through reboots it's possible to keep bootable cdroms 'lifted'. It opens you up for the perfect rootkit. There are already proof of concepts aviable. There was even a researcher who accidently infected himself with a rootkit and didn't even notice it.
But that's were TPM (trust platform modules) come in....
Back in the day when Vista was still Longhorn Microsoft initiated it's "Palladium" program. The idea that was you had a 'protected' environment in which programs could run outside user's control. This made it more secure, both ways. Badly behaved programs couldn't break out and infect your computer and users couldn't break in and reverse engineer DRM.
So how to acheive this Microsoft wanted to run a sort of mini-OS to run a virtualized environment.
But you can't virtualize x86 easily and get binary compatability, remember? So that instead of taking the Vmware route and implimenting expensive partial software emulation or of going Xen route and modifying how programs worked they decided to go the Microsoft route:
Have Intel and AMD change how their proccessors worked.
Life is good for the 36billion pound gorrilla, eh? So that took care of the first half; the VM environment. Intel and AMD scrambled to create VT and Pacifica and integrate it into their chips.
(CPU makers design chips at least 2 generations into the future. The newest stuff is just in design state.. the next generation is having it's production stuff being designed and tested, and the 2 generation old is what they are selling. Or something like that... Just remember that it takes a very long time to get new cpu desines out.)
The second half of the Palladium "final solution" was to impliment a way to prove that this protected environment was untampered with. Time to protect the VM from molestation.
So the solution to the 2nd problem was TPM. TPM on your motherboard stores checksum hashes to create a 'trusted path'. The motherboard/cpu would then refuse to run modified versions of this palladium protected environment.
For instance in Linux supported TPM since 2.6.12, I beleive. And there is a 'trusted grub' version. So the path of trust goes like this:
Bios initializes. Begins to boot up. The TPM takes over somehows.. It has in it's memory a checksum of your grub bootloader.
The grub bootloader is tested to make sure that it's unmolested. If it's fine then it boots.
Trusted grub maintains it's own set of checksums for the kernel and initrd. It tests the kernel and boots up.
The kernel and initrd holds checksums of important system files and checks those a it boots up... etc etc etc all through the boot proccess more and more stuff is tested and verified. All of this is with assistance with the TPM and your CPU. If a 'trusted' binary has been modified in anyway then it will not be executed.
So that way you have a 'trusted' environment.
Well eventually Palladium died on the longhorn feature chopblock. Intel and AMD were looking for places to use it's new VT and Pacificia stuff in. It was going to be in their future cpus which they already tested and designed and were in the proccess of creating the production plants for...
And standing there was little ol' Xen Source with it's paravirtualization that could only work on 2 operating systems, but was very fast. (FreeBSD and Linux are the two)
So now Intel and AMD worked with Xen to make their hypervisor support the new features. Eventually as new hardware gets here Xen will be able to support operating systems without modifications. You need support in your motherboard and support in your CPU.
If your motherboard claims to support the 9xx series Pentium-D then more then likely it will support VT. I don't know about AMD though.
Also Vmware benifits from VT/Pacificia; this will allow for a much faster VM for them, also.
And TPM will be used to ensure that Linux and friends aren't running in a hostile VM. It's specificly designed to be very difficult to virtualize.
Of course Microsoft now realised that 'Hey virtualization is the next big thing from last year' and is going to have their own hypervisor due out sometime after 'Longhorn server' comes out. They're current Virtual Server product is laughable compared to the sort of enterprise stuff Vmware has and it's performance sucks compared to Xen/Linux. (which is probably why MS has stopped bothering trying to sell it and give away free now)
Of course it's Microsoft's 'Virtual Server' and it has a huge advantage simply because it is from Microsoft. Most of the administrators that use it are completely unaware of Vmware's products beyond their Workstation stuff and Xen/Linux might as well be from another planet.
Please note that lots of the stuff I said are probably misleading or just wrong. I am NO expert on the subject and am just relaying what I've read elsewere.
Posted Jul 20, 2006 13:07 UTC (Thu)
by thompsot (guest, #12368)
[Link] (1 responses)
Posted Jul 20, 2006 13:09 UTC (Thu)
by thompsot (guest, #12368)
[Link]
Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Of course Microsoft now realised that 'Hey virtualization is the next big thing from last year'
LOL
Of course it's Microsoft's 'Virtual Server' and it has a huge advantage simply because it is from Microsoft. Most of the administrators that use it are completely unaware of Vmware's products beyond their Workstation stuff and Xen/Linux might as well be from another planet.
I'm experiencing this EXACT thing where I work... If I pitch the advantages of VMware, I'm told that the MS virtual server is free and supported already, plus the Windows admins already implemented it. If I pitch the advantages of Xen, everyone silently stares at me as if trying to figure out what strange language I'm speaking, then someone shrugs and changes the subject.
Coming from a multi-architecture and platform background (RISC/x86/MIPS - NetWare/Windows/Linux/Windows) and working in a single architecture and platform environment (x86 - Windows) is a strange, "upside-down totem pole" experience to be sure.
Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
OOps... I meant, "Netware/Windows/Linux/Unix". The horror...