[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: teor
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: 3
padding, 041-proposed, 040-must, tor-ci-fail- |
sometimes |
Parent ID: #28631 | Points: 3
Reviewer: nickm | Sponsor:
| Sponsor2
-------------------------------------------------+-------------------------
Comment (by mikeperry):
Replying to [comment:20 teor]:
> Here are three 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.)
I am still not understanding the issue here. Or I am understanding
differently than you. Let me try to reply here and say what I think you
mean/what I think is true.
> 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
2. Tor calls a monotime_init() function at startup, and stores the FIRST
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.
6. If wall clock time moved back to a time period **earlier than
monotime_init() AND does this before Tor stores a ratchet value**, then
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
2. Tor calls monotime_init() function at startup, and stores the FIRST
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
> 5. The monotime_absolute() function gets the same value for the previous
and current times. It returns zero.
5. The monotime_absolute() function gets the same time value as
monotime_init(), because less than the timer resolution amount of time has
elapsed since monotime_init() was called. Then, and only then, it returns
0.
> 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
2. Tor calls monotime_init() function at startup, and stores an
initialization time in low-resolution units.
> 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.
> 5. 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.)
5. The monotime_absolute() function gets the same time value as
monotime_init(), because less than the timer resolution amount of time has
elapsed since monotime_init() was called. Then, and only then, it returns
0.
In all but the first case (monotime Windows bugs), the
monotime_absolute_usec() functions cannot return 0 after more than the
time resolution period has passed since monotime_init(). Even in the first
case, monotime_absolute_usec() cannot return 0 unless the clock moves
backwards **before the ratchet value is stored**. In all other cases, the
ratchet value should be stored as a non-zero value and all subsequent
calls to monotime_absolute_usec() are non-zero...
Furthermore, I'm deeply confused about how in #29990, host and VM time has
*any* effect on our mocked monotime values for unit tests. I think what
we're actually looking at here is that the unittests themselves are
incrementing monotime below the resolution of some platforms, which I why
I tried to fix this with changes to just the unittests... but I'll take my
comments about #29990 there.
I would request that we not merge hacky changes to the unittests for the
#29990 workarounds. If we're going to hack this, let's hack it so
monotime_init() (or the ratchet) has a non-zero value, and then we can go
through circpad for the rare cases where the difference between
monotime_init() and the first ratchet update is 0 (or negative), in
production (which I still believe should be rare/impossible).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29500#comment:33>
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