Weblog entry #56 for dkg

dealing with entropy on a virtual machine
Posted by dkg on Sat 12 Dec 2009 at 18:42
Tags: none.
I've been using virtual machines (KVM, these days) as isolated environments to do things like build packages as root. Unfortunately, some of these activities require decent-sized chunks of random data (pulled from /dev/random). But /dev/random pulls from the kernel's entropy pool, which in turn is replenished from "hardware" events. But a virtual machine has no actual hardware, and if it is only doing isolated package builds, there is very little activity to feed the kernel's entropy pool. So the builds and test suites that rely on this randomness all hang for a long long time. :(

My current way to get around this is to replace /dev/random with the /dev/urandom device, which does not block if the entropy pool is depleted:

mknod /dev/newrandom c 1 9
chmod --reference=/dev/random /dev/newrandom
mv -f /dev/newrandom /dev/random
This has the consequence that the "randomness" these commands use doesn't have as much "real" entropy, though some operating systems (like FreeBSD) have a non-blocking /dev/random by default (and it's also questionable what "real" entropy means for a virtual machine in the first place).

I'm also using cowbuilder within these VMs to do package builds. But cowbuilder has its own /dev tree, with its own device nodes, so this needs to be fixed too. So after you have successfully done cowbuilder --create, you need to modify the random device within the cowbuilder chroot:

mknod /var/cache/pbuilder/base.cow/dev/newrandom c 1 9
chmod --reference=/var/cache/pbuilder/base.cow/dev/random /var/cache/pbuilder/base.cow/dev/newrandom
mv -f /var/cache/pbuilder/base.cow/dev/newrandom /var/cache/pbuilder/base.cow/dev/random
Hopefully this will be useful for other people using cowbuilder (or other build strategies) on isolated virtual machines. If you've worked around this problem in other ways (or if there's a security concern about this approach), i'd be happy to hear about the details.

 

Comments on this Entry

Posted by Anonymous (87.181.xx.xx) on Sat 12 Dec 2009 at 20:53
Maybe virtio-rng is interesting for you.

[ Parent | Reply to this comment ]

Posted by Anonymous (122.200.xx.xx) on Fri 28 Oct 2011 at 15:49
Do you have any document about how to do that...

[ Parent | Reply to this comment ]

Posted by madduck (2a01:0xx:0xx:0xxx:0xxx:0xxx:xx) on Sun 13 Dec 2009 at 08:47
[ Send Message ]
Why don't you just ln -s /dev/random /dev/urandom?

I suggest to get an entropy key (http://www.entropykey.co.uk/), plug it into the host, and use virtio_rng, as suggested by the previous commenter.

[ Parent | Reply to this comment ]

Posted by Anonymous (80.126.xx.xx) on Sun 13 Dec 2009 at 15:06
Maybe http://www.vanheusden.com/entropybroker/ helps you. It enables you to distribute entropy data to other vms or even other systems.

[ Parent | Reply to this comment ]

Posted by Anonymous (95.95.xx.xx) on Sat 19 Dec 2009 at 00:24
# Configuration for the rng-tools initscript
# $Id: rng-tools.default,v 1.1.2.5 2008-06-10 19:51:37 hmh Exp $

# This is a POSIX shell fragment

# Set to the input source for random data, leave undefined
# for the initscript to attempt auto-detection. Set to /dev/null
# for the viapadlock driver.
HRNGDEVICE=/dev/urandom

# Additional options to send to rngd. See the rngd(8) manpage for
# more information. Do not specify -r/--rng-device here, use
# HRNGDEVICE for that instead.
RNGDOPTIONS="--fill-watermark=89% --feed-interval=2 --random-device=/dev/random"

[ Parent | Reply to this comment ]