https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-d...
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/... https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/commits/...
any microprocessor which purports to be able to internally-generate "random numbers" should also be equipped with an input (possibly a single line) which is intended to be connected to an external source of random numbers, intended to be mixed with the internal random source
None of todays CPUs (and NIC, USB, DISK, PHONE, etc) are even remotely trustworthy or trustable. So there is zero reason to believe they would get even that feature right either, nor do you have any way to exhaustively test it. Only way you will ever have one bit of open trust as to what is going on in your gear is with #OpenFabs #OpenHW #OpenAudits. Ignoring that fundamental truth for the moment... the better way would be to feed your homemade radioactive HWRNG into the OS PRNG via the serial UART, which is also closed HW.
Asrock's team offered a custom BIOS available with the appropriate microcode fix; I respectfully declined to flash a one-off BIOS for me and me only, but the better news is that Asrock told AMD that the BIOS update should be publicly available in mid-November.
The fact that all these cpu, mobo, bios, etc makers resort to this dodgy behaviour tells you that they're hiding something you should know everything about. It's time to do #Open*. Here's more dodgy behaviour and program and HW you should know everything about... https://www.thedrive.com/the-war-zone/30699/here-what-we-know-the-shadowy-x-...