Comment by jstanley

I was going to suggest exactly that, if you're got an RNG, or pretty much anything else for that matter, you need the ability to return some sort of things-went-wrong-somewhere indicator value, and presumably AMD is using 0 to do this. Yes, there's also the CF, but the caller may not be checking that, particularly if it's being done from a HLL.

Has anyone checked whether it can return ~0, (signed) -1, the traditional error-return value?

No, CF=0 occurences seem to be happen frequently and uniformely distributed like valid results at ~1/65536, not clustered. Under a minute-long all-core load CF=0 always produces zero, but that's to be expected according to the manual.

Here are some stats:

    Rounds (N): 1000000000
    Failed (F): 15312
    Valid  (V): 999984688
    N/65536: 15258.789
    V/65536: 15258.555
    Failed, result was zero: 15312
    Failed, result non-zero: 0
    Bucket value for      0: 15312
    Bucket value for      1: 15290
    Bucket value for  65535: 15223
    Min bucket value: 14670
    Max bucket value: 15835

I used this C program to collect them:

    #include <stdio.h>
    #include <stdint.h>
    #include <stdbool.h>

    const size_t N = 1000000000; // 1e9

    struct rdrand16_result {
        uint16_t n;
        bool ok;
    };

    static inline struct rdrand16_result rdrand16()
    {
        struct rdrand16_result result;
        __asm__ __volatile__( "rdrand %0" : "=r" (result.n), "=@ccc" (result.ok) );
        return result;
    }

    int main()
    {
        size_t buckets[0xFFFF + 1] = { 0 };
        size_t notok = 0, notok_zero = 0, notok_nonz = 0;
        for (size_t i = 0; i < N; ++i) {
            struct rdrand16_result result = rdrand16();
            ++buckets[result.n];
            if (! result.ok) {
                ++notok;
                notok_zero += result.n == 0;
                notok_nonz += result.n != 0;
            }
        }
        size_t max = 0, min = N;
        for (size_t i = 0; i <= 0xFFFF; ++i) {
            size_t n = buckets[i];
            min = n < min ? n : min;
            max = n > max ? n : max;
        }
        printf("Rounds (N): %zu\n", N);
        printf("Failed (F): %zu\n", notok);
        printf("Valid  (V): %zu\n", N - notok);
        printf("N/65536: %.3f\n", (double)N / 65536);
        printf("V/65536: %.3f\n", (double)(N - notok) / 65536);
        printf("Failed, result was zero: %zu\n", notok_zero);
        printf("Failed, result non-zero: %zu\n", notok_nonz);
        printf("Bucket value for      0: %zu\n", buckets[0]);
        printf("Bucket value for      1: %zu\n", buckets[1]);
        printf("Bucket value for  65535: %zu\n", buckets[0xFFFF]);
        printf("Min bucket value: %zu\n", min);
        printf("Max bucket value: %zu\n", max);
        return 0;
    }

And for the full fail story behind it, fail0verflow hacking the PS3 presentation is great and covers the bug: https://youtu.be/DUGGJpn2_zY

Most of the console hacking talks are great, both informative and entertaining.

CVE-2008-0166 (Debian OpenSSL Predictable PRNG Vulnerability) inspired xkcd/221 but this sort of thing happens a lot :)

https://i.imgur.com/bwFWMqQ.png

Careful, there is two different things going on here:

a) whether you use the maybe-entropy provided by the CPU (and/or the bootloader)

b) whether you credit that maybe-entropy towards your tracking of whether the pool should be considered sufficiently seeded

random.trust_cpu/random.trust_bootloader configures b).

nordrand has been removed from the kernel as it had become overloaded by meaning both a) and b)

Under most circumstances, a) is harmless. You mostly want that off when the CPU exhibits some performance hiccups when asked.

Under some circumstances, b) is outright dangerous. Some applications can work without seeded pool at some slightly reduced performance, but could be made to fail miserably if they had been made to believe that the pool was seeded yet it was not. This happens with hash tables when you skip some of the accounting because it seems no longer relevant. It really would not be relevant, once even a determined attacker should be unable to reliably trigger the worst-case-performance.

As far as I know that is correct; the kernel was written in a way such that one bad source doesn’t poison the pool. Still, if you know one source is bad, might as well take it out.

> E.g. if you have rand source A, and xor it with rand source B, then you get, at worst, the best of A and B,

With the assumption that sources A and B are independent from each other.

this is generally true however if an adversary is able to control a source it becomes dangerous if they can preview the results or inspect the other sources.

You should be using &0xFFFF for masking. Your mod is off by 1 too.

How about* rdrand32()%65536? Taking the remainder by 65535 doesn't take the lowest 16 bits after all

*: missed a word the first time around