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.
> This is one way of protecting yourself against hash denial-of-service attacks.
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.
> [...] 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.
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.
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.
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.
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.
> 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?)
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.
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.