>What’s an RDRAND?
>The microcode bug in question is a faulty response to the
RDRAND
instruction. Modern x86_64 CPUs—beginning with Intel's Broadwell and
AMD's Zen architectures—are supposed to have high-quality onboard random
number generators (RNGs), which use thermal "noise" to very rapidly
offer high-entropy pseudorandom numbers to anybody with kernel-level
access who wants it.
RDRAND is, in turn, the instruction that provides these random numbers.
>All of this is supposed to be fairly failsafe. There's a CPUID
function call that checks for the availability of RDRAND
, and there's also a "carry bit" in the return value from a call to RDRAND
that's supposed to let the calling application know if the CPU's RNG
was unable to generate a sufficiently random number. Unfortunately,
unpatched Ryzen 3000 says "yes" to the CPUID 01H
call, sets
the carry bit indicating it has successfully created the most
artisanal, organic high-quality random number possible... and gives you a 0xFFFFFFFF
for the "random" number, every single time.
I think that any microprocessor which purports to be able to internally-generate "random numbers" should also be equipped with an input (possibly a single line) which is intended to be connected to an external source of random numbers, intended to be mixed with the internal random source, for example:
or
or
This should minimize the possibility that defects in one source can affect the randomness of the ultimately-used data stream,
Jim Bell