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@xxxxxxxxxx>
---
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
