Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  merge_ready
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.4.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.2.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, prop224,                     |  Actual Points:
  034-triage-20180328, 034-removed-20180502      |
Parent ID:                                       |         Points:  1
 Reviewer:  dgoulet                              |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:23 dgoulet]:
 >
 > Because we recalculate the data in an event loop now, it means other
 events can trigger the assert() on the hsdir indexes because they would
 see the consensus being live but the recalculate consensus callback was
 not yet triggered. For instance, a client request to a .onion will trigger
 the assert() if done before the recalculation happened because it would
 consider the consensus live.
 >
 > In other words, there is a time gap between "clock jump, now I have a
 live consensus" and "recalculate conensus data", we'll end up in some
 desynch state imo. HS is just one big example, there might be more.
 >

 Hm, I guess the HS-client example above is indeed a plausible (but
 unlikely) edge-case. It's worth noting that the example you cited above
 applies only to the HS client case, whereas I think we covered it for HS
 services since services basically function based on those callbacks. Of
 course, there might be other cases around the codebase, which we are not
 aware of right now ("if a tree falls in a forest and no one is around to
 hear it...").

 Some obvious approaches:

 a) Fix all the cases by recomputing data immediately when a clock jump is
 noticed (as per my first branch). This has the negative effect of giving
 variable time duration to the callback as Nick pointed out.
 b) Fix the HS client edge-case dgoulet pointed out, by calling
 `recalculate_consensus_data_callback()` when an HS client tries to connect
 to an HS.
 c) Merge Nick's branch and leave the edge-cases open. In the future, we
 can fix those too as we understand more things about this problem.
 d) Do more research, try to understand the problem more, and figure out an
 even better solution if possible...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24977#comment:24>
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