Systemd Will Now Use RdRand Directly If The Kernel Can't Deliver Entropy

Systemd will now resort to using Intel's RdRand hardware random number generator directly if the Linux kernel is unable to provide the init system with sufficient entropy.

This systemd change stems from the issue of the Linux boot process getting stuck if there's not enough entropy due to a kernel change to eliminate CVE-2018-1108 over early boot processes potentially having weak random seed data. With systemd's random-util change, systemd will now use RdRand directly if the kernel can't provide any randomness, rather than having to block/stall.

In the systemd context it's relying upon the random number generator for seeding hash tables and thus doesn't need to be particularly random. But with many not trusting hardware random number generators, this support can be disabled by changing the systemd high_quality_required option to false. Under that condition, the kernel is the only source of entropy.

RdRand has been supported by Intel CPUs going back to the Ivy Bridge days while since Broadwell has also been RDSEED. On the AMD side, initial RdRand was found with Excavator cores while Zen also brings the RDSEED instruction.

This systemd RdRand tapping will be part of the upcoming systemd 240 release.