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.
Jeff
[1] lkml&netdev thread: "[PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM"
Quoted 6 lines · 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_RANDOMin 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
Quoted 4 lines · Jeremy Fitzhardinge
Quoted 3 lines · Jeff Garzik
Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?
Quoted 8 lines
Quoted 3 lines
All this talk[1] about
IRQF_SAMPLE_RANDOMin 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/[email protected]/msg02902.html
Need to search what happened to it in Rusty's queues.
Quoted 5 lines
J
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Am Donnerstag, 15. Mai 2008 schrieb Jeff Garzik:
Quoted 6 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_RANDOMin 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
Quoted 10 lines · Christian Borntraeger
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_RANDOMin 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.cin Rusty's lguest repository. http://www.mail-archive.com/virtualization%40lists.linux-foundation.org/msg02902.htmlI have tested this driver with this fix
https://lists.linux-foundation.org/pipermail/virtualization/2008-January/009737.html
and it worked.
Nice!
Quoted 1 line
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
Quoted 2 lines · Jeff Garzik
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
Signature · 1 line
Work email - jdike at linux dot intel dot com
Quoted 6 lines · 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_RANDOMin 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.
Quoted 4 lines · Rusty Russell
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.
Signature · 4 lines
"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
In reply to Rusty RussellQuoted 3 lines · On Friday 16 May 2008 09:43:08 Rusty Russell wrote:
Anyway, since there's interest, I'll drag
virtio_rngfrom 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.
--- 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(+)
drivers/char/hw_random/Kconfig +10 -0
@@ -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. +
drivers/char/hw_random/Makefile +1 -0
@@ -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
drivers/char/hw_random/virtio-rng.c new file +143 -0
143 lines not on this page · raw message
include/linux/virtio_rng.h new file +8 -0
@@ -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 1/2 virtio: hardware random device
In reply to Rusty RussellQuoted 3 lines · On Friday 16 May 2008 09:43:08 Rusty Russell wrote:
Anyway, since there's interest, I'll drag
virtio_rngfrom 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.
--- 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(+)
drivers/char/hw_random/Kconfig +10 -0
@@ -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. +
drivers/char/hw_random/Makefile +1 -0
@@ -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
drivers/char/hw_random/virtio-rng.c new file +143 -0
143 lines not on this page · raw message
include/linux/virtio_rng.h new file +8 -0
@@ -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
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.
--- Documentation/lguest/lguest.c | 90 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+)
Documentation/lguest/lguest.c +90 -0
@@ -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 charverbose ("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
In reply to Rusty RussellThis 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.
--- Documentation/lguest/lguest.c | 90 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+)
Documentation/lguest/lguest.c +90 -0
@@ -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 charverbose ("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
In reply to Rusty RussellThis 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.
--- Documentation/lguest/lguest.c | 90 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+)
Documentation/lguest/lguest.c +90 -0
@@ -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 charverbose ("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 2/2] lguest: virtio-rng support
Documentation/lguest/lguest.c static void setup_block_file(const char · line 1648
Quoted 6 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?
johannes
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/2] lguest: virtio-rng support
In reply to Rusty RussellDocumentation/lguest/lguest.c static void setup_block_file(const char · line 1648
Quoted 6 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?
johannes
Re: [PATCH 2/2] lguest: virtio-rng support
Quoted 8 lines · Johannes Berg
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/urandomto 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
In reply to Johannes BergQuoted 8 lines · Johannes Berg
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/urandomto 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
In reply to Johannes BergQuoted 8 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/urandomto 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
In reply to Johannes BergQuoted 8 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/urandomto 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
Quoted 11 lines · Rusty Russell
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/urandomto fill the guests/dev/random?Technically it's up to rngd in the guest to decide whether to feed entropy or not (ie.
/dev/urandomor/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/randomin the host, we risk a DoS. But since/dev/randomis 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
Quoted 11 lines · On Saturday 17 May 2008 14:50:31 H. Peter Anvin wrote:
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 theGuest's + * input buffers. The usual case is that the Guest doesn't want random numbers + * and so has no buffers although
/dev/urandomis still readable, whereas + * console is the reverse.Is it really a good idea to use the hosts
/dev/urandomto fill the guests/dev/random?
Quoted 5 lines
Quoted 2 lines
Technically it's up to rngd in the guest to decide whether to feed entropy or not (ie.
/dev/urandomor/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 6 lines
Quoted 2 lines
If we use
/dev/randomin the host, we risk a DoS. But since/dev/randomis 0666 on my system, perhaps noone actually cares?There is no point in feeding the host
/dev/urandomto 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?
Thanks,
Rusty.
Re: [PATCH 2/2] lguest: virtio-rng support
In reply to H. Peter AnvinQuoted 11 lines · On Saturday 17 May 2008 14:50:31 H. Peter Anvin wrote:
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 theGuest's + * input buffers. The usual case is that the Guest doesn't want random numbers + * and so has no buffers although
/dev/urandomis still readable, whereas + * console is the reverse.Is it really a good idea to use the hosts
/dev/urandomto fill the guests/dev/random?
Quoted 5 lines
Quoted 2 lines
Technically it's up to rngd in the guest to decide whether to feed entropy or not (ie.
/dev/urandomor/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 6 lines
Quoted 2 lines
If we use
/dev/randomin the host, we risk a DoS. But since/dev/randomis 0666 on my system, perhaps noone actually cares?There is no point in feeding the host
/dev/urandomto 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?
Thanks,
Rusty.
Herbert Xu
maintainerRe: [PATCH 2/2] lguest: virtio-rng support
Quoted 3 lines · Rusty Russell
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,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH 2/2] lguest: virtio-rng support
Am Samstag, 17. Mai 2008 schrieb Herbert Xu:
Quoted 3 lines · Rusty Russell
Quoted 2 lines
But you did not address the DoS question: can we ignore it? Or are we
trading
Quoted 5 lines
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.
I think the proper solution would be to use the hosts /dev/hw_rng - if available.
Re: [PATCH 2/2] lguest: virtio-rng support
Quoted 2 lines · Christian Borntraeger
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
In reply to Christian BorntraegerQuoted 1 line · Christian Borntraeger
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
In reply to Rusty RussellQuoted 18 lines · Rusty Russell
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 theGuest's + * input buffers. The usual case is that the Guest doesn't want random numbers + * and so has no buffers although
/dev/urandomis still readable, whereas + * console is the reverse.Is it really a good idea to use the hosts
/dev/urandomto fill the guests/dev/random?Technically it's up to rngd in the guest to decide whether to feed entropy or not (ie.
/dev/urandomor/dev/random).
Quoted 7 lines
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.
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.
Quoted 12 lines
Quoted 7 lines
Quoted 3 lines
If we use
/dev/randomin the host, we risk a DoS. But since/dev/randomis 0666 on my system, perhaps noone actually cares?There is no point in feeding the host
/dev/urandomto 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/urandomfrom the host will make/dev/urandomharder 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.
Quoted 8 lines
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?
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
In reply to Rusty RussellQuoted 15 lines · Rusty Russell
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 theGuest's + * input buffers. The usual case is that the Guest doesn't want random numbers + * and so has no buffers although
/dev/urandomis still readable, whereas + * console is the reverse.Is it really a good idea to use the hosts
/dev/urandomto fill the guests/dev/random?
Quoted 9 lines
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/urandomor/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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
If we use
/dev/randomin the host, we risk a DoS. But since/dev/randomis 0666 on my system, perhaps noone actually cares?There is no point in feeding the host
/dev/urandomto 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/urandomfrom the host will make/dev/urandomharder 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.
Quoted 6 lines
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?
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
Quoted 2 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:
But the
host->guestprotocol 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
In reply to Jeremy FitzhardingeQuoted 2 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:
But the
host->guestprotocol 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
Quoted 11 lines · Rusty Russell
Quoted 3 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:
But the
host->guestprotocol 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/hwrngmodel, 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 4 lines
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
In reply to Rusty RussellQuoted 8 lines · Rusty Russell
Quoted 3 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:
But the
host->guestprotocol 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/hwrngmodel, 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 2 lines
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
Quoted 10 lines · On Monday 19 May 2008 19:10:49 Jeremy Fitzhardinge wrote:
Quoted 8 lines · Rusty Russell
Quoted 2 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:
But the
host->guestprotocol 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/hwrngmodel, and we can add an entropy count later if we want to change that.
Quoted 4 lines
Really? Wouldn't guest userspace just use
/dev/randomas 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
In reply to Jeremy FitzhardingeQuoted 10 lines · On Monday 19 May 2008 19:10:49 Jeremy Fitzhardinge wrote:
Quoted 8 lines · Rusty Russell
Quoted 2 lines · On Saturday 17 May 2008 17:47:01 Jeremy Fitzhardinge wrote:
But the
host->guestprotocol 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/hwrngmodel, and we can add an entropy count later if we want to change that.
Quoted 4 lines
Really? Wouldn't guest userspace just use
/dev/randomas 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
Quoted 8 lines · Rusty Russell
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/hwrngby 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.
Quoted 3 lines
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
Re: [PATCH 2/2] lguest: virtio-rng support
In reply to Rusty RussellQuoted 3 lines · Rusty Russell
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/hwrngby 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.
Quoted 3 lines
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
Re: [PATCH 2/2] lguest: virtio-rng support
In reply to Rusty RussellQuoted 5 lines · Rusty Russell
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.
We can, if it comes from /dev/random.
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
If we use
/dev/randomin the host, we risk a DoS. But since/dev/randomis 0666 on my system, perhaps noone actually cares?There is no point in feeding the host
/dev/urandomto 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/urandomfrom the host will make/dev/urandomharder to predict in the guest.
Only up to a point.
Quoted 7 lines
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 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
In reply to Rusty RussellQuoted 4 lines · Rusty Russell
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.
We can, if it comes from /dev/random.
Quoted 5 lines
Quoted 3 lines
Quoted 2 lines
If we use
/dev/randomin the host, we risk a DoS. But since/dev/randomis 0666 on my system, perhaps noone actually cares?There is no point in feeding the host
/dev/urandomto 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/urandomfrom the host will make/dev/urandomharder to predict in the guest.
Only up to a point.
Quoted 5 lines
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?
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 1/2] virtio: hardware random device
In reply to Rusty RussellAm Freitag, 16. Mai 2008 schrieb Rusty Russell:
Quoted 6 lines
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.
Quoted 7 lines
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(+)
Re: [PATCH 1/2] virtio: hardware random device
In reply to Rusty RussellAm Freitag, 16. Mai 2008 schrieb Rusty Russell:
Quoted 6 lines
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.
Quoted 7 lines
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(+)