Linux v4.19-rc1, release candidate code published on Sunday, allows those building their own kernel or Linux distribution to choose whether or not to trust the CPU hardware random number generator, a decision that has become complicated in the wake of the revelations about government surveillance over the past five years.
When random number generation is insufficiently random, encryption based on such numbers can be broken with less effort. Among the security-minded, there’s concern that hardware makers might offer subpar randomization unknowingly, as a result of espionage, or to accommodate demands from government law enforcement or intelligence agencies.
The paranoia wasn’t always so palpable. Back in 2013, Linus Torvalds, Lord of the Linux, dismissed calls to ditch Intel’s RDRAND processor instruction, noting that the Linux kernel uses multiple sources of input to generate random numbers.
The patch, proposed in July by Theodore Ts’o, a Linux kernel contributor and Google software engineer, punts the controversy into the laps of Linux distributors and kernel builders.
“I’m not sure Linux distro’s will thank us for this,” Ts’o wrote in a post to the Linux kernel mailing list last month.
If enabled, the RANDOM_TRUST_CPU flag prevents the kernel’s
getrandom() system call from blocking the boot process in order to accumulate enough entropy. It hastens the boot process, which has some benefits, at the cost of less certainty about cryptographic strength.
Use Debian? Want Intel’s latest CPU patch? Small print sparks big problem
The setting applies not only to RDRAND but also RDSEED, for Intel and AMD x86 chips, as well as random number generators in IBM’s S390 and PowerPC architectures.
Ts’o suggests that the code change will keep kernel developers from being put the spot for trusting certain governments and organizations but not others.
“With this patch, we don’t put ourselves in this position – but we do put the Linux distro’s in this position instead,” he wrote. “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.”
Perhaps unsurprisingly, there’s already a request to implement a way to disable the trust flag. ®
>> Source Link