Red Hat Releases Windows Virtualization Code

dan_johns writes "Only one month after Microsoft released Linux code to improve the performance of Linux guests on Windows, Red Hat has done the reverse. Red Hat has quietly released a set of drivers to improve the performance of Windows guests hosted on Linux's Kernel-based Virtual Machine (KVM) hypervisor. The netkvm driver is a network driver and viostor is a Storport driver to improve the performance of high-end storage. This release includes paravirtual block drivers for Windows. Linux and Windows — virtually coming together at last."

Comments

Re:Gentoo??

[palegray.net]

Now you can run Windows in a VM when people come over to avoid the shame of admitting you run Gentoo?

/me goes back to his Mac and Debian servers.

Lack of Caring

[tychoish]

I suppose this is a good thing, and I'm a big fan of the virtualization, but really, why? Windows fails to compel.

How does this affect security?

[mlts]

I've always wondered how paravirtualizing some functions such as I/O or networking affects security.

Say a VM gets compromised, and is able to do what it wants with the block devices, how tough would it be to get out of the VM? If malicious code is able to access the host's block device that runs in kernel mode and start running code directly on the host's OS, game over.

Re:How does this affect security?

[AltGrendel]

That depends on if you are using Xen or Qemmu. There's a design flaw in Xen/SELinux that will allow a hacked guest to write to the physical drive without notifying SELinux. This was "fixed" when the Qemm/SELinux interaction was worked out. There's a blog from one of the Red Hat SELinux guys that gives more detail, but I can't find the link just now.

Re:How does this affect security?

[TheRaven64]

Paravirtualisation just means that you're using a set of simple interfaces to communicate with the hypervisor driver, rather than an emulated physical device. You're still sending commands from the guest to the hypervisor (or, in the case of Xen, to a privileged guest), and it is still completing them on your behalf by talking to the hardware. If anything, PV is more secure, because the code running outside the guest is much simpler than a full emulated device. If there's a bug in the host PV drivers that permits arbitrary code execution then it's possible to escape from the VM. If there's a bug in the host's device emulator, then it's possible to escape from the VM. The second is more likely, because the code is much more complicated. A Xen PV block device interface, for example, is about 200 lines of code.

Re:How does this affect security?

[Anthony Liguori]

I've always wondered how paravirtualizing some functions such as I/O or networking affects security.

Say a VM gets compromised, and is able to do what it wants with the block devices, how tough would it be to get out of the VM? If malicious code is able to access the host's block device that runs in kernel mode and start running code directly on the host's OS, game over.

Unlike Hyper-V and Xen, in KVM a paravirtual device looks an awful lot like an emulated device. For instance, virtio-net appears to the guest as a normal PCI device. It's quite conceivable that a hardware vendor could implement a physical virtio-net card if they were so inclined. In our backend, we implement virtio-net like any other emulated device.

This means from a security perspective, it's just as secure as an emulated driver. It's implemented in userspace and can be sandboxed as an unprivileged user or through SELinux.

VMware uses a similar model. Hyper-V and Xen prefer to not model hardware at all and use special hypervisor-specific paths. From a security perspective, the fact that these devices are on a different code path means that they have different security characteristics than emulated devices. For instance, in Xen, a paravirtual network device is backed directly in the domain-0 kernel so an exploit in the xenpv network device is much more severe than an exploit in a Xen emulated network device (since the device emulation happens in an unprivileged stub domain).

Re:How does this affect security?

[QuantumG]

8 years and finally someone outside the company gets that joke.

Re:See!

[Ynot_82]

Since when has Linux /not/ played nicely with windows?

It's the other direction that's strewn with landmines

A good thing.

[LoRdTAW]

Cooperation like this is a great gesture. MS releasing code to help Linux run better in their VM's is a good thing and I am glad Red Hat returned the favor. With shops today running a mixed environment this helps them with transitioning or running apps side by side. Great for Linux development/testing on Windows and now better Windows development/testing on Linux systems. Now if only Apple would allow OSX to run in a VM. Developers could have one system running the OS of their choice and do all their cross platform development and testing on one system. Great for small developers who might code on a laptop or prefer to have a single system for development.

Re:A good thing.

[spitzak]

Not really. The authors of the code wanted it released in such a way that it could be incorporated into the kernel source code. This meant it had to be GPL or the kernel maintainers would not add it. It is irrelevant whether or not releasing it some other way would violate the GPL, as the authors never intended to do that.

The real news is that somehow magically Microsoft was not forced to GPL every bit of code that they ever wrote, despite their repeated claims that the GPL is a "virus" that "infects everything it touches". They basically proved that they directly lied about this.

Re:At parity once again

[nxtw]

Yes, they expected it just like they expected people to extend Kerebos Authentication and XML filetypes right back at them. Microsoft embraces and extends OTHERS, they don't GET embraced and extended.

