We don't even know if this affects say Windows, also Linux doesn't use just the hardware RNG for entropy.
The bug mentioned here is about a specific scenario. But that's only how the issue emerged. The more general conclusion is that RNG is faulty and quality of numbers it outputs can be compromised. It could have happened and it may happen in the future. That's the real problem.
Everyone who uses (or used...) this RdRand now have a moment of doubt - and potentially a problem.
AMD has to check how deep this goes and either fix or disable it in an update.
Companies that use these CPUs in offline systems (once again: embedded!) will have to analyze the risks as well.
That's how things go. This is a standard procedure for most enterprises. Hardware and software faults are found all the time.
When it's important to have reliable noncompromisable entropy on the cheap they usually generate it via software. Rdrand is considered potentially weak in such cases.
I'm not sure if I understand your post, but it doesn't seem correct the way I read it.
Pseudo-random numbers generated computationally are always deterministic - hence, of limited "quality".
Of course they are perfectly fine for many applications.
However, for specific scenarios (e.g. complex financial modelling, scientific simulations) it is often recommended (sometimes:
required) to use a higher quality source.
You can either go for a very complex algorithm or a hardware generator. Either way, the better randomness means slower operation.
The popular fix to this, commonly used since Intel introduced RDRAND, is to keep using a good PRNG and periodically reset seed with RDRAND (RDSEED in fact).
Now, if it turns out that AMD's RDRAND is not reliable, this (really common) approach has to be scrapped as it may even be worse than using a PRNG all the way...
