Virt RNG?

Virt RNG?

[Jeff Garzik]

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.

	Jeff



[1] lkml&netdev thread: "[PATCH] drivers/net: remove network drivers' 
last few uses of IRQF_SAMPLE_RANDOM"

Re: Virt RNG?

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
> 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.

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

Re: Virt RNG?

[Dor Laor]

On Thu, 2008-05-15 at 20:53 +0100, Jeremy Fitzhardinge wrote:
> Jeff Garzik wrote:
> > 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.
> 
> 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.
> 

There was a virtio-rng device:
http://www.mail-archive.com/virtualization@lists.linux-foundation.org/msg02902.html

Need to search what happened to it in Rusty's queues.
>     J
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: Virt RNG?

[Christian Borntraeger]

Am Donnerstag, 15. Mai 2008 schrieb Jeff Garzik:
> 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.

Dont know why it never hit mainline.

Christian

Re: Virt RNG?

[Jeff Dike]

On Thu, May 15, 2008 at 02:48:53PM -0400, Jeff Garzik wrote:
> Has anyone yet written a "hw" RNG module for virt, that reads the host's 
> random number pool?

UML has one, probably not usable as-is by anyone else right now...

    	     	      Jeff

-- 
Work email - jdike at linux dot intel dot com

Re: Virt RNG?

[Jeff Garzik]

Christian Borntraeger wrote:
> Am Donnerstag, 15. Mai 2008 schrieb Jeff Garzik:
>> 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.

Nice!



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

A limitation of the hw-random API.  However, I'd say the virtio rng 
driver could (and should) buffer bigger chunks, say at least a 
cacheline's worth of data, to return via hw-random's 32-bit data request 
API.

	Jeff

Re: Virt RNG?

[Rusty Russell]

On Friday 16 May 2008 04:48:53 Jeff Garzik wrote:
> 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).

One could argue that virtual rng should try to feed the kernel rng directly, 
with or without entropy credit.

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.

Thanks,
Rusty.

Re: Virt RNG?

[Henrique de Moraes Holschuh]

On Fri, 16 May 2008, Rusty Russell wrote:
> 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).

It would be easy to implement rng-tools as a kernel driver, as long as
proper in-kernel interfaces exist for it to work in an event-driven way.
I don't see what we would win over rng-tools in userspace, however.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[PATCH 1/2] virtio: hardware random device

[Rusty Russell]

On Friday 16 May 2008 09:43:08 Rusty Russell wrote:
> 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.

Actually, I didn't miss it.  But I've polished the driver a little more,
here are the patches.

===
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 <rusty@rustcorp.com.au>
---
 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(+)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -112,3 +112,13 @@ config HW_RANDOM_PASEMI
 
 	  If unsure, say Y.
 
+config HW_RANDOM_VIRTIO
+	tristate "VirtIO Random Number Generator support"
+	depends on HW_RANDOM && VIRTIO
+	---help---
+	  This driver provides kernel-side support for the virtual Random Number
+	  Generator hardware.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called virtio-rng.  If unsure, say N.
+
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx
 obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
 obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
+obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c
new file mode 100644
--- /dev/null
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -0,0 +1,143 @@
+/*
+ * Randomness driver for virtio
+ *  Copyright (C) 2007, 2008 Rusty Russell IBM Corporation
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/scatterlist.h>
+#include <linux/spinlock.h>
+#include <linux/virtio.h>
+#include <linux/virtio_rng.h>
+
+/* The host will fill any buffer we give it with sweet, sweet randomness.  We
+ * give it 64 bytes at a time, and the hwrng framework takes it 4 bytes at a
+ * time. */
+static struct virtqueue *vq;
+static u32 random_data[16];
+static unsigned int data_left;
+static DECLARE_COMPLETION(have_data);
+
+static void random_recv_done(struct virtqueue *vq)
+{
+	int len;
+
+	/* We never get spurious callbacks. */
+	if (!vq->vq_ops->get_buf(vq, &len))
+		BUG();
+
+	data_left = len / sizeof(random_data[0]);
+	complete(&have_data);
+}
+
+static void register_buffer(void)
+{
+	struct scatterlist sg;
+
+	sg_init_one(&sg, &random_data, sizeof(random_data));
+	/* There should always be room for one buffer. */
+	if (vq->vq_ops->add_buf(vq, &sg, 0, 1, &random_data) != 0)
+		BUG();
+	vq->vq_ops->kick(vq);
+}
+
+/* At least we don't udelay() in a loop like some other drivers. */
+static int virtio_data_present(struct hwrng *rng, int wait)
+{
+	if (data_left)
+		return 1;
+
+	if (!wait)
+		return 0;
+
+	wait_for_completion(&have_data);
+	return 1;
+}
+
+/* virtio_data_present() must have succeeded before this is called. */
+static int virtio_data_read(struct hwrng *rng, u32 *data)
+{
+	BUG_ON(!data_left);
+
+	*data = random_data[--data_left];
+
+	if (!data_left) {
+		init_completion(&have_data);
+		register_buffer();
+	}
+	return sizeof(*data);
+}
+
+static struct hwrng virtio_hwrng = {
+	.name = "virtio",
+	.data_present = virtio_data_present,
+	.data_read = virtio_data_read,
+};
+
+static int virtrng_probe(struct virtio_device *vdev)
+{
+	int err;
+
+	/* We expect a single virtqueue. */
+	vq = vdev->config->find_vq(vdev, 0, random_recv_done);
+	if (IS_ERR(vq))
+		return PTR_ERR(vq);
+
+	err = hwrng_register(&virtio_hwrng);
+	if (err) {
+		vdev->config->del_vq(vq);
+		return err;
+	}
+
+	register_buffer();
+	return 0;
+}
+
+static void virtrng_remove(struct virtio_device *vdev)
+{
+	vdev->config->reset(vdev);
+	hwrng_unregister(&virtio_hwrng);
+	vdev->config->del_vq(vq);
+}
+
+static struct virtio_device_id id_table[] = {
+	{ VIRTIO_ID_RNG, VIRTIO_DEV_ANY_ID },
+	{ 0 },
+};
+
+static struct virtio_driver virtio_rng = {
+	.driver.name =	KBUILD_MODNAME,
+	.driver.owner =	THIS_MODULE,
+	.id_table =	id_table,
+	.probe =	virtrng_probe,
+	.remove =	__devexit_p(virtrng_remove),
+};
+
+static int __init init(void)
+{
+	return register_virtio_driver(&virtio_rng);
+}
+
+static void __exit fini(void)
+{
+	unregister_virtio_driver(&virtio_rng);
+}
+module_init(init);
+module_exit(fini);
+
+MODULE_DEVICE_TABLE(virtio, id_table);
+MODULE_DESCRIPTION("Virtio random number driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/virtio_rng.h b/include/linux/virtio_rng.h
new file mode 100644
--- /dev/null
+++ b/include/linux/virtio_rng.h
@@ -0,0 +1,8 @@
+#ifndef _LINUX_VIRTIO_RNG_H
+#define _LINUX_VIRTIO_RNG_H
+#include <linux/virtio_config.h>
+
+/* The ID for virtio_rng */
+#define VIRTIO_ID_RNG	4
+
+#endif /* _LINUX_VIRTIO_RNG_H */

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

[Rusty Russell]

This is a simple patch to add support for the virtio "hardware random
generator" to lguest.  It gets about 1.2 MB/sec reading from /dev/hwrng
in the guest.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 Documentation/lguest/lguest.c |   90 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -41,6 +41,7 @@
 #include "linux/virtio_net.h"
 #include "linux/virtio_blk.h"
 #include "linux/virtio_console.h"
+#include "linux/virtio_rng.h"
 #include "linux/virtio_ring.h"
 #include "asm-x86/bootparam.h"
 /*L:110 We can ignore the 39 include files we need for this program, but I do
@@ -195,6 +196,33 @@ static void *_convert(struct iovec *iov,
 #define le16_to_cpu(v16) (v16)
 #define le32_to_cpu(v32) (v32)
 #define le64_to_cpu(v64) (v64)
+
+/* Is this iovec empty? */
+static bool iov_empty(const struct iovec iov[], unsigned int num_iov)
+{
+	unsigned int i;
+
+	for (i = 0; i < num_iov; i++)
+		if (iov[i].iov_len)
+			return false;
+	return true;
+}
+
+/* Take len bytes from the front of this iovec. */
+static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len)
+{
+	unsigned int i;
+
+	for (i = 0; i < num_iov; i++) {
+		unsigned int used;
+
+		used = iov[i].iov_len < len ? iov[i].iov_len : len;
+		iov[i].iov_base += used;
+		iov[i].iov_len -= used;
+		len -= used;
+	}
+	assert(len == 0);
+}
 
 /* The device virtqueue descriptors are followed by feature bitmasks. */
 static u8 *get_feature_bits(struct device *dev)
@@ -1613,6 +1641,64 @@ static void setup_block_file(const char 
 	verbose("device %u: virtblock %llu sectors\n",
 		devices.device_num, le64_to_cpu(conf.capacity));
 }
