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

Eric Blake eblake at redhat.com
Tue May 29 20:32:23 UTC 2018


On 05/29/2018 03:24 AM, 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(-)
> 

> -static int
> -virRandomOnceInit(void)
> -{
> -    unsigned int seed = time(NULL) ^ getpid();
> -
> -#if 0
> -    /* Normally we want a decent seed.  But if reproducible debugging
> -     * of a fixed pseudo-random sequence is ever required, uncomment
> -     * this block to let an environment variable force the seed.  */
> -    const char *debug = virGetEnvBlockSUID("VIR_DEBUG_RANDOM_SEED");
> -
> -    if (debug && virStrToLong_ui(debug, NULL, 0, &seed) < 0)
> -        return -1;

Are we sure we don't need the ability to quickly compile in a 
deterministic replacement for debug in the future?  I suppose there's 
always git history, but this particular #if 0 was left in place for a 
reason, where completely removing it makes it harder to realize that 
such debugging is even possible.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org




More information about the libvir-list mailing list