A months-old AMD microcode bug destroyed my weekend

Although in the author's case, he seems to be waiting on a BIOS fix because the microcode fix doesn't actually work. In the updates he mentions being told "...that the amd64-microcode package... would fix the issue. This, too, is not the case; the amd64-microcode and intel-microcode packages are both installed by default on all Ubuntu 19.10 systems, including the one I'm experiencing the RDRAND failure on."

It's good news that microcode fixes generally don't demand BIOS updates, but in practice this one seems to be getting fixed that way before it's fixed by the manufacturer.

I understand you can't just get any memory. The memory I purchased was reasonably within the required specs and a solid brand. The memory wasn't on the "tested list" but on a relatively new chip that's a small list and in the Philippines, I had a limited choice. This is also a wide problem as I found loads of people who had the same issues. I was able to fix it though, and I have my original RAM installed. If there's a secret sauce to picking RAM other than being on this tested list, it's not widely known. Just finding a thread where someone could explain the problem and the fix was difficult.

I guess this is no different from any newly released thing. Better to wait until the quirks get worked out.

Motherboard is TUF B450M-PLUS gaming.

Chip is Ryzen 3600.

I'm not saying you're wrong; I'm just saying, hey, there's "prior art" for this... <g>

I know I'm nitpicking but I disagree with that statement.

There's a kernel option called CONFIG_RANDOM_TRUST_CPU which you can set to false. So if for some reason, even if it's a bad one, you don't want your random numbers generated by your cpu then that's that. End of discussion. (In theory, not sure if rdrand if trapable)

I get that you're skeptical about the quality of what's provided in /dev/(u)random because in most cases it's true. Should I ever feel the need to hookup a hw random generator then I hope programs would use that one instead of guessing they can do better by calling rdrand.

There is assembly in WireGuard for the crypto primitive implementations, but those are generated by scripts and are based on either formally-proven implementations or highly-vetted ones.

[1]: https://elixir.bootlin.com/linux/v5.3.6/source/drivers/char/...

So says a maintainer of WireGuard. HN is beautiful sometimes.

If RANDOM_TRUST_CPU is disabled, that will stop the kernel function from using RDRAND and avoid this issue for anyone using the ‘get_random_u32()’ function?

My conclusion would be exactly the opposite: If your RNG is so important that it has to be cryptographically secure, you owe it to your users to put in the time and effort of maintaining a proper implementation yourself, or at the very least use an open source library that provides this functionality in software. Otherwise you're always going to be at the mercy of a potentially misbehaving environment.

In terms of entropy, you don't really need to "maintain a pool" for CSPRNGs. You either have enough entropy to feed it with, or you don't. Once it is properly seeded, you can squeeze as many random bits out of it as you want (or at least, as many as anyone would ever reasonably need). It's really no different from a stream cipher, the key is the seed, and you're just encrypting zeroes. You don't need to suddenly get another randomly generated key after encrypting 100 MiB to encrypt the next 100 MiB securely.

Another great thing about entropy is that you can't reduce it. Which is why you really don't have to spend any time thinking about whether a particular entropy source is well behaved or uniformly distributed or anything like that at all. You just have to be certain that you have overall enough entropy that nobody can guess the entire seed. So anything the OS can give you? Dump it in there. Any kind of user interaction? Dump it in there. The time? CPU jitter? Network jitter? Just put it all in there. 100 MiBs of 0s? You know what why not, just put it on top because you literally can't make it worse, only better.

For example, seeding ChaCha with 256bits will give you 1 ZiB of output before cycling. That should keep you going for awhile.

A lot of PRNG are now implemented as the output of stream ciphers or block cipher in counter mode:

* https://en.wikipedia.org/wiki/Fortuna_(PRNG)

So 128 bits is all that is needed to get going.

Re-key every so often to ensure forward security in case there is a kernel-level compromise.

With AES-NI instructions in most CPUs, several GB/s can be achieved.

If you have a secure stream cipher, you have a secure RNG. Not "can build", they're the same thing. If you only have block ciphers, the security proof is less trivial, but in practice "decrypt /dev/zero" still works.

If you don't have a secure (symmetric) cipher, you have bigger crypographic problems than bad random numbers.

And again, like before, the reaction to this is just hilarious to me. "It's a kernel bug." - Yeah, sure, but your users don't care, and your users shouldn't have to care. Because this an easy problem to fix, and if you're worth your salt as a developer you should fix it. Evidently Wireguard isn't worth it's salt.

This is completely true, but there is a property that your random numbers have to have that your seed doesn't need in any way: Being uniformly distributed.

If you need a random 64 bit number, you want every single bit in that number to have a 50% chance of being 0 or 1. This requirement doesn't exist at all for seed data, the entropy of all your seed data together just needs to be large enough for it to be computationally infeasible to calculate it from the outside.

I would say that is a pretty big difference. Also, if you just need uniformly distributed random IDs but those IDs aren't secret and don't need to be unpredictable, you don't even need a seed. Or at least, you can just use a constant as a seed. No interaction with the outside world needed at all.

We already know that parties like the NSA have intentionally backdoored RNGs that made it into production use.

[1]: https://elixir.bootlin.com/linux/v5.3.6/source/drivers/char/...

In comparison get_random_u32() is safe to call at any point — including early boot — and does not affect global entropy pool. At worst it may return low-quality numbers, but that can be easily fixed by running your own peudo-random generator on top of it (which is a good idea anyway because you don't want your kernel module to contend with other parties for RNG ownership).

https://en.wikipedia.org/wiki/Shot_noise

Johnson Nyquist noise is measured from resistors, and is therefore present in every circuit. Shot noise however, is more evident in transistors.

------------

I don't know if the AMD circuit is Shot-noise or Johnson Nyquist noise. But its important to remember that there are many sources of noise / randomness in normal circuits.

The funny thing about true-random number generators: noise sources are all over the place! A beginner who plays with transistors will almost immediately "discover" a form of noise, and be forced to minimize it.

With regard to "true random" circuits (of which there are many, many different kinds), they all isolate a particular noise, and then amplify it. You have to isolate a particular form of noise if you want to get a good entropy estimation.

EDIT: It seems both shot noise and Johnson-Nyquist noise are white-noise, so maybe it doesn't matter. White noise + white noise should result in white noise, but its been a long time since I've taken this circuit class...