sys_fuzz

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> > You have no choice but to fuzz the clock,
> 
> I think you went a tad too far.  Your other choice, like
> CLOCK_MONOTONIC, is to just add a tiny value (a nano Sec) if it would
> be a repeat.

Thanks for the correction.

> > All x86 machines back to the Pentium (1993) have a hardware cycle
> > counter; it's called the TSC. As an interesting detail, this was a
> > 64-bit register even when the primary word size was 32 bits.
> 
> Well, it gets worse, in an Intel SMP chip there may be one TSC per
> CPU and they are not always in sync.
> 
> As the clock_getres() man page says:
> 
>     "These registers may differ between CPUs and as a consequence these
>     clocks may return bogus results if a process is migrated to another
>     CPU."
> 
> Thus the need to not trust the clock and the need for normalize_time()

Sure.  But if my new understanding is correct, all *this* problem
requires is stepback protection, not fuzzing.  Please check me on
that.  Worst case, lots of migration could make the TSC look a bit
like a random variable with a very low frequency of collisions
(proportional to (2^64)^-2 by birthday effect); filtered through the
stepback check this would look a lot like fuzzing.

> I'm not expecting it to be renmoved, but I feel better that it will not
> mutate badly.  Might even get better comments now. The timestamp nonce
> has value for all hosts and maybe other lurking benefits.  As long as
> any fuzz added is less than sys_fuzz then no host I see will be
> negatively impacted by it.

It's a judgment call I'm not going to make yet.  I'd like to collect the
code simplification, and I think this analysis shows it's a safe thing,
but I want to hear what Hal has to say and meditate on all this some more.

It occurs to me that one reason to jump is that in the SMP case we
have no guarantee that the fuzz calculation itself is reliable. I
mean, what happens if a process migration intervenes between the
"adjacent" measurement calls?

And thank you.  You've helped light up one of the last few areas of the
code I didn't grok.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170124/3ff7ac27/attachment.bin>