[tor-bugs] #18365 [Core Tor/Tor]: Fined-grain timer implementation to support per-connection or per-circuit timers

[Tor Bug Tracker & Wiki]

#18365: Fined-grain timer implementation to support per-connection or per-circuit
timers
-------------------------------------------------+-------------------------
 Reporter:  nickm                                |          Owner:  nickm
     Type:  enhancement                          |         Status:
 Priority:  Medium                               |  needs_review
Component:  Core Tor/Tor                         |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.9.x-final
 Keywords:  performance, backend,                |        Version:
  TorCoreTeam201604                              |     Resolution:
Parent ID:                                       |  Actual Points:  medium
 Reviewer:                                       |         Points:  medium
                                                 |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by mikeperry):

 * cc: yawning (added)


Comment:

 I've done a quick high-level review of the src/common/timers.c, and I'm
 concerned about the relative timers and cached monotonic time. If the
 timers themselves use monotonic time as we implement it, then we're
 vulnerable to NTP spoofing where the adversary causes a negative clock
 jump to delay all timers. Using cached monotonic time for timers means
 that all timers scheduled after that clock jump will have to wait for the
 duration of the clock jump before the cached monotonic clock moves forward
 again to cover the clock jump delta and then trigger the callbacks. This
 means that padding will be effectively disabled for the full time delta of
 such negative clock jumps.

 For the netflow padding, I used uncached gettimeofday and added some
 sanity checks for clock jumps based on expected min and max timeout values
 and channel padding inspection frequency. Not perfect, but at least we can
 check and warn when it happens, and schedule the padding immediately.

 I talked a bit with Yawning, and we think that using performance counters
 (CLOCK_MONOTONIC_RAW on Linux and QueryPerformanceCounter on Windows)
 would work here, but then we'd have to alter all of the current channel
 timestamps, netflow timeout values, and this timer code to use those for
 scheduling and callback. This may actually be a good idea anyway, since we
 only need "consensus reality" time for the Tor consensus and descriptor
 freshness checks. Actual networking and timer stuff can and should be
 realtime and agnostic about the epoch.

 Otherwise, I think it might actually be better for padding to use uncached
 tor_gettimeofday() directly, and check for jumps. Obviously this is error-
 prone and problematic, though, but I think  better than cached monotonic
 time for the traffic analysis and padding use case.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18365#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online