No; Microsoft and Red Hat joined each others' virtualization validation programs. As a result, Red Hat will support Windows server operating systems on Red Hat's virtualization software. This support is a direct result of Red Hat participating in Microsoft's validation program.

The list of vendors participating in Microsoft's program includes other companies, such as VMware, Citrix, Cisco, Oracle, and Sun.

Re:See!

[fuzzyfuzzyfungus]

A common filesystem(one nicer than fat32, or iso9660, and more generally useful than UDF, at any rate) would be nice; for external storage devices and for certain hobbyist dual-boot scenarios; but I, in my own experience, just don't feel the need as keenly as I used to. I wouldn't be surprised if the reason that one doesn't exist(to any really useful degree) is that others have similar experiences.

With computers so cheap, and getting ever cheaper, and networking going from common to ubiquitous, and little network storage widgets popping up even on home networks, not to mention the increasing amount of stuff that lives on a remote server somewhere, I just don't find myself needed to access one OS's partition from the other very much. If I really do need to grab some file, NTFS-3G's inefficiency just isn't a big deal.

The overwhelming majority of file transfers between OSes(or between the same OS on different machines) that I end up doing these days are via some network protocol, http, sftp, smb, IMAP, etc. that abstracts away the filesystem on the other end, and is spoken just fine by most anything. With virtualization becoming an increasingly common, and for most purposes superior, alternative to dual booting, network transfers even work for two OSes on the same machine.

It would be nice if there were a properly interoperable filesystem in common use(if only so we could shove a stake through exFAT's black heart before it takes off); but it just hasn't been a big deal for a while now, for me.

Re:Gentoo??

[Jurily]

Now you can run Windows in a VM when people come over to avoid the shame of admitting you run Gentoo

What shame? Absolutely nothing can establish your Alpha Geek status faster than saying "Umm, I don't have a graphical desktop right now, it's still compiling", and firing up lynx to check your email.

Re:See!

[maharb]

It might be a legit improvement and a strategic move from Microsoft. Windows doesn't care if they are being run in a VM on a Linux box. They still sell support, licenses and all that other good stuff. In fact, VM's might mean more windows installs, more license keys sold, more support requests, and more money for Microsoft. Why would they want to stop paying customers from doing what they want on their box. Hell, Microsoft is probably thrilled that people are running Linux on a licensed copy of Windows in a VM rather than native and they are probably thrilled that windows is being installed on VM's on a Linux host. Win win for Microsoft and Linux. Soon they will both have 100% market share. lol.

Re:See!

[Korin43]

The NTFS drivers for Linux work pretty well.. And ext2 IFS works except for:

* Inodes that are larger than 128 bytes are not supported.
* Access rights are not maintained. All users can access all the directories and files of an Ext2 volume. If a new file or directory is created, it inherits all the permissions, the GID and the UID from the directory where it has been created. There is one exception to this rule: a file (but not a directory) the driver has created always has cleared "x" permissions, it inherits the "r" and the "w" permissions only. See also section "What limitations arise from not maintaining access rights?".
* The driver does not allow accessing special files at Ext2 volumes, the access will be always denied. (Special files are sockets, soft links, block devices, character devices and pipes.)
* Alternate 8.3-DOS names are not supported (just because there is no place to store them in an Ext2 file system). This can prevent legacy DOS applications, executed by the NTVDM of Windows, from accessing some files or directories.
* Currently the driver does not implement defragging support. So defragmentation applications will neither show fragmentation information nor defragment any Ext2 volume.
* This software does not achieve booting a Windows operating system from an Ext2 volume.
* LVM volumes are not supported, so it is not possible to access them.

exchange/ad on linux (haha)

[itzdandy]

The problem for me with this is that Windows is a poor server OS. The only compelling reason to run Windows servers is active directory and exchange. IIS is not nearly as good as apache or nginx or comanche or lighttpd (specifically, overhead, flexability, security, and performance!)

The costs for many organizations to engineer, deploy, and support windows servers for exchange and sharepoint is equal to or greater that the cost of outsourced/hosted. You can get hosted exchange for under $12/user/month at rackspace which compares well enough to a MCTS for Windows server and exchange as that 55,000 can do well over 350 exchange accounts without a power bill.

A linux server may take some expertise to setup but needs far far less daily upkeep. You can employ many less techs and hire in from the local tech shop for big deployments. I have an email server (ubuntu 6.04) that has been running for over 3 years without any effort on my part. The only downtime it has ever had was when the power failed and it shut down after the UPS was drained. $1200+ about 6 hours config (say $85/h) and no maintenance is something is am sure no windows server can or ever has matched.

back on point here, stop investing time and money is getting windows to run faster virtualized, put those dollars into alternatives to windows software. it has happened before that an OSS alternative (apache) has become so dominant that the big vendors have the alternatives rather than the standard. (bind, apache, sendmail and postfix, courier etc)