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.

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).