svn commit: r239569 - head/etc/rc.d

[RW]

On Fri, 14 Sep 2012 17:25:59 +0100
Ben Laurie wrote:

> On Fri, Sep 14, 2012 at 3:46 PM, RW <rwmaillists at googlemail.com>
> wrote:
> > On Fri, 14 Sep 2012 14:43:53 +0100
> > Ben Laurie wrote:
> >
> >> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb <bz at freebsd.org>
> >> wrote:
> >> > 7) send all data to the kernel and hash (arch dependent?) it +
> >> > counter value into the buffer on overflow, as in b[n] = H(b[n] +
> >> > c
> >> > + i[n]) in the kernel
> >> >    (can control when buffer full and only then take action when
> >> >    needed, indepedent on how seed data is chosen, uses standard
> >> >    technology)
> >>
> >> IMO, this is the only good option.
> >
> > No it isn't. I means that the hashing is unconditional, so anyone
> > that needs a faster boot needs to patch the kernel.
> 
> Has anyone measured the cost of doing this? Also, if you really want
> to turn it off, we could provide a flag.

Yes, read the thread.

> >  It has no advantage
> > whatsoever over a minor change to initrandom.
> 
> It absolutely has. It applies to all inputs to /dev/random, not just
> those that come from initrandom. 

If the rc script are written correctly it shouldn't matter, there no
need to write to /dev/random after the boot - it wont do anything
useful.

It has no advantage over hashing the low-grade entropy in userland
which is is just couple of lines difference in a shell script. 

> Also, should something get to write
> to it before initrandom, initrandom's input would still be used.

There's no reason to do that, so why do you think it matter?