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

This path in hashx_vm_alloc_huge() for OpenBSD and NetBSD always
fails without checking its parameter. Fix the warning.

As suggested by @wiz on #40843, let's add an explicit check to
hashx_vm_alloc_huge() that avoids using a Linux-style default
on NetBSD targets.

This doesn't change the questionable Linux-style default,
but a future patch will disable this code by default so it's not a
portability liability.

(This code is in hashx's VM layer but it's actually only relevant to
equix.)

This addresses bug #40843. Another patch will disable huge pages
by default entirely, but this patch is sufficient to fix the NetBSD
build.

Also add more info to leg dump.

HTML in comment, what a bad idea...

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

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.

Clippy found a transmute that could have been a reborrow.

This reverts commit 5487476f.

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.

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.

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.

Fix a couple cases where size_t values were being confused with int.

Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

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>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Close #40824

Signed-off-by: David Goulet <dgoulet@torproject.org>

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.

Fixes bug 40805; bugfix on 0.4.7.1-alpha.