[systemd-devel] Properly handling rngd's complex dependencies

Shea Levy shea at shealevy.com
Thu Nov 22 08:19:02 PST 2012


Hi all,

rngd currently supports three sources of randomness to increase the 
kernel's entropy pool: The hwrng device, the trusted platform module 
device, and the RdRand x86 instruction. We don't want to start the 
daemon when none of the sources are available (as it will fail), but we 
want to start it as early as possible after some source is available so 
that programs requiring randomness have a good entropy pool available to 
them. Is there any way to express the following start-up behavior: "If 
the cpu supports RdRand*, then start rngd as soon as possible, otherwise 
start rngd as soon as either a hwrng device or a tpm device comes online"?

One solution I thought of was to change rngd to listen for uevents and 
add to its list of used randomness sources on-the-fly. Then we could 
just start rngd as soon as possible, it will use RdRand if available and 
otherwise idle until a usable randomness source comes online. The 
downside to this is that it will complicate rngd (which from my brief 
perusal of the code is currently single-threaded) and that it might make 
users think they have a decent entropy source available but rngd is just 
sitting there.

Thoughts?

Thanks,
Shea

P.S. please CC me as I am not subscribed to the list

* Technically I suppose the complete solution would also listen for CPU 
hotplug events and run rngd on an RdRand-supporting cpu if one gets added...


More information about the systemd-devel mailing list