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>

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

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

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

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

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

relay: Remove logging for a bug. It triggers a BUG() later

See merge request tpo/core/tor!738

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

hashx: Rust hook for inspecting and modifying the random number stream

See merge request tpo/core/tor!734

Fix assert crash on relay-side due to on_circuit backpointer

See merge request tpo/core/tor!737

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

Bug40828

See merge request tpo/core/tor!736

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>

Include a basic Rust wrapper for Equi-X and HashX

See merge request tpo/core/tor!733

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>

Warn when operating as bridge and exit

Closes #40819

See merge request tpo/core/tor!730

fix non-fatal assertion when rotate_onion_key fails

Closes #40554

See merge request tpo/core/tor!729

gitlab-ci: fix apt conf syntax for Acquire::Retries

See merge request tpo/core/tor!705