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.
benlivengood|5 years ago
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.
fluix|5 years ago
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.