Re: [PATCH 2/2] lguest: virtio-rng support

From: Jeremy Fitzhardinge
Date: Sat May 17 2008 - 03:47:38 EST

Rusty Russell wrote:
On Saturday 17 May 2008 14:50:31 H. Peter Anvin wrote:
Rusty Russell wrote:
On Friday 16 May 2008 20:49:41 Johannes Berg wrote:
+/* Our random number generator device reads from /dev/urandom into the
Guest's + * input buffers. The usual case is that the Guest doesn't
want random numbers + * and so has no buffers although /dev/urandom is
still readable, whereas + * console is the reverse.
Is it really a good idea to use the hosts /dev/urandom to fill the
guests /dev/random?
Technically it's up to rngd in the guest to decide whether to feed
entropy or not (ie. /dev/urandom or /dev/random).
Uhm, no. It's not. Unless the host provides actual entropy
information, you have a security hole.

Huh? We just can't assume it adds entropy. AFAICT rngd -H0 is what we want here.

Hm, the Fedora manpage doesn't mention a -H option.

But the host->guest protocol should include the number of bits estimated entropy along with the bits themselves.

If we use /dev/random in the host, we risk a DoS. But since /dev/random
is 0666 on my system, perhaps noone actually cares?
There is no point in feeding the host /dev/urandom to the guest (except for seeding, which can be handled through other means); it will do its own mixing anyway.

Seeding is good, but unlikely to be done properly for first boot of some standard virtualized container. In practice, feeding /dev/urandom from the host will make /dev/urandom harder to predict in the guest.

Yes, but only because the host /dev/urandom has some amount of real entropy in it, in which case you may as well use some bits from /dev/random. The guests are perfectly capable of implementing all the /dev/urandom mixing algorithms for themselves; all they need is some real entropy to start working with.

The reason to provide anything at all from the host is to give it "golden" entropy bits.

But you did not address the DoS question: can we ignore it? Or are we trading off a DoS in the host against a potential security weakness in the guest?

If so, how do we resolve it?

Entropy is a (typically) scarce resource which is generated at X bits/second. If you're worried about an entropy-eating DoS, then you deal with it like any other resource you're providing to guests: make the host side rate-limit the guest entropy consumption to Y bits/sec (Y <= X). And if you can estimate how much remaining entropy exists in the host /dev/random, you can set a lower bound on what you provide to guests so that the host always has something to work with.

Of course, there's no real reason that we need to provide guest entropy from the host's /dev/random at all. If we're collecting entropy from various entropy sources and feeding them all into a usermode daemon to do all the whitening, etc, then we can just provide it directly from that, leaving /dev/random available for purely host use. (There's probably be some entropy exchange between the daemon and host /dev/random, depending on what entropy sources are available to the host.)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at