[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