It seems json-c uses a random number generator to get a seed that it then uses for string hashing. This is one way of protecting yourself against hash denial-of-service attacks.
https://github.com/json-c/json-c/blob/df27756491abf9ecce648c...
https://github.com/json-c/json-c/blob/df27756491abf9ecce648c...
Ironic, in this case. And the fix isn't much better; 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.
Overall RDRAND seems to be a terrible userspace instruction. Special-casing its use sounds more complicated then proper multi-platform support for system RNGs.
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.
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.
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.
FOOF...
( https://en.wikipedia.org/wiki/Pentium_F00F_bug Admittedly that was in the 90s... )
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...
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...
Wasting time trying to patch over its misbehaviors is just overengineering.