On Thu, 22.11.12 11:19, Shea Levy (s...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
