[gargravarr]

Linux provides /dev/random and /dev/urandom to all applications as well as relevant API calls, but the quality of those is always in doubt (especially with urandom, which recycles the entropy pool when it gets too low). CPU hardware PRNGs are supposed to be much higher quality, when they work. So it's all about depending on the CPU to actually do what it's advertising - the CPUID flag advertises a high-quality hardware RNG, but then the firmware bug completely nurfs it.

[nocturnial]

> So it's all about depending on the CPU to actually do what it's advertising

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.

[gargravarr]

I wasn't aware of this kernel flag (nor am I surprised it exists), seems like it would be useful to the article's author. However, by default it's left enabled, which allows the kernel to automatically set up the environment based on what it can glean from the hardware. So my comment was in regards to the machine without intervention.