Equi-X supports optionally allocating its solver memory using huge
pages, to reduce the virtual memory subsystem overhead required to make
the entire solver buffer live.
Tor doesn't use this feature, since it seems to have no noticeable
performance benefit at this time, but we still included code for it at
compile time. To improve portability, this patch disables huge page
support by default and enables it only in the cmake build system used
for equix benchmarks.
With this patch equix-bench still supports huge pages. Verified using
strace that we're making the hugepage allocation.
There's no fallback for huge pages, so Equi-X initialization will fail
if they are requested and we don't support them for any runtime or
compile-time reason.
Addresses #40843 (NetBSD) but also prevents future porting issues
related to huge pages.
NetBSD includes the idea of a 'maximum protection' per-region,
and an mprotect which exceeds the max protection will be denied.
If we explicitly ask for a maximum which includes execute permission, we
can successfully swap our code buffer's permissions between read-write
and read-execute when each hash program is compiled.
With this patch, the crypto/hashx tests pass on NetBSD 9.
This addresses bug #40844
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.
projects / thirdparty / tor.git / log
