On Tuesday, October 29, 2019, 11:42:42 AM PDT, coderman <coderman@protonmail.com> wrote:

>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
https://ieeexplore.ieee.org/document/847868



This should minimize the possibility that defects in one source can affect the randomness of the ultimately-used data stream,

            Jim Bell