[libvirt] [PATCH 08/10] virrandom: Make virRandomBits better

Martin Kletzander mkletzan at redhat.com
Tue May 29 13:44:28 UTC 2018


On Tue, May 29, 2018 at 10:24:44AM +0200, Michal Privoznik wrote:
>Now that we have strong PRNG generator implemented in
>virRandomBytes() let's use that instead of gnulib's random_r.
>
>Problem with the latter is in way we seed it: current UNIX time
>and libvirtd's PID are not that random as one might think.
>Imagine two hosts booting at the same time. There's a fair chance
>that those hosts spawn libvirtds at the same time and with the
>same PID. This will result in both daemons generating the same
>sequence of say MAC addresses [1].
>
>1: https://www.redhat.com/archives/libvirt-users/2018-May/msg00097.html
>
>Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>---
> src/util/virrandom.c | 63 ++--------------------------------------------------
> 1 file changed, 2 insertions(+), 61 deletions(-)
>

ACK to patches 1-7.  But for this one I'm "concerned" about few things.

First of all, just so I don't forget it, random_r can be removed from
bootstrap.conf after this patch, right?

Before this patch, and without gnutls, we wouldn't deplete the entropy of the
kernel, (even though we're just using /dev/urandom and not /dev/random), but now
we'd read everything from /dev/urandom.

Last but not least, if we completely drop the non-gnutls variants of everything,
wouldn't everything be easier anyway?  Like the worrying about entropy pool in
previous point?

And one thing below:

>diff --git a/src/util/virrandom.c b/src/util/virrandom.c
>index 444b0f9802..01cc82a052 100644
>--- a/src/util/virrandom.c
>+++ b/src/util/virrandom.c
>@@ -108,26 +61,14 @@ VIR_ONCE_GLOBAL_INIT(virRandom)
> uint64_t virRandomBits(int nbits)
> {
>     uint64_t ret = 0;
>-    int32_t bits;
>
>-    if (virRandomInitialize() < 0) {
>+    if (virRandomBytes((unsigned char *) &ret, sizeof(ret)) < 0) {
>         /* You're already hosed, so this particular non-random value
>          * isn't any worse.  */
>         return 0;

We definitely want to return an error here now IMHO.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180529/c7336897/attachment-0001.sig>


More information about the libvir-list mailing list