Some AMD CPUs Might Lose RdRand Randomness Following Suspend/Resume

[starshipeleven]

Servers also has network randomness.

They also have disk access randomness.

Servers aren't in production when I'm setting ssh keys up, and may or may not have enough network randomness depending on how much they are used.

It's not the first time I had to kick in a raid scrub or cat /dev/md0 > /dev/null for the sake of increasing the damn rng pool and not waiting ages for the key to be generated on a device lacking hardware RNG (or where the software was not using it)

While each source could be compromised (hardware, network, clock), combining them and adding a bit of pseudo random, will produce perfectly random numbers that can only predicted (very expensively), by someone who has compromised all of the sources randomness.

The issue is that when 99% of your entropy comes from the hardware random because it is SO MUCH FASTER than any other source, when you lose access to it you get a huuge hit.

[trek]

Actually it does cause big problems. Lots of systemd services fail to run, thus making the system unusable. I personally experienced this on a fresh Arch Linux install, could not start any systemd services due to this, which meant even Gnome Terminal failed to launch (it depends on a systemd service for some weird reason).

this is what it happens with poorly designed software that is based on assumptions: systemd is the only affected software by this hardware flaw, but the disruption it provokes is far more than the intended behavior

systemd is fragile, you must take care of it!

[GreenReaper]

Yet another good reason to compile without power management in the kernel! (CPU idle notwithstanding).