#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
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
