[Sks-devel] [patch] Clocks and VMs

[Phil Pennock]

I do not run with SKS in a VM and have never experienced the clock
problem, so can't test if the attached patch resolves any problems.  I
can confirm that I can receive a key from a peer with this code applied.
So it's not immediately bad.

Can someone who can reproduce the timing problems try this out please?

Basic idea: where the Unix.gettimeofday() results may be used as unique
calls, call a new shim which keeps a cache of recent results, and if the
new result is not after the last result, take the last result and add
one millisecond to it and pretend that's the time.

Since this problem has not really bitten Unix non-VM, one millisecond
resolution must be fine in practice, and should be a reasonable
increment.

I saw use of epsilon_float in Ehandlers.float_incr but that worries me;
unless I'm misunderstanding things, epsilon_float is only guaranteed to
give a different value when added to x if x is 1.0; if the exponent is
greater than 0, then surely x + epsilon_float = x ?

Also, there's a more general problem which needs fixing, which is use of
the wall clock as a timer for scheduling events at some fixed amount of
time into the future.  The wall clock *can* go back, although it
shouldn't in routine operation.  I suspect that setting the wall clock
back while SKS is running would result in some unfortunate blow-ups.

Looking around, perhaps something like this should be used:
  http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=738
  https://github.com/polazarus/oclock
?

-Phil

sks-clocks.patch
Description: Text Data

pgpzRhHqyXgPJ.pgp
Description: PGP signature