[fluix]

> [...] there's no guarantee that RDRAND won't revert to the -1 behavior after the check runs, perhaps after a VM migration or resume from suspend or what-not.

Author here. This is true and is an issue with some CPUs (breaking RDRAND after resume), but every call to RDRAND is guarded[1] by a check that it works.

[1]: https://github.com/json-c/json-c/blob/041cef434afe0d0c6da8b6...

Edit: Ah, I just realized you stated "after the check runs" and you're correct, there's no way that can be guaranteed.

Edit 2: Well, if RDRAND returns a value json-c can't use (-1) it won't be used.

[benlivengood]

Most unixes on x86 optionally use RDRAND to add entropy to the /dev/random pool and I see that Win32 is also covered in json-c, so I don't see the benefit of explicit support for RDRAND in the critical path at least.

RDRAND may also be slow: https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3...

Ultimately I think it was a mistake for Intel to try to provide user-level hardware random number generation. It's apparently not an easily solved problem and requires complete trust in the hardware and a fallback TRNG/HRNG that's just as secure if the hardware reports that it's not working. Why not just use the fallback all the time? System-level entropy pools are pretty well-studied at this point.

[PhantomGremlin]

I think it was a mistake for Intel to try to provide user-level hardware random number generation.

They probably did this for speed. Faster than library calls or system calls.

It's apparently not an easily solved problem

Apparently too hard for the clowns at AMD. AFAIK it's a "solved problem" on Intel hardware. (Has there ever been a problem with the hardware in any Intel CPU?)

We wouldn't be having this discussion if AMD hadn't royally fucked this up.

[bigiain]

> (Has there ever been a problem with the hardware in any Intel CPU?)

FOOF...

( https://en.wikipedia.org/wiki/Pentium_F00F_bug Admittedly that was in the 90s... )

[PhantomGremlin]

Sorry about that. FOOF did cause some people headaches.

I should have more specifically said, "has there been a problem with RDRAND hardware in any Intel CPU?"

FOOF wasn't a "real" problem for an average user, it had some workarounds. It wasn't even triggered unless you tried to execute an invalid instruction.

Much much much worse was the Intel FDIV bug. That one caused Intel to recall processors and cost them $475 million. https://en.wikipedia.org/wiki/Pentium_FDIV_bug

Lots of jokes resulted. E.g.: We are Pentium of Borg. Division is futile. You will be approximated.

As for RDRAND, Intel put a lot of thought into it. It wasn't just a hack.

Here's a high level presentation. (A friend of mine at Intel thought highly of Dr. George Cox, who was a long time Intel employee). https://old.hotchips.org/wp-content/uploads/hc_archives/hc23...

Here's a little more detail: https://spectrum.ieee.org/computing/hardware/behind-intels-n...

[benlivengood]

> They probably did this for speed. Faster than library calls or system calls.

Xorshift is faster than RDRAND and json-c is using lookup3 for hashing (unless I'm missing some other use of the RDRAND data) so it doesn't need cryptographic RNG.

> Apparently too hard for the clowns at AMD. AFAIK it's a "solved problem" on Intel hardware. (Has there ever been a problem with the hardware in any Intel CPU?)

Meltdown/Spectre of course. As I posted earlier there's also an Intel microcode update that makes RDRAND much slower. https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3...

[rurban]

rdrand besides most likely backdoored is not fast. It's like 1000x slower than the slowest prng call on an unpatched Ryzen. https://rurban.github.io/dieharder/QUALITY.html

[kelnos]

Ugh, this is... unfortunate. Are there really any systems for which all the other options for randomness are not available? I really think there aren't. RDRAND should be near the bottom of the list of things it tries (or just be dropped entirely), not the top.

Wasting time trying to patch over its misbehaviors is just overengineering.