Virt RNG?

Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?

All this talk[1] about IRQF_SAMPLE_RANDOM in network drivers reminds me that virt guest instances should be grabbing random numbers from the host, especially if the host has a hardware RNG.

Quoted 3 lines · Jeff Garzik

Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?

Quoted 3 lines

All this talk[1] about IRQF_SAMPLE_RANDOM in network drivers reminds me that virt guest instances should be grabbing random numbers from the host, especially if the host has a hardware RNG.

It was actually one of the first device types proposed for what would become virtio, but as far as I know there has been no work on such a device. It certainly makes lots of sense.

J
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?

All this talk[1] about IRQF_SAMPLE_RANDOM in network drivers reminds me that virt guest instances should be grabbing random numbers from the host, especially if the host has a hardware RNG.

Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?

Am Donnerstag, 15. Mai 2008 schrieb Jeff Garzik:

Quoted 3 lines

Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?

All this talk[1] about IRQF_SAMPLE_RANDOM in network drivers reminds me that virt guest instances should be grabbing random numbers from the host, especially if the host has a hardware RNG.

Yes, there was a drivers/char/hw_random/virtio-rng.c in Rusty's lguest repository. http://www.mail-archive.com/virtualization%40lists.linux-foundation.org/msg02902.html

I have tested this driver with this fix
https://lists.linux-foundation.org/pipermail/virtualization/2008-January/009737.html
and it worked.

As it transfers only 4 byte per hypercall it is not mindblowingly fast, but I guess it is fast enough.

Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?

All this talk[1] about IRQF_SAMPLE_RANDOM in network drivers reminds me that virt guest instances should be grabbing random numbers from the host, especially if the host has a hardware RNG.

Yes, I prepared one earlier. I was a little surprised to see that hwrng drivers don't contribute in any way to the entropy pool though, but now reading the thread I find out about rngd (not installed on my Ubuntu system, but available at least).

Anyway, since there's interest, I'll drag virtio_rng from the bottom of the queue, apply Christian's fix (which I somehow missed before, sorry Christian), and re-post.

Anyway, since there's interest, I'll drag virtio_rng from the bottom of the queue, apply Christian's fix (which I somehow missed before, sorry Christian), and re-post.

virtio: An entropy device, as suggested by hpa.

Note that by itself, having a "hardware" random generator does very
little: you should probably run "rngd" in your guest to feed this into the kernel entropy pool.

Signed-off-by Rusty Russell <[email protected]>

---
 drivers/char/hw_random/Kconfig      |   10 ++
 drivers/char/hw_random/Makefile     |    1 
 drivers/char/hw_random/virtio-rng.c |  143 +++++++++++++++++++++++++++++++
 include/linux/virtio_rng.h          |    8 ++
 4 files changed, 162 insertions(+)

virtio: An entropy device, as suggested by hpa.

Note that by itself, having a "hardware" random generator does very
little: you should probably run "rngd" in your guest to feed this into the kernel entropy pool.

Signed-off-by Rusty Russell <[email protected]>

---
 drivers/char/hw_random/Kconfig      |   10 ++
 drivers/char/hw_random/Makefile     |    1 
 drivers/char/hw_random/virtio-rng.c |  143 +++++++++++++++++++++++++++++++
 include/linux/virtio_rng.h          |    8 ++
 4 files changed, 162 insertions(+)

