Linux Kernel Diverts Question To Distros: Trust CPU Hardware Random Number Generators?

Written by Michael Larabel in Linux Kernel on 16 August 2018 at 05:45 AM EDT. 26 Comments
In a controversial move, the Linux kernel will be pushing the question off to distribution vendors on whether to put trust in CPU hardware random number generators.

Google's Ted Ts'o sent out the random subsystem updates this week for the Linux 4.19 kernel merge window. In addition to the recent change of better protecting entropy sent in from user-space, the decision on whether to trust the CPU hardware random number generators like Intel's RdRand will now be left up to the Linux distribution vendors or end-users having the final say in overriding that decision.

The decision on whether to trust the "CPU HWRNG" is important to determine whether the kernel's get random function will block at all, which otherwise can stall the boot process if there is not sufficient entropy and part of the motivation on the recent work for better protecting user-space entropy. That work in turn is stemming from the CVE-2018-1108 security notice earlier this year whereby a kernel's random seed data may not be random enough for early processes in the boot sequence. The boot process can be stalled until there is sufficient data -- or in the case of distributions like Fedora, diverting to a user-space jitter entropy daemon. But with this new option being added to the Linux 4.19 kernel, if you want to instill trust in your CPU vendor, you can let the kernel know you trust your CPU hardware RNG.

Whether to trust the CPU hardware random number generator can be changed when building the kernel via the new RANDOM_TRUST_CPU Kconfig switch. Ted Ts'o commented when writing the patch:
I'm not sure Linux distro's will thank us for this. The problem is trusting the CPU manfuacturer can be an emotional / political issue.

For example, assume that China has decided that as a result of the "death sentence" that the US government threatened to impose on ZTE after they were caught introducing privacy violating malware on US comsumers, that they needed to be self-sufficient in their technology sector, and so they decided the needed to produce their own CPU.

Even if I were convinced that Intel hadn't backdoored RDRAND (or an NSA agent backdoored RDRAND for them) such that the NSA had a NOBUS (nobody but us) capability to crack RDRAND generated numbers, if we made a change to unconditionally trust RDRAND, then I didn't want the upstream kernel developers to have to answer the question, "why are you willing to trust Intel, but you aren't willing to trust a company owned and controlled by a PLA general?" (Or a company owned and controlled by one of Putin's Oligarchs, if that makes you feel better.)

With this patch, we don't put ourselves in this position --- but we do put the Linux distro's in this position intead. The upside is it gives the choice to each person building their own Linux kernel to decide whether trusting RDRAND is worth it to avoid hangs due to userspace trying to get cryptographic-grade entropy early in the boot process. (Note: I trust RDRAND more than I do Jitter Entropy.)
While Intel RdRand is often what gets brought up the most in these discussions, RANDOM_TRUST_CPU also applies to AMD, IBM s390/POWER, and other CPU hardware RNGs too.

The new RANDOM_TRUST_CPU option is part of the random changes queued for the Linux 4.19 kernel.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week