sys_fuzz

Gary E. Miller gem at rellim.com
Wed Jan 25 03:36:15 UTC 2017


Yo Eric!

On Tue, 24 Jan 2017 21:54:13 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

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

Worth a shot.  Handle the birthday effect by using Lambert Rule #3.
Just increment.

My gut feeling is you are right, but I'd like to get some good
edge cases.  NTP runs on so many hosts with so many different sys
clock implementations that guessing all the failure modes would be
problematic.

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

Yeah, way down the priority list.  Something to noodle on for a long
while.  Knowledge to keep under your hat for when a bug pops up in
this area.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170124/8a2f7fc3/attachment.bin>


More information about the devel mailing list