Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 37 additions & 1 deletion .cargo/config.toml
Original file line number Diff line number Diff line change
Expand Up @@ -48,5 +48,41 @@
#
# Read by curve25519-dalek's build.rs via CARGO_CFG_CURVE25519_DALEK_BACKEND.
# Verify: cargo build -p encryption -v 2>&1 | grep curve25519_dalek_backend

# poly1305 backend: SOFT, deliberately. Same reasoning as dalek above, but
# unlike dalek this surface was actually REACHING THE BINARY.
#
# `crates/encryption` -> `chacha20poly1305` -> `poly1305`, and poly1305 0.8
# auto-selects its AVX2 backend on any x86/x86_64 target unless told otherwise.
# That backend is 424 `_mm*` intrinsic calls under 30 `unsafe` occurrences in a
# single file (`src/backend/avx2/helpers.rs`) — over seven times dalek's 57, and
# a second unaudited SIMD surface beside `ndarray::simd`, which is what the
# matryoshka pattern exists to prevent.
#
# Reachability, not porting: the whole thing is gated behind one cfg —
# `src/backend.rs`, `#[cfg(all(any(target_arch = "x86", target_arch = "x86_64"),
# not(poly1305_force_soft)))] pub(crate) mod avx2;` — so the flag below compiles
# it out without touching a line of crypto.
#
# What it costs: the soft backend (poly1305-donna, the same algorithm) instead
# of the AVX2 one, on the AEAD's MAC. That is a real throughput cost on large
# payloads and it has NOT been measured here. It is accepted because the
# alternative is an unaudited intrinsic surface in the crypto path.
#
# What it does NOT mean: writing our own Poly1305. Per the operator-ratified
# doctrine in `.claude/CHACHA20_MATRYOSHKA_PLAN.md` — "RustCrypto owns the
# algorithm; ndarray owns the SIMD... Rolling your own AEAD (HChaCha20 +
# Poly1305 + framing) is the footgun; it is forbidden." The sanctioned way to
# accelerate this later is the chacha20 route: vendor the fork and give
# RustCrypto's own backend an `ndarray::simd` lane, never a reimplementation.
#
# Read by poly1305's src/backend.rs as a plain cfg.
# Verify: cargo build -p encryption -v 2>&1 | grep poly1305_force_soft
[target.'cfg(target_arch = "x86_64")']
rustflags = ["-Ctarget-cpu=x86-64-v3", "--cfg", "curve25519_dalek_backend=\"serial\""]
rustflags = [
"-Ctarget-cpu=x86-64-v3",
"--cfg",
"curve25519_dalek_backend=\"serial\"",
"--cfg",
"poly1305_force_soft",
Comment on lines +86 to +87

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Preserve the soft-backend cfg when RUSTFLAGS is set

When this workspace is built with RUSTFLAGS set, Cargo uses that environment source instead of the matching target.<cfg>.rustflags array, so poly1305_force_soft is silently dropped; this occurs in every GitHub Actions job because .github/workflows/ci.yaml:23 globally sets RUSTFLAGS: "-D warnings", and likewise affects any downstream build that supplies its own compiler flags. I confirmed this precedence with Cargo 1.95, and the Cargo configuration reference specifies that only the first applicable rustflags source is used. Consequently, an x86_64 build of encryption in those environments still compiles Poly1305's AVX2 backend, defeating the purpose of this change; ensure supported RUSTFLAGS settings include this cfg or enforce the backend through a mechanism that cannot be replaced by them.

Useful? React with 👍 / 👎.

]
Loading