+
+/* 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.
+ *
+ * The same logic applies, however. */
+static bool handle_rng_input(int fd, struct device *dev)
+{
+	int len;
+	unsigned int head, in_num, out_num, totlen = 0;
+	struct iovec iov[dev->vq->vring.num];
+
+	/* First we need a buffer from the Guests's virtqueue. */
+	head = get_vq_desc(dev->vq, iov, &out_num, &in_num);
+
+	/* If they're not ready for input, stop listening to this file
+	 * descriptor.  We'll start again once they add an input buffer. */
+	if (head == dev->vq->vring.num)
+		return false;
+
+	if (out_num)
+		errx(1, "Output buffers in rng?");
+
+	/* This is why we convert to iovecs: the readv() call uses them, and so
+	 * it reads straight into the Guest's buffer.  We loop to make sure we
+	 * fill it. */
+	while (!iov_empty(iov, in_num)) {
+		len = readv(dev->fd, iov, in_num);
+		if (len <= 0)
+			err(1, "Read from /dev/urandom gave %i", len);
+		iov_consume(iov, in_num, len);
+		totlen += len;
+	}
+
+	/* Tell the Guest about the new input. */
+	add_used_and_trigger(fd, dev->vq, head, totlen);
+
+	/* Everything went OK! */
+	return true;
+}
+
+/* And this creates a "hardware" random number device for the Guest. */
+static void setup_rng(void)
+{
+	struct device *dev;
+	int fd;
+
+	fd = open_or_die("/dev/urandom", O_RDONLY);
+
+	/* The device responds to return from I/O thread. */
+	dev = new_device("rng", VIRTIO_ID_RNG, fd, handle_rng_input);
+
+	/* The device has one virtqueue, where the Guest places inbufs. */
+	add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd);
+
+	verbose("device %u: rng\n", devices.device_num++);
+}
 /* That's the end of device setup. */
 
 /*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
@@ -1683,6 +1769,7 @@ static struct option opts[] = {
 	{ "verbose", 0, NULL, 'v' },
 	{ "tunnet", 1, NULL, 't' },
 	{ "block", 1, NULL, 'b' },
+	{ "rng", 0, NULL, 'r' },
 	{ "initrd", 1, NULL, 'i' },
 	{ NULL },
 };
@@ -1756,6 +1843,9 @@ int main(int argc, char *argv[])
 			break;
 		case 'b':
 			setup_block_file(optarg);
+			break;
+		case 'r':
+			setup_rng();
 			break;
 		case 'i':
 			initrd_name = optarg;

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

[Rusty Russell]

This is a simple patch to add support for the virtio "hardware random
generator" to lguest.  It gets about 1.2 MB/sec reading from /dev/hwrng
in the guest.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 Documentation/lguest/lguest.c |   90 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -41,6 +41,7 @@
 #include "linux/virtio_net.h"
 #include "linux/virtio_blk.h"
 #include "linux/virtio_console.h"
+#include "linux/virtio_rng.h"
 #include "linux/virtio_ring.h"
 #include "asm-x86/bootparam.h"
 /*L:110 We can ignore the 39 include files we need for this program, but I do
@@ -195,6 +196,33 @@ static void *_convert(struct iovec *iov,
 #define le16_to_cpu(v16) (v16)
 #define le32_to_cpu(v32) (v32)
 #define le64_to_cpu(v64) (v64)
+
+/* Is this iovec empty? */
+static bool iov_empty(const struct iovec iov[], unsigned int num_iov)
+{
+	unsigned int i;
+
+	for (i = 0; i < num_iov; i++)
+		if (iov[i].iov_len)
+			return false;
+	return true;
+}
+
+/* Take len bytes from the front of this iovec. */
+static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len)
+{
+	unsigned int i;
+
+	for (i = 0; i < num_iov; i++) {
+		unsigned int used;
+
+		used = iov[i].iov_len < len ? iov[i].iov_len : len;
+		iov[i].iov_base += used;
+		iov[i].iov_len -= used;
+		len -= used;
+	}
+	assert(len == 0);
+}
 
 /* The device virtqueue descriptors are followed by feature bitmasks. */
 static u8 *get_feature_bits(struct device *dev)
@@ -1613,6 +1641,64 @@ static void setup_block_file(const char 
 	verbose("device %u: virtblock %llu sectors\n",
 		devices.device_num, le64_to_cpu(conf.capacity));
 }
