While the risk of the RDRAND instruction failing in such a fashion is minor, the current implementation allows the process to continue if such an occurrence happens.
Checking for such an occurrence and calling RandFailure() if it occurs is a safer alternative than failing silently.
While the risk of the RDRAND instruction failing in such a fashion is minor, the current implementation allows the process to continue if such an occurrence happens.
Checking for such an occurrence and calling RandFailure() if it occurs is a safer alternative than failing silently.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34348.
See the guideline for information on the review process. A summary of reviews will appear here.
I’m dubious, since this will cause a total failure on (any?) platforms where its not correctly supported. But on platforms where its detectably not supported it’s just not used. ISTM this should behave like g_rdrand_supported == False, except perhaps in developer/debug builds (because it might be useful to know about specific hardware were rdrand is detected but doesn’t work).
I believe some early zen cpus could have rdrand failures when the instruction was overused in another thread or maybe some race condition with suspend or something like that.
ISTM this should behave like g_rdrand_supported == False, except perhaps in developer/debug builds (because it might be useful to know about specific hardware were rdrand is detected but doesn’t work).
I don’t believe that these checks are equivalent. g_rdrand_supported represents whether the processor supports the RDRAND instruction. However, this check is not indicative of that; instead, it reflects that execution of the RDRAND instruction is failing in a continuous fashion. This behavior may occur at any time, rather than exclusively during initialization.
I believe some early zen cpus could have rdrand failures when the instruction was overused in another thread or maybe some race condition with suspend or something like that.
That scenario also appears to be mentioned in the Software Developer’s Manual:
Under heavy load, with multiple cores executing RDRAND in parallel, it is possible, though unlikely, for the demand of random numbers by software processes/threads to exceed the rate at which the random number generator hardware can supply them. This will lead to the RDRAND instruction returning no data transitorily. The RDRAND instruction indicates the occurrence of this rare situation by clearing the CF flag.
SeedHardwareFast, but disallow it during SeedHardwareSlow, possibly just using a pause-loop, like for rdseed. However, I wonder if there are still any CPUs out there that have rdrand, but not rdseed. If not, it would make testing this change hard, and if the rdrand fallback isn’t taken ever in practise, any code change to it will be meaningless.