--OGdp5inFq4AVlqlU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 23, 2006 at 11:09:04AM +0200, Frank Kardel wrote:
> true. get*time is quick an coarse as it uses a cached value
> and avoids accessing  any hardware. It is good for places
> that traditionally accessed the struct  timeval  {mono_}time  structure.
> It can also be used where resolution is not at premium.
> the non-get versions try the best for maximum available precision.
> for rnd -stuff I this you'd like these better.

likely, as long as the 'slow' isn't too slow - that's what i wanted to
read about.  If the comparison to old microtime is good, then non-get
variants it is - we're using new microtime now on any port which would
> be affected anyway.
=20
> not a problem here. so depending how far you are in the
> initialization process you get increasingly better estimates
> starting with an invocation counter that is rapidly replaced with
> platform specific fixed frequency counters.

sounds perfect.

> I would then say we either feed when selecting the new counter and
> use the counter value at registration when it didn't make the selection.
> So we can make use of counter values for all registrations and when
> switching. This primariy supports the boot process.

Another choice would be to take the values from all registered
counters up to now, each time we consider them for selection.  That
would put the code in just one place, and offer the widest chance of
at least some variability in seed input.  We should do this regardless
of whether we have a cyclecounter for rnd's own timestamps, of course.

> Should we consider feeding counter deltas(!) between clock
> interrupts into rnd ?

Worth further consideration, but perhaps unlikely to be especially
valuable:

a) the main concern here is startup seeding; by the time we have
interrupts going there's a reasonable chance of contributions from
other sources, and the initial uses of rnd (the first arc4random
seeding, usually by ipsec) may be past us.  Watch an RNDVERBOSE kernel
boot and you'll see what I mean.

b) even if we were to feed something in, I wouldn't bother storing and
calculating deltas, just put the raw counter values in and let the
pool take care of turning the deltas into some semblance of entropy.
Or do something like xor the current values of all counters and put
that in, if the cost of adding multiple samples every hardclock is a
serious concern (adding in is pretty lightweight, but not ~zero).

This might be something to consider out of desperation on a machine
starved of any other sources, as a disabled-by-default rnd source.
Basically, the things that make a good timecounter make a bad random
source, but if you have both a good and a bad timecounter
(clockinterrupt) perhaps the jitter between them could be as good as
you'll get.  Another place to consider instead might be at the end of
callout processing, in the hope that different callout runs take
different time to process.

Solaris does something interesting and mildly similar with their
equivalent, if I understand correctly.  Rather than hook particular
devices, they instrument syscalls and other kernel entry points, and
roll up all the various hardware interactions that might have occurred
in the processing path into the delta between entry and exit.

--
Dan.

--OGdp5inFq4AVlqlU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFEm8ICEAVxvV4N66cRAtmzAJ0VdEJiNKIVM4kPgdSmXTi91B92OACeKUJR
mC7ECc4XrxHbzzUuxrV7cPE=
=acM5
-----END PGP SIGNATURE-----

--OGdp5inFq4AVlqlU--