Random Numbers in Virtual Machines | Hacker News Reader

Random Numbers in Virtual Machines

rhelblog.redhat.com

56 pointsruda17 comments

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.

[1] http://www.vanheusden.com/Linux/#security

Over at Greenhost we use entropybroker from vanheusden to spread entropy to our VM´s. https://greenhost.net/2015/03/16/spreading-chaos-and-entropy...

this looks good comparing to the virtio-rng approach

Until three weeks ago, ArchLinux shipped with a dangerous and completely useless rng-tools package, which was used by major EC2 AMIs:

https://bugs.archlinux.org/task/34580

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.

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.

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)

http://lpeer.blogspot.co.uk/2010/04/switching-from-c-to-java...

http://lpeer.blogspot.co.uk/2010/05/casing-moving-target.htm...

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

> generating random PIDs for processes

Just curious, but why should PIDs be randomized? Using 'watch pidof pidof' on my laptop, PIDs seems not so randomized.

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.

See http://marc.info/?t=94754302700001&r=1&w=1 and http://marc.info/?t=94759485200001&r=1&w=1 for old discussion.

It seems hwrng is mandatory otherwise /dev/random will block easily for virtio-rng.

Modern Intel processors have an RDRAND instruction which (cue conspiracy theorists) is a hardware RNG. https://en.wikipedia.org/wiki/RdRand

However, it's RDSEED that needs to be used as input if we use the Intel instructions.

https://software.intel.com/en-us/blogs/2012/11/17/the-differ...

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.

The host has more sources that contribute to the kernel entropy pool: network and block IO are more than any individual VM.

Keep in mind, though, that just accessing /dev/urandom in the guest won't need too much input from the host.

However, having a hwrng is obviously the preferred option where there is need for a lot of entropy.

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.

how many apps or software follow the random number recommendations described here?

Reply on news.ycombinator.com