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