[tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#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