I saw this test fail intermittently due to what seemed like a filesystem
race in docker? The cleanup task was failing with a 'directory not
empty' error, despite trying to do a recursive 'rm'. This patch adds an
'ls' to the same directory, hoping the output might be useful to
diagnose future intermittent failures.
Change 3f66ff9b000d1fbaae106e58269fe2aa306bc453 added geoip-db-tool to
the main workspace, so it's no longer using a local lockfile. Move its
lock to the crate root, remove from gitignore, and update it.
(We could also choose to not keep the lockfiles checked in, but it seems
useful to have them in our test and maintenance tooling here.)
David Goulet [Mon, 14 Aug 2023 15:03:47 +0000 (11:03 -0400)]
zstd: Check errors right affer compressing/decompressing
Considering a compression bomb before looking for errors led to false negative
log warnings. Instead, it is possible the work failed for whatever reasons
which is not indicative of a compression bomb.
Fixes #40739
Signed-off-by: David Goulet <dgoulet@torproject.org>
This was causing CI failures that didn't reproduce on my local machine.
The DoS subsystem now has a new assert() which triggers a BUG on some
nonzero memory contents (or_conn->tracked_for_dos_mitigation), and
uninitialized stack memory might be nonzero.
Extend DoS protection to IP addresses with known relays
This exemption used to be helpful in keeping exit relays from tripping
the DoS detection subsystem and losing Tor connectivity. Now exit relays
block re-entry into the network (tor issue #2667) so it's no longer
needed. We'd like to re-enable protection on these addresses to avoid
giving attackers a way around our DoS mitigations.
hashx: Fix rare compiler output overflow on aarch64
This is a fix for a very rare buffer overflow in hashx, specific to the
dynamic compiler on aarch64 platforms.
In practice this issue is extremely unlikely to hit randomly, and it's
only been seen in unit tests that supply unusual mock PRNG output to the
program generator. My best attempt at estimating the probability of
hitting the overflow randomly is about 10^-23. Crafting an input with
the intent to overflow can be done only as fast as an exhaustive search,
so long as Blake2B is unbroken.
The root cause is that hashx writes assembly code without any length
checks, and it uses an estimated size rather than an absolute maximum
size to allocate the buffer for compiled code. Some instructions are
much longer than others, especially on aarch64.
The length of the overflow is nearly 300 bytes in the worst synthetic
test cases I've developed so far. Overflow occurs during hashx_make(),
and the subsequent hashx_exec() will always SIGSEGV as the written code
crosses outside the region that's been marked executable. In typical use,
hashx_exec() is called immediately after hashx_make().
This fix increases the buffer size from 1 page to 2 pages on aarch64,
adds an analysis of the compiled code size, and adds runtime checks so we
can gracefully fail on overflow. It also adds a unit test (written in
Rust) that includes a PRNG sequence exercising the overflow. Without
this patch the unit test shows a SIGSEGV on aarch64, with this patch it
runs successfully and matches interpreter output.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
tor only marks a channel as 'open' once the TLS and OR handshakes have both
completed, and normal "client" (ORPort) DoS protection is not enabled until
the channel becomes open. This patch adds an additional earlier initialization
path for DoS protection on incoming TLS connections.
This leaves the existing dos_new_client_conn() call sites intact, but adds a
guard against multiple-initialization using the existing
tracked_for_dos_mitigation flag. Other types of channels shouldn't be affected
by this patch.
hashx: Rust hook for inspecting and modifying the random number stream
This patch has no effect on the C tor build.
Adds a function hashx_rng_callback() to the hashx API, defined only
when HASHX_RNG_CALLBACK is defined. This is then used in the Rust
wrapper to implement a similar rng_callback().
Included some minimal test cases. This code is intented for
use in cross-compatibility fuzzing tests which drive multiple
implementations of hashx with the same custom Rng stream.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
The idea behind this is that we may want to start exporting more pieces
of c-tor as Rust crates so that Arti can perform cross compatibility and
comparison testing using Rust tooling.
This turns the 'tor' repo into a Cargo workspace, and adds one crate to
start with: "tor-c-equix", rooted in src/ext/equix. This actually
includes both Equi-X itself and HashX, since there's less overall
duplication if we package these together instead of packaging HashX
separately.
This patch adds a basic safe Rust interface, but doesn't expose any
additional internals for testing purposes.
No changes to the C code here or the normal Tor build system.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Nick Mathewson [Thu, 13 Jul 2023 20:03:16 +0000 (16:03 -0400)]
Clarify where geoip-db-tool is.
Somebody emailed me to ask where to find the tool that generated our
geoip file. I was about to suggest that they search for "geoip-db-tool",
when I found that you can't actually search for that and find our code.
Rotate to a new L2 vanguard whenever an existing one loses the
Stable or Fast flag. Previously, we would leave these relays in the
L2 vanguard list but never use them, and if all of our vanguards
end up like this we wouldn't have any middle nodes left to choose
from so we would fail to make onion-related circuits.
projects / thirdparty / tor.git / log