+
+/* 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.
+ *
+ * The same logic applies, however. */
+static bool handle_rng_input(int fd, struct device *dev)
+{
+	int len;
+	unsigned int head, in_num, out_num, totlen = 0;
+	struct iovec iov[dev->vq->vring.num];
+
+	/* First we need a buffer from the Guests's virtqueue. */
+	head = get_vq_desc(dev->vq, iov, &out_num, &in_num);
+
+	/* If they're not ready for input, stop listening to this file
+	 * descriptor.  We'll start again once they add an input buffer. */
+	if (head == dev->vq->vring.num)
+		return false;
+
+	if (out_num)
+		errx(1, "Output buffers in rng?");
+
+	/* This is why we convert to iovecs: the readv() call uses them, and so
+	 * it reads straight into the Guest's buffer.  We loop to make sure we
+	 * fill it. */
+	while (!iov_empty(iov, in_num)) {
+		len = readv(dev->fd, iov, in_num);
+		if (len <= 0)
+			err(1, "Read from /dev/urandom gave %i", len);
+		iov_consume(iov, in_num, len);
+		totlen += len;
+	}
+
+	/* Tell the Guest about the new input. */
+	add_used_and_trigger(fd, dev->vq, head, totlen);
+
+	/* Everything went OK! */
+	return true;
+}
+
+/* And this creates a "hardware" random number device for the Guest. */
+static void setup_rng(void)
+{
+	struct device *dev;
+	int fd;
+
+	fd = open_or_die("/dev/urandom", O_RDONLY);
+
+	/* The device responds to return from I/O thread. */
+	dev = new_device("rng", VIRTIO_ID_RNG, fd, handle_rng_input);
+
+	/* The device has one virtqueue, where the Guest places inbufs. */
+	add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd);
+
+	verbose("device %u: rng\n", devices.device_num++);
+}
 /* That's the end of device setup. */
 
 /*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
@@ -1683,6 +1769,7 @@ static struct option opts[] = {
 	{ "verbose", 0, NULL, 'v' },
 	{ "tunnet", 1, NULL, 't' },
 	{ "block", 1, NULL, 'b' },
+	{ "rng", 0, NULL, 'r' },
 	{ "initrd", 1, NULL, 'i' },
 	{ NULL },
 };
@@ -1756,6 +1843,9 @@ int main(int argc, char *argv[])
 			break;
 		case 'b':
 			setup_block_file(optarg);
+			break;
+		case 'r':
+			setup_rng();
 			break;
 		case 'i':
 			initrd_name = optarg;

Re: [PATCH 1/2] virtio: hardware random device

[Christian Borntraeger]

Am Freitag, 16. Mai 2008 schrieb Rusty Russell:
> 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 <rusty@rustcorp.com.au>
> ---
>  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(+)

Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>

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

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 386 bytes --]


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

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

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

[H. Peter Anvin]

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?

Only if you have an entropy estimate to go with it.  It's still dubious, 
though: the guests own pool will do its own mixing, so you might as well 
pull from /dev/random in the host as being a genuine entropy source and 
only add what entropy is available.

	-hpa

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

[Rusty Russell]

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

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?

Cheers,
Rusty.

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

[H. Peter Anvin]

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.

> 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?

/dev/random	= give me actual entropy, if you have some.
/dev/urandom	= give me what you have, regardless of quality.

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.

	-hpa

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

[Rusty Russell]

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.

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

> 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?

Thanks,
Rusty.

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

[Herbert Xu]

On Sat, May 17, 2008 at 04:28:03PM +1000, Rusty Russell wrote:
>
> 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?

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.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Christian Borntraeger]

Am Samstag, 17. Mai 2008 schrieb Herbert Xu:
> On Sat, May 17, 2008 at 04:28:03PM +1000, Rusty Russell wrote:
> >
> > 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?
> 
> 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.

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

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

[Jeremy Fitzhardinge]

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

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

[H. Peter Anvin]

Christian Borntraeger wrote:
> I think the proper solution would be to use the hosts /dev/hw_rng - if 
> available.

Not really, no.  The host has access to real entropy in the form of 
hardware timings as well as possibly /dev/hw_rng.

	-hpa

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

[H. Peter Anvin]

Rusty Russell wrote:
>> 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.

We can, if it comes from /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?
>> 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.

Only up to a point.

>> 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 don't think you have a DoS situation at all.  The worst thing is that 
you don't have any entropy available at all, at which point /dev/urandom 
is as insecure as it ever is.

	-hpa

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

[Rusty Russell]

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.

Thanks,
Rusty.

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

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> 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.

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

Well, I think having some rate-limiting controls would be nice to have, 
but certainly not a show-stopper for a first implementation.

    J

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

[Rusty Russell]

On Monday 19 May 2008 19:10:49 Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > 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.

Cheers,
Rusty.

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

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> 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.

Yeah, that's a bit of a pity.  Hardware rngs can often generate really 
crappy randomness, which needs tons of processing to remove noise like 
50/60hz hum, etc.

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

Well, yes, we can certainly do any amount of processing we like to the 
stuff provided to guests, so that the 1:1 bits/entropy ratio is as true 
as we can make it.

    J