Some AMD CPUs Might Lose RdRand Randomness Following Suspend/Resume
Systemd lead developer Lennart Poettering of Red Hat tweeted today, "So AMD CPUs implement an RDRAND operation that doesn't actually return randomness (after your first suspend/resume cycle that is)."
So AMD CPUs implement an RDRAND operation that doesn't actually return randomness (after your first suspend/resume cycle that is). https://t.co/FNsqJb4TEu
— Lennart Poettering (@pid_eins) May 7, 2019
Referenced is this bug report outlining that the RdRand instruction on an older AMD A6-6310 processor isn't properly behaving following a suspend/resume. By avoiding RdRand usage on the system as part of generating a UUID, the reported systemd issue no longer happens.
Also referenced is this Linux kernel bug report that is still open after five years. That bug report cites RdRand failing after resume on AMD CPUs. In this case, OpenSSL was failing to generate keys after a kernel suspend/resume. The belief back then was that it may be due to a BIOS bug but the issue not fully investigated since OpenSSL ended up disabling RdRand usage in the process and thus working around the problem experienced by the end-user.
Fortunately, by default the Linux kernel doesn't exclusively rely upon RdRand as a source of entropy but ends up being mixed in with other data / entropy sources. Regardless, now that Red Hat developers are involved and other upstream developers, hopefully they'll be able to figure out this issue in short order to come up with an effective solution.
I haven't encountered this issue myself and so far the only reports I've seen are from those using older Excavator era processors and not any newer AMD "Zen" Ryzen/EPYC processors.
22 Comments
