ASRock slow to apply fix for AMD Ryzen 3000 Random Number Generator, others fixed BIOS in July

[A1xLLcqAgt0qc2RyMz0y]

Article on what the Bug is and that it still has not been fixed.

How a months-old AMD microcode bug destroyed my weekend

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

The microcode bug in question is a faulty response to the RDRAND instruction. Modern x86_64 CPUs—beginning with Intel's Broadwell and AMD's Zen architectures—are supposed to have high-quality onboard random number generators (RNGs), which use thermal "noise" to very rapidly offer high-entropy pseudorandom numbers to anybody with kernel-level access who wants it. RDRAND is, in turn, the instruction which provides these random numbers.

All of this is supposed to be fairly failsafe. There's a CPUID function call that checks for the availability of RDRAND, and there's also a "carry bit" in the return value from a call to RDRAND that's supposed to let the calling application know if the CPU's RNG was unable to generate a sufficiently random number due to lack of entropy. Unfortunately, unpatched Ryzen 3000 says "yes" to the CPUID 01H call, sets the carry bit indicating it's successfully created the most artisanal, organic high-quality random number possible... and gives you a 0xFFFFFFFF for the "random" number, every single time.

 

[Rikimaru]

I read that's a BIOS error, not CPU, after suspend mode.

 

[A1xLLcqAgt0qc2RyMz0y]

I read that's a BIOS error, not CPU, after suspend mode.

No the problem is with the CPU:

As AMD's representatives told reporters back in July, the real fix comes from applying BIOS updates to your motherboard and hoping that the BIOS update also includes the microcode patch for the CPU itself. When I checked my own BIOS using the dmidecode utility, I saw a date of August 12, 2019. But when I looked at Asus' download page for my motherboard, I saw downloads dated in September! Hurray! So I downloaded the BIOS update, saved it to a FAT32 thumb drive, rebooted my system, and went into setup.

Unfortunately, after successfully applying the update and rebooting again, I realized my error—yes, Asus showed a later date for the BIOS, but the actual version was the same as the one I already had—3.2.0. My CPU still thought 0xFFFFFFFF was the randomest number ever, always, no matter what.

At this point, I began to get paranoid—systemd had already quietly worked around the bug. But with most applications just quietly ignoring the problem, how would I know if it ever had been patched? What if two years later, I was still vulnerable to stack-smashing that I shouldn't have been, due to ASLR that wasn't actually randomizing?

AMD's Ryzen 3000-powered systems still produce 0xFFFFFFFF as the randomest number ever, always, no matter what.

 

[Malo]

According to the update on the article, AMD had indeed provided the microcode update with the fix to motherboard manufacturers in July but ASRock had not implemented the code in a BIOS for his X470 motherboard yet.