How a months-old AMD microcode bug destroyed my weekend [UPDATED]

[grarpamp]

>>> https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amd-ucode
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/commits/master

>> 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-37b-was-up-to-during-its-record-720-days-in-space