Comment by JdeBP
7 years ago
... which is what the systemd code actually does. The problem is that there appears to be a possible AMD processor state, caused by suspend+resume, where the instruction succeeds but the data returned are not in fact random.
There is no mention anywhere, in this thread nor the one from 2014, of it returning non-random data from the issue reporters, just assumptions from onlookers.
Wrong.
* https://news.ycombinator.com/item?id=19851693
The other problem is that systemd's fallback is a non-random PRNG.
Only if a RANDOM_EXTEND_WITH_PSEUDO flag is set. But in fact, that flag is nowhere set in systemd outwith unit testing code. So it is not in fact another problem.
Even if it were used, the calls to rand() would only happen if RDRAND first succeeded and then failed. If RDRAND always failed, systemd's true fallback is actually to getrandom() and thence to /dev/urandom. However, AMD claims in its doco that there is a FIFO of generated data provided for satisfying bursts of multiple RDRAND instructions, so it is supposedly unlikely to succeed and then fail, especially for the amounts of random data in the case at hand.
AMD does not say, though, whether the FIFO is big enough to complete a 128-bit GUID, and this does after all involve a processor that can enter a mode where RDRAND succeeds and gives a constant result. It's not wholly beyond the bounds of possibility that AMD made the FIFO too small as well.