* https://github.com/systemd/systemd/issues/11810#issuecomment...
H. Peter Anvin's educated guess was that some MSR flag, that has the effect of controlling this instruction, is not being saved and restored in the processor across a suspend, and the result is a processor state where it signals that the instruction is succeeding but it is not actually returning random values.
Let’s wait for clarifications how that person has done the tests.
However: the bug is about systemd failing to get entropy, not getting nonsense entropy.
* https://github.com/systemd/systemd/issues/11810#issuecomment...
There is no "however". This bug is about code that is, according to the AMD doco, using the instruction correctly; but that is, because the AMD processor has this possible state after a suspend+resume, getting all-ones as its random data, thereby causing ID collisions in a fairly wide range of possible things from freshly re-generated machine IDs to journal file header block IDs, and including unit invocation IDs.
* https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...
* https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...
* https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...
This indicates that a "should be fine" in another comment is not in fact true. (-:
* https://github.com/systemd/systemd/blob/717e8eda77b93ac396dc...
Why would OpenSSL fail visibly if the API was returning success but with non-random data?
That would be quite something to read the comment on;
// Here we check to be sure the Earth is not flat
...
// Seeing that the Earth is indeed flat, we will iterate in this absurdity some more in the hopes it rounds out eventually