Exposing cell_queues_get_total_allocation(), buf_get_total_allocation(),
tor_compress_get_total_allocation(), tor_compress_get_total_allocation() when
hit MaxMemInQueues threshold.
Fixes #24501
Signed-off-by: Fernando Fernandez Mancera <ffernandezmancera@gmail.com>
teor [Sun, 10 Dec 2017 15:29:05 +0000 (02:29 +1100)]
Make sure bridges are definitely running before delaying directory fetches
Retry directory downloads when we get our first bridge descriptor
during bootstrap or while reconnecting to the network. Keep retrying
every time we get a bridge descriptor, until we have a reachable bridge.
Stop delaying bridge descriptor fetches when we have cached bridge
descriptors. Instead, only delay bridge descriptor fetches when we
have at least one reachable bridge.
teor [Sun, 10 Dec 2017 14:14:28 +0000 (01:14 +1100)]
Simplify some conditionals in circuit_get_open_circ_or_launch()
When entry_list_is_constrained() is true, guards_retry_optimistic()
always returns true.
When entry_list_is_constrained() is false,
options->UseBridges is always false,
therefore !options->UseBridges is always true,
therefore (!options->UseBridges || ...) is always true.
When we cleanup intro points, we iterate over the descriptor's map of intro
points and we can possibly mark for close a circuit. This was problematic
because we would MAP_DEL_CURRENT() the intro point then free it and finally
mark for close the circuit which would lookup the intro point that we just
free in the map we are iterating over.
This can't be done and leads to a use-after-free because the intro point will
be returned successfully due to the fact that we are still in the loop
iterating. In other words, MAP_DEL_CURRENT() followed by a digest256map_get()
of the same object should never be done in the same loop.
Fixes #24595
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Mon, 11 Dec 2017 20:42:28 +0000 (15:42 -0500)]
sched: Avoid integer overflow when computing tcp_space
In KIST, we could have a small congestion window value than the unacked
packets leading to a integer overflow which leaves the tcp_space value to be
humongous.
This has no security implications but it results in KIST scheduler allowing to
send cells on a potentially saturated connection.
Found by #24423. Fixes #24590.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Don't consider a port "handled" by an isolated circuit.
Previously, circuit_stream_is_being_handled incorrectly reported
that (1) an exit port was "handled" by a circuit regardless of
whether the circuit was already isolated in some way, and
(2) that a stream could be "handled" by a circuit even if their
isolation settings were incompatible.
As a result of (1), in Tor Browser, circuit_get_unhandled_ports was
reporting that all ports were handled even though all non-internal
circuits had already been isolated by a SOCKS username+password.
Therefore, circuit_predict_and_launch_new was declining to launch
new exit circuits. Then, when the user visited a new site in Tor
Browser, a stream with new SOCKS credentials would be initiated,
and the stream would have to wait while a new circuit with those
credentials could be built. That wait was making the
time-to-first-byte longer than it needed to be.
Now, clean, not-yet-isolated circuit(s) will be automatically
launched ahead of time and be ready for use whenever a new stream
with new SOCKS credentials (or other isolation criteria) is
initiated.
Fixes bug 18859. Thanks to Nick Mathewson for improvements.
David Goulet [Wed, 6 Dec 2017 16:33:01 +0000 (11:33 -0500)]
test: Add a KIST test for a non opened channel
This makes sure that a non opened channel is never put back in the channel
pending list and that its state is consistent with what we expect that is
IDLE.
Test the fixes in #24502.
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Mon, 4 Dec 2017 16:49:48 +0000 (11:49 -0500)]
hs-v3: Cleanup HS circuits when marking as closed
First, hs_service_intro_circ_has_closed() is now called in circuit_mark_for
close() because the HS subsystem needs to learn when an intro point is
actually not established anymore as soon as possible. There is a time window
between a close and a free.
Second, when we mark for close, we also remove it from the circuitmap because
between the close and the free, a service can launch an new circuit to that
same intro point and thus register it which only succeeds if the intro point
authentication key is not already in the map.
However, we still do a remove from the circuitmap in circuit_free() in order
to also cleanup the circuit if it wasn't marked for close prior to the free.
Fixes #23603
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Mon, 25 Sep 2017 20:47:16 +0000 (16:47 -0400)]
hs-v3: Don't cleanup intro point in has_closed()
The hs_service_intro_circ_has_closed() was removing intro point objects if too
many retries.
We shouldn't cleanup those objects in that function at all but rather let
cleanup_intro_points() do its job and clean it properly.
This was causing an issue in #23603.
Furthermore, this moves the logic of remembering failing intro points in the
cleanup_intro_points() function which should really be the only function to
know when to cleanup and thus when an introduction point should be remembered
as a failed one.
Fixes #23603
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Mon, 4 Dec 2017 19:48:15 +0000 (14:48 -0500)]
sched: Set channel scheduler state to IDLE when not opened
In the KIST main loop, if the channel happens to be not opened, set its state
to IDLE so we can release it properly later on. Prior to this fix, the channel
was in PENDING state, removed from the channel pending list and then kept in
that state because it is not opened.
David Goulet [Mon, 4 Dec 2017 17:22:02 +0000 (12:22 -0500)]
sched: Downgrade warning log to info in KIST
Some platforms don't have good monotonic time support so don't warn when the
diff between the last run of the scheduler time and now is negative. The
scheduler recovers properly from this so no need to be noisy.
Fixes #23696
Signed-off-by: David Goulet <dgoulet@torproject.org>
projects / thirdparty / tor.git / log
