Entropy in VMs is hard to get, it's nice to see an "easy" way to access better system-level entropy. There are also a few utils that let you distribute entropy amongst your VMs[1], but getting everything directly from the system feels better from a security perspective.
I've been forced to use rng-tools and / or rng-usleep to get enough randomness in some Ubuntu VMs in the past. It's maddening to see SSL slowdowns for no good reason, and to have to trace it back to a blocking call to /dev/random for 8 lousy bytes.
Canonical released Pollen/Polinate a while ago to address this problem. The idea is that each virtual machine queries a pool of entropy servers to seed it's own generator, and as log as at least one entropy server isn't compromised, you should be fine.
> Red Hat Enterprise Virtualization starting version 3.5 also has exposed this feature.
Anyone know what relationship that product has with oVirt ( http://www.ovirt.org ) ? I thought oVirt was kind of the upstream. So wouldn't they be adding this to oVirt as well.
The original product was called Solid ICE by a company called Qumranet. Red Hat acquired Qumranet in 2008 and as we do with all acquisitions, we started to liberate the proprietary code. It became oVirt in about 2010, and parallel to that is the downstream (but also fully open source) RHEV management product.
Interesting fact: The original product was written in C# and ran only on Windows. It was translated into Java, largely automatically at first with manual tidy ups, so it could run on Linux or Windows servers. (Well there are some Python and other bits too)
Thanks for explaining. That is a pretty cool history.
I am working with a bunch of C# code written for windows as well trying to make it work on Linux and went the Mono way. So far it worked pretty well (as long as no Desktop GUI forms are involved).
Yes, oVirt is the upstream for RHEV, so adding the virtio-rng device to guests is a feature in oVirt 3.5 as well. I didn't mention Fedora or oVirt there but everything applies to upstreams as well.
On a multiuser system there are various cases where being able to predict the PID of a process allows attack against naive code. eg. If a process uses the pid to generate a tmp file name, someone sneaks in first and makes it a link and uses that to put content into an arbitrary file they shouldn't have write access to.
Now, there is a valid contention that any code doing that is broken anyway and should just be fixed, and most code is much better about this now than 15 years ago. There is another contention that randomizing pids can help so why not.
Edit to add: we can obviously pass on the RDRAND instruction directly to the VM, but that's less portable, because not all servers in a server farm may have that instruction available, limiting live migration capabilities.
So we can just pass on output from RDSEED into the host's /dev/random, and feed the VM /dev/random by default as described.
other than the x86 instruction set there are some SOCs that embeds a hwrng directly, the one I used is Freescale iMX6 that has a FIPS-certified hwrng, which is very handy.
I've been forced to use rng-tools and / or rng-usleep to get enough randomness in some Ubuntu VMs in the past. It's maddening to see SSL slowdowns for no good reason, and to have to trace it back to a blocking call to /dev/random for 8 lousy bytes.
[1] http://www.vanheusden.com/Linux/#security