Documentation/lguest/lguest.c static void setup_block_file(const char · line 1648

Quoted 5 lines

Documentation/lguest/lguest.c +5 -0

+
+/* 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?

Documentation/lguest/lguest.c static void setup_block_file(const char · line 1648

Quoted 5 lines

Documentation/lguest/lguest.c +5 -0

+
+/* 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?

Documentation/lguest/lguest.c static void setup_block_file(const char · line 1648

Quoted 5 lines

Documentation/lguest/lguest.c +5 -0

+
+/* 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?

Documentation/lguest/lguest.c static void setup_block_file(const char · line 1648

Quoted 5 lines

Documentation/lguest/lguest.c +5 -0

+
+/* 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?

Quoted 7 lines · On Friday 16 May 2008 20:49:41 Johannes Berg wrote:

Documentation/lguest/lguest.c static void setup_block_file(const char · line 1648

Quoted 5 lines

Documentation/lguest/lguest.c +5 -0

+
+/* 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).

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?

Quoted 10 lines · Rusty Russell

Quoted 8 lines · On Friday 16 May 2008 20:49:41 Johannes Berg wrote:

Quoted 5 lines

(quoted diff) +2 -0

+
+/* 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?

Quoted 2 lines

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.

Quoted 2 lines

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.

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

Quoted 10 lines · Rusty Russell

Quoted 8 lines · On Friday 16 May 2008 20:49:41 Johannes Berg wrote:

Quoted 5 lines

(quoted diff) +2 -0

+
+/* 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?

Quoted 2 lines

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.

Quoted 2 lines

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.

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?

Quoted 2 lines

But you did not address the DoS question: can we ignore it? Or are we

Quoted 1 line

off a DoS in the host against a potential security weakness in the guest?

Why not do both? Use the host's urandom to make the guest at least unpredictable on start-up without increasing the guest's entropy, and use the host's random to actually increase the guest's entropy.

Quoted 16 lines · On Saturday 17 May 2008 14:50:31 H. Peter Anvin wrote:

Quoted 14 lines · Rusty Russell

Quoted 9 lines · On Friday 16 May 2008 20:49:41 Johannes Berg wrote:

Quoted 6 lines

(quoted diff) +2 -0

+
+/* 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).

Quoted 3 lines

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 3 lines

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?

Quoted 13 lines · On Saturday 17 May 2008 14:50:31 H. Peter Anvin wrote:

Quoted 11 lines · Rusty Russell

Quoted 9 lines · On Friday 16 May 2008 20:49:41 Johannes Berg wrote:

Quoted 6 lines

(quoted diff) +2 -0

+
+/* 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?

Quoted 6 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 2 lines

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?

I think the proper solution would be to use the hosts /dev/hw_rng - if available.

Quoted 2 lines

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 2 lines

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?

I think the proper solution would be to use the hosts /dev/hw_rng - if available.

Quoted 2 lines

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.

Quoted 3 lines

Quoted 2 lines

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.

Quoted 1 line

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?

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

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

Quoted 3 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:

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

If we go down that path, we have to come up with a way of feeding that information to guest userspace. Patches welcome. If we meanwhile assume entropy == #bits, it fits the current /dev/hwrng model, and we can add an entropy count later if we want to change that.

I'll change my lguest implementation to suck from /dev/random, since noone else seems to consider its depletion to be a real issue. It's no worse than what any other process can do.

Quoted 3 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:

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

If we go down that path, we have to come up with a way of feeding that information to guest userspace. Patches welcome. If we meanwhile assume entropy == #bits, it fits the current /dev/hwrng model, and we can add an entropy count later if we want to change that.

I'll change my lguest implementation to suck from /dev/random, since noone else seems to consider its depletion to be a real issue. It's no worse than what any other process can do.

Quoted 8 lines · Rusty Russell

Quoted 2 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:

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

If we go down that path, we have to come up with a way of feeding that information to guest userspace. Patches welcome. If we meanwhile assume entropy == #bits, it fits the current /dev/hwrng model, and we can add an entropy count later if we want to change that.

Really? Wouldn't guest userspace just use /dev/random as usual, which I think does have an ioctl to give that kind of information? And the interfaces do allow things injecting entropy into the kernel pool to provide entropy estimates along with the actual bits themselves.

Quoted 8 lines · Rusty Russell

Quoted 2 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:

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

If we go down that path, we have to come up with a way of feeding that information to guest userspace. Patches welcome. If we meanwhile assume entropy == #bits, it fits the current /dev/hwrng model, and we can add an entropy count later if we want to change that.

Really? Wouldn't guest userspace just use /dev/random as usual, which I think does have an ioctl to give that kind of information? And the interfaces do allow things injecting entropy into the kernel pool to provide entropy estimates along with the actual bits themselves.

Unfortunately not. Hardware randomness devices export /dev/hwrng, and it's up to userspace to feed that into /dev/random (or not). That's usually done by rngd, which at least on my system, assumes 1 bit of entropy per bit of data from /dev/hwrng by default.

I was a little surprised that this decision was exported to userspace, but if you're not prepared to unconditionally trust hw rngs, it makes sense to palm it off.

We could write a boutique device for virtualization which *did* feed
directly, but that would be a little gauche.

Unfortunately not. Hardware randomness devices export /dev/hwrng, and it's up to userspace to feed that into /dev/random (or not). That's usually done by rngd, which at least on my system, assumes 1 bit of entropy per bit of data from /dev/hwrng by default.

I was a little surprised that this decision was exported to userspace, but if you're not prepared to unconditionally trust hw rngs, it makes sense to palm it off.

We could write a boutique device for virtualization which *did* feed
directly, but that would be a little gauche.