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

2012-11-26 Thread Shea Levy 

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

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

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

2012-11-23 Thread Lennart Poettering 
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

2012-11-23 Thread Cristian Rodríguez 

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

2012-11-22 Thread Mantas Mikulėnas 
On Thu, Nov 22, 2012 at 6:19 PM, 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?

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