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.)
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/