[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #30871 [Core Tor/Tor]: circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/feature/hs/hs_service.c:3166 (first at ../src/feature/hs/hs_service.c:2385)

#30871: circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at
../src/feature/hs/hs_service.c:3166 (first at
../src/feature/hs/hs_service.c:2385)
-------------------------------------------------+-------------------------
 Reporter:  s7r                                  |          Owner:  dgoulet
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.1.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.4.1.2-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs 041-should 041-regression?    |  Actual Points:
  double-mark                                    |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by dgoulet):

 So the HS system (v2 or v3) will not launch introduction circuits until 3
 things are true:

 {{{
   if (!have_completed_a_circuit() || net_is_disabled() ||
       networkstatus_get_live_consensus(now) == NULL) {
     goto end;
   }
 }}}

 In _theory_ the `have_completed_a_circuit()` is the one telling us that
 the Guard is usable because we were able to complete a full circuit
 through it.

 However, it seems that once those introduction circuits were launched, 3
 of them ended up in waiting to "see how the guard performs". I bet it is
 because the circuit went _back_ into "wait for guard state" after opening
 some circuits which lead to this situation. In theory, it should be "fine"
 I believe.

 Now onto the main problem, the duplicate close. The warnings before are v2
 ... but that duplicate close is for the v3 which has no warnings. The
 "exceeded limit" log is at info level for v3...

 So roughly 5 minutes after bootstrap, the v3 introduction circuit finally
 opened but the introduction point authentication key disappeared from our
 state. This is all but too familiar (#28970 and #27471) ... Somehow, both
 on client or service side, we loose track (or clean it) of the
 authentication key of an IP leading to these BUG().

 This duplicate mark for close is the hint I think. It appears we have a
 code path in tor that can mark an intro circuit for close and then that
 circuit is called with the "has opened" callback leading to this double
 close.

 The freeing of the circuit is deferred as a "post main loop" event. I'm
 wondering if it is possible for this sequence to happen within a _single_
 main loop run:

 1) Intro circuit(s) is *mark* for close and thus cleaned up from the HS
 state. Could be on descriptor rotation or build time out for instance.
 2) The "circuit has opened" callback is called for the mark for close
 circuit.
 3) The freeing of that circuit is done post main loop.

 If possible, then the (2) should never have been done on a marked for
 close.

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