[systemd-devel] Properly handling rngd's complex dependencies
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... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Properly handling rngd's complex dependencies
On Thu, Nov 22, 2012 at 6:19 PM, Shea Levy 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"?
If I remember correctly, this can be done with udev rules... For CPUs,
check if ENV{MODALIAS} contains the right feature and add
TAG+="systemd" and ENV{SYSTEMD_WANTS}+="rngd.service", which will make
systemd start that service. Same for other device types.
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Properly handling rngd's complex dependencies
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
Re: [systemd-devel] Properly handling rngd's complex dependencies
El 23/11/12 11:38, Lennart Poettering escribió: 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? Unfortunately kernel developers seem to insist in pushing into userspace stuff that belongs to the kernel (notable exception on this is RDRAND that is actually used by the kernel to feed the entropy pool...) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Properly handling rngd's complex dependencies
Hi Mantas,
Thanks for the advice. One question:
On 11/22/2012 12:49 PM, Mantas Mikulėnas wrote:
On Thu, Nov 22, 2012 at 6:19 PM, Shea Levy 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"?
If I remember correctly, this can be done with udev rules... For CPUs,
check if ENV{MODALIAS} contains the right feature
I'm not exactly sure how to do this, do you have any pointers on how I
can parse ENV{MODALIAS} to get cpu features?
and add
TAG+="systemd" and ENV{SYSTEMD_WANTS}+="rngd.service", which will make
systemd start that service. Same for other device types.
--
Mantas Mikulėnas
Thanks,
Shea
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
