[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor
#29500: Broken circuitpadding unittests on appveyor
-------------------------------------------------+-------------------------
Reporter: asn | Owner: (none)
Type: defect | Status:
| needs_revision
Priority: High | Milestone: Tor:
| 0.4.0.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: wtf-pad, tor-relay, tor-cell, | Actual Points:
padding, 041-proposed, 040-must |
Parent ID: #28631 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by teor):
Hi Mike,
I noticed your question during the network team meeting:
{{{
mikeperry: the #29500 one is annoying. I think we need another flag or
something. I also only barely understand how this could ever happen in a
real scenario
mikeperry: it seems almost impossible
nickm: mikeperry: maybe add the appropriate assertions that should never
be hit, so that we can figure out why it would be happening sometime
anyway?
nickm: diagnosis is the next best thing to a fix
}}}
Here are two scenarios where the monotime_diff or monotime_absolute
functions can return zero:
(I'll use monotime_absolute below, because I think that's what you're
using. But monotime_absolute just calls monotime_diff with the previous
monotime value.)
The Ratchet Returns Zero
1. Tor is running on a platform which has monotime API bugs (Windows), or
Tor is compiled without support for monotime functions (old Linux, old
macOS, other platforms where we haven't implemented monotime support)
2. Tor calls a monotime_absolute() function, and stores the last monotime
value
3. Any amount of time elapses
4. Tor calls a monotime_absolute() function, and Windows experiences its
monotime bug, or the user has changed the wall clock time backwards
5. Tor emulates monotonic time using a ratchet. The ratchet stores an
internal correction factor for future monotonic times, and returns the
same value as it previously returned
6. The monotime_absolute() function gets the same value for the previous
and current times. It returns zero.
Low Resolution Timers in the OS
1. Tor is running on a platform with low-resolution timers
2. Tor calls a monotime_absolute() function, and stores the last monotime
value
3. A small amount of time elapses, which is lower than the timer
resolution
4. Tor calls a monotime_absolute() function, which gets the same monotime
value as the previous call to the low-resolution timer
6. The monotime_absolute() function gets the same value for the previous
and current times. It returns zero.
Low Resolution Timer APIs in Tor
1. Tor is running on any platform
2. Tor calls a monotime_absolute() function with low-resolution units
(seconds, milliseconds, or microseconds) and stores the last monotime
value
3. A small amount of time elapses, which is less than one unit
4. Tor calls a monotime_absolute() function, which gets a monotime value
which is greater than the previous call to the low-resolution timer, but
less than one unit away from the previous timer.
6. The monotime_absolute() function gets less than one unit's difference
between the previous and current times. It divides by the unit conversion
factor, and returns zero. (These functions truncate, rather than
rounding.)
I hope that explains the scenarios that Tor code needs to deal with when
calling Tor's monotime APIs.
If you have any more questions, please feel free to ask on this ticket.
Sometimes I miss questions on IRC or in meetings.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29500#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs