FreeBSD 10 recently changed their definition of RAND_MAX, to try
and cover the fact that their evenly distributed results really are
a smaller range than a full power of 2. As a result, I did some
investigation, and learned:
1. POSIX requires random() to be evenly distributed across exactly
31 bits. glibc also guarantees this for rand(), but the two are
unrelated, and POSIX only associates RAND_MAX with rand().
Avoiding RAND_MAX altogether thus avoids a build failure on
FreeBSD 10.
2. Concatenating random bits from a PRNG will NOT provide uniform
coverage over the larger value UNLESS the period of the original
PRNG is at least as large as the number of bits being concatenated.
Simple example: suppose that RAND_MAX were 1 with a period of 2**1
(which means that the PRNG merely alternates between 0 and 1).
Concatenating two successive rand() calls would then invariably
result in 01 or 10, which is a rather non-uniform distribution
(00 and 11 are impossible) and an even worse period (2**0, since
our second attempt will get the same number as our first attempt).
But a RAND_MAX of 1 with a period of 2**2 (alternating between
0, 1, 1, 0) provides sane coverage of all four values, if properly
tempered. (Back-to-back calls would still only see half the values
if we don't do some tempering). We therefore want to guarantee a
period of at least 2**64, preferably larger (as a tempering factor);
POSIX only makes this guarantee for random() with 256 bytes of info.
* src/util/virrandom.c (virRandomBits): Use constants that are
accurate for the PRNG we are using, not an unrelated PRNG.
(randomState): Ensure the period of our PRNG exceeds our usage.
Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>
---
src/util/virrandom.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/src/util/virrandom.c b/src/util/virrandom.c
index c233732..0e368b0 100644
--- a/src/util/virrandom.c
+++ b/src/util/virrandom.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Red Hat, Inc.
+ * Copyright (C) 2012-2013 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -36,7 +36,7 @@
#define VIR_FROM_THIS VIR_FROM_NONE
-static char randomState[128];
+static char randomState[256];
static struct random_data randomData;
static virMutex randomLock;
@@ -70,0 +70,0 @@ virRandomOnceInit(void)
VIR_ONCE_GLOBAL_INIT(virRandom)
-/* The algorithm of virRandomBits requires that RAND_MAX == 2^n-1 for
- * some n; gnulib's random_r meets this property. */
-verify(((RAND_MAX + 1U) & RAND_MAX) == 0);
+/* The algorithm of virRandomBits relies on gnulib's guarantee that
+ * random_r() matches the POSIX requirements on random() of being
+ * evenly distributed among exactly [0, 2**31) (that is, we always get
+ * exactly 31 bits). While this happens to be the value of RAND_MAX
+ * on glibc, note that POSIX only requires RAND_MAX to be tied to the
+ * weaker rand(), so there are platforms where RAND_MAX is smaller
+ * than the range of random_r(). For the results to be evenly
+ * distributed among up to 64 bits, we also rely on the period of
+ * random_r() to be at least 2**64. */
+enum {
+ RANDOM_BITS_PER_ITER = 31,
+ RANDOM_BITS_MASK = (1U << RANDOM_BITS_PER_ITER) - 1,
+};
/**
* virRandomBits:
@@ -85,7 +95,6 @@ verify(((RAND_MAX + 1U) & RAND_MAX) == 0);
*/
uint64_t virRandomBits(int nbits)
{
- int bits_per_iter = count_one_bits(RAND_MAX);
uint64_t ret = 0;
int32_t bits;
@@ -98,10 +107,10 @@ uint64_t virRandomBits(int nbits)
virMutexLock(&randomLock);
- while (nbits > bits_per_iter) {
+ while (nbits > RANDOM_BITS_PER_ITER) {
random_r(&randomData, &bits);
- ret = (ret << bits_per_iter) | (bits & RAND_MAX);
- nbits -= bits_per_iter;
+ ret = (ret << RANDOM_BITS_PER_ITER) | (bits & RANDOM_BITS_MASK);
+ nbits -= RANDOM_BITS_PER_ITER;
}
random_r(&randomData, &bits);
--
1.8.3.1
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list