[Pkg-sysvinit-devel] Re: /etc/init.d/urandom Suggestion

[Kent Borg]

On Sun, Feb 26, 2006 at 05:10:11PM -0500, Kent Borg wrote:
> Let me look at costs.

In my previous posting I overstated one cost and didn't address
another cost.  Let me try to correct that.

Cache.  Though a lot of data might move, and all from different RAM
locations, this is a compute-bound process.  SHA-1 requires the CPU do
significant work and so the time scale of visiting RAM locations is
stretched out.  Being compute-bound my proposal benefits well from
being niced; higher priority processes can preempt this entropy
collection and have plenty of time to pull their data into caches.
This process can complete when it completes.  I think this is a
non-issue.

Battery.  Cost: A power starved system trying to conserve battery
can't blithely say "But is is niced." and walk away.  Response: A
truly power starved system avoids booting the kernel except when
necessary, so this cost is also avoided.  Also, a really fine tuned,
power frugal system isn't blindly installing Debian and has the
opportunity to revisit this issue.  Finally, designers of a power
starved system might conclude they need this entropy and so benefit
from this proposal.


A couple other points.

If, as this traversal is ticking away in the background, mechanical
disks manage to provide significant data with which to start filling
RAM and some of that data gets hashed, is that a problem?  I think
not.  Because how data gets laid out on disk and exact disk behavior
can be unpredictable, this might indirectly provide more entropy.

Another point is that my computations of "error rates" glossed over
that some RAM visited will be used for completely predictable things,
like the kernel image.  OK.  But not all RAM will used at the point
the /etc/init.d/urandom runs, nor will it all be used when this
process completes.  Any bits that are still in their power-on state
when hashed have the potential to contribute entropy.



Thanks,

-kb