Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Slashdot Deals: Cyber Monday Sale Extended! Courses ranging from coding to project management - all eLearning deals 20% off with coupon code "CYBERMONDAY20". ×

Comment Re:How is this new news? (Score 1) 183

The Xen PV drivers have historically been closed source for Windows. Fortunately a brave soul in the community stepped up and wrote a set of GPL drivers but Citrix still maintains their proprietary drivers. In general, there's a great deal of fragmentation with Xen PV drivers because they haven't been Open Source from the start.

I think the fact that KVM is avoiding this is quite good.

Comment Re:How does this affect security? (Score 5, Informative) 183

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

Comment Linux has a paravirtual entropy driver (Score 5, Insightful) 179

CONFIG_HW_RANDOM_VIRTIO enables it. It's been there for quite a while.

We could easily support it in KVM but I've held back on it because to really solve the problem, you would need to use /dev/random as an entropy source. I've always been a bit concerned that one VM could starve another by aggressively consuming entropy.

lguest does support this backend device though.

Comment Re:First you need root on the box (Score 4, Informative) 393

No, SMM is loaded from ROM memory by the BIOS. You would have to reload the SMM code every time.

What's more, this only works while the SMM code stays resident in the CPU cache. You would need something running at the OS level that was constantly rewriting this memory to ensure it stayed in the CPU cache.

I expect this would actually be quite difficult to build a root kit with that was not as easy to detect as any other root kit.

All programmers are playwrights and all computers are lousy actors.