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

[Lennart Poettering]

On Thu, 22.11.12 11:19, Shea Levy (shea at shealevy.com) wrote:

> 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?

Mantas' suggestion is the way to go.

That said, what's the reason for having a userspace component for this
at all? Why isn't all of this done inside the kernel? I mean, the kernel
/dev/random stuff already has hooks into various subsystems to get
entropy, it sounds trivial to also hook up RDRAND with it?

Maintaing complex userspace infrastructure where a 20 line kernel patch
or so would suffice too, doesn't sound ideal to me?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.