forked from unom/punktfunk
enricobuehler
c814340607
aes 0.9 runtime-detects the ARMv8-Crypto backend on aarch64 via `cpufeatures` and polyval 0.7
picks its armv8 PMULL intrinsics by target_arch, so neither cfg exists any more — passing them
is inert. That retires a real footgun rather than tidying a file: a RUSTFLAGS env var overrides
config rustflags ENTIRELY, so every aarch64 lane that set its own (cargo-ndk does so internally
for every Android arm64-v8a build) silently dropped both and ran SOFTWARE AES on the per-packet
decrypt path.
Measured before deleting, `crypto/open_in_place` (1408-byte MTU shard, AES-128-GCM, single core,
Mac15,14 M3 Ultra, four runs back to back under identical background load):
aes 0.8 + both cfgs 2.19 GiB/s
aes 0.8, cfgs stripped 225 MiB/s ~10x cliff — reproduces the recorded ~240 MiB/s
aes 0.9 + both cfgs 5.28 GiB/s
aes 0.9, cfgs stripped 5.28 GiB/s identical to 4 s.f.
The ChaCha20-Poly1305 series of the same bench was the control and moved 0.07% across the cfg
toggle at both versions, so the toggle demonstrably reached only the AES path. A final run with
the flags actually deleted (not merely RUSTFLAGS-overridden) reproduced 5.29 GiB/s.
.cargo/config.toml is kept as a tombstone carrying that table so the flags are not reintroduced.
The two CI comments that warned about losing these cfgs to a RUSTFLAGS override are updated —
mold in ci/cargo-config-mold.toml is now the only thing such an override can cost.
40 lines
2.3 KiB
TOML
40 lines
2.3 KiB
TOML
# Workspace-wide build flags.
|
|
#
|
|
# THERE ARE DELIBERATELY NONE. This file is kept as a tombstone so the aarch64 AES cfgs are not
|
|
# reintroduced — read this before adding rustflags here.
|
|
#
|
|
# Until 2026-08-13 this file carried:
|
|
#
|
|
# [target.'cfg(target_arch = "aarch64")']
|
|
# rustflags = ["--cfg", "aes_armv8", "--cfg", "polyval_armv8"]
|
|
#
|
|
# because RustCrypto's `aes` 0.8.x enabled the ARMv8-Crypto hardware AES backend on aarch64 ONLY
|
|
# behind `--cfg aes_armv8`, and `polyval` 0.6.x gated its PMULL (carry-less multiply) GHASH path
|
|
# behind `--cfg polyval_armv8`. That was a live footgun, not just boilerplate: a RUSTFLAGS
|
|
# ENVIRONMENT VARIABLE OVERRIDES CONFIG RUSTFLAGS ENTIRELY — it does not merge and does not
|
|
# append — so every aarch64 lane that set its own RUSTFLAGS silently dropped both and fell back to
|
|
# SOFTWARE AES on the per-packet decrypt path. cargo-ndk sets RUSTFLAGS internally for its linker
|
|
# configuration, which means every Android arm64-v8a build was hitting exactly that.
|
|
#
|
|
# `aes` 0.9 removed the cfg: on aarch64 it runtime-detects with `cpufeatures::new!(features_aes,
|
|
# "aes")` (lib.rs), the same way x86_64 AES-NI always did. `polyval` 0.7 likewise selects
|
|
# `backend/intrinsics/armv8.rs` by `target_arch` alone. Neither cfg exists any more — passing them
|
|
# is inert.
|
|
#
|
|
# Measured here before deleting them, `crypto/open_in_place` from benches/pipeline.rs (one 1408-byte
|
|
# MTU shard, AES-128-GCM, single core, Mac15,14 M3 Ultra, all four runs back to back under the same
|
|
# background load):
|
|
#
|
|
# aes 0.8 + both cfgs 2.19 GiB/s <- what the cfgs bought
|
|
# aes 0.8, cfgs stripped 225 MiB/s <- the footgun: ~10x slower, software AES
|
|
# aes 0.9 + both cfgs 5.28 GiB/s
|
|
# aes 0.9, cfgs stripped 5.28 GiB/s <- identical to 4 s.f.; the cfgs do nothing
|
|
#
|
|
# The ChaCha20-Poly1305 series of the same bench was the control: it moved 0.07% across the cfg
|
|
# toggle at both versions, confirming the toggle reached only the AES path.
|
|
#
|
|
# So 0.9 without the cfgs is not merely as fast as 0.8 with them — it is ~2.4x faster, and ~24x
|
|
# the software fallback. Do not re-add these flags; if a future aarch64 slowdown is suspected,
|
|
# re-run `cargo bench -p punktfunk-core --bench pipeline -- in_place` and compare against the
|
|
# table above rather than reaching for a cfg.
|