Admit wasm simd128 runtime dispatch

Author: eldryoth

CHANGELOG.md

@@ -2,16 +2,20 @@
 
 ## 1.3.3 - 2026-07-03
 
-- Recorded the wasm `simd128` runtime-dispatch decision: wasm vector code
-  remains compile/codegen evidence only and is not admitted as an active
-  runtime backend.
+- Admitted narrow wasm `simd128` runtime dispatch for Standard and URL-safe
+  public encode plus normal strict decode when `wasm32` binaries are compiled
+  with `target-feature=+simd128`, `simd`, and the explicit
+  `allow-wasm32-best-effort-wipe` feature.
+- Added Node/V8 and Wasmtime runtime smoke evidence requiring
+  `wasm-simd128` candidate, active encode, and active decode backend reporting
+  plus Standard and URL-safe public API round trips.
 - Added `scripts/generate_wasm_simd_evidence.sh` and wired it into the local
   release checks so installed wasm targets emit release test-harness LLVM IR
   with `target-feature=+simd128` and checked vector-codegen markers.
-- Added `WASM_SIMD128_RUNTIME_REVIEW.md` and release-gated posture validation
-  documenting that wasm candidate reporting is distinct from active dispatch,
-  and that runtime/JIT timing, cleanup, fallback, and benchmark evidence remain
-  required before admission.
+- Updated `WASM_SIMD128_RUNTIME_REVIEW.md` and release-gated posture
+  validation to document the narrow admitted runtime profile, remaining
+  browser/runtime timing caveats, wasm cleanup caveats, and future broadening
+  requirements.
 - Added `Engine::profile_with_wrap` and `Engine::checked_profile_with_wrap`
   convenience helpers for turning an engine into a strict wrapped profile.
 - Synchronized all workspace crate package versions to `1.3.3`.

README.md

@@ -31,24 +31,27 @@ The crate starts conservative: a small scalar implementation, strict RFC 4648 be
 
 The current public release is `1.3.3`.
 
-`1.3.3` is a focused wasm SIMD posture and profile-ergonomics patch on top of
-the `1.3.0` implementation-completion release, the `1.3.1` Tokio writer patch,
-and the `1.3.2` non-standard SIMD surface review. It keeps the conservative
-`1.2.x` encode acceleration posture and the admitted `1.3.0` normal strict
-SIMD decode scope for Standard and URL-safe alphabet families on std
-`x86`/`x86_64` AVX-512 VBMI, AVX2, SSSE3/SSE4.1, and little-endian std
+`1.3.3` is a focused wasm SIMD runtime-dispatch and profile-ergonomics patch
+on top of the `1.3.0` implementation-completion release, the `1.3.1` Tokio
+writer patch, and the `1.3.2` non-standard SIMD surface review. It keeps the
+admitted `1.2.x` native encode acceleration posture and the admitted `1.3.0`
+normal strict SIMD decode scope for Standard and URL-safe alphabet families on
+std `x86`/`x86_64` AVX-512 VBMI, AVX2, SSSE3/SSE4.1, and little-endian std
 `aarch64` NEON after whole-input scalar validation.
 
 Encode acceleration remains active only for admitted Standard and URL-safe
 fixed-block surfaces. Decode acceleration remains limited to normal strict
 decode. Wrapped decode, legacy whitespace decode, custom alphabets,
-bcrypt-style and `crypt(3)` profiles, in-place decode, `no_std`, wasm runtime
-dispatch, and constant-time-oriented secret decode remain scalar.
+bcrypt-style and `crypt(3)` profiles, in-place decode, `no_std`, and
+constant-time-oriented secret decode remain scalar. Wasm `simd128` is admitted
+only for Standard and URL-safe public encode and normal strict decode when the
+binary is compiled with `target-feature=+simd128`, the `simd` feature, and the
+explicit `allow-wasm32-best-effort-wipe` feature.
 
-The latest patch in this line is `1.3.3`, which records that wasm `simd128`
-runtime dispatch remains unadmitted, adds release-gated wasm codegen evidence
-for the inactive prototype, and adds wrapped-profile helper ergonomics. The
-workspace crate family stays version-aligned at `1.3.3`.
+The latest patch in this line is `1.3.3`, which admits narrow wasm `simd128`
+runtime dispatch with Node/V8 and Wasmtime smoke evidence, keeps the wasm
+cleanup caveat fail-closed by default, and adds wrapped-profile helper
+ergonomics. The workspace crate family stays version-aligned at `1.3.3`.
 
 Implemented on this branch now:
 
@@ -101,6 +104,12 @@ Implemented on this branch now:
   whole-input scalar validation. Unsupported CPUs, big-endian AArch64,
   `no_std`, custom alphabets, short inputs, tails, wrapped decode, legacy
   decode, in-place decode, and CT secret decode stay scalar.
+- Runtime-dispatched wasm `simd128` fixed-block encode and normal strict
+  decode for Standard and URL-safe alphabets when built for `wasm32` with
+  `target-feature=+simd128`, `simd`, and
+  `allow-wasm32-best-effort-wipe`. The admission is backed by Node/V8 and
+  Wasmtime runtime smoke evidence; unsupported wasm builds stay scalar by
+  compiling without `+simd128`.
 - Optional `base64-ng-sanitization` companion crate for applications that
   already admit `sanitization` and want direct CT decode helpers into
   clear-on-drop secret containers.
@@ -120,9 +129,9 @@ Planned behind admission evidence:
   alphabets, no bcrypt/crypt profiles, and no constant-time-oriented secret
   decode. Default builds, unsupported runtime CPUs, `no_std`, and all
   out-of-scope decode surfaces remain scalar.
-- Additional admitted wasm `simd128`, custom alphabet, and in-place encode
-  fast paths only after separate SIMD admission evidence is complete. Default
-  builds and unsupported runtime CPUs remain scalar.
+- Additional custom alphabet, wrapped/legacy, in-place, and broader wasm
+  runtime/browser fast paths only after separate SIMD admission evidence is
+  complete. Default builds and unsupported runtime CPUs remain scalar.
 - Async reader and writer streaming is available through the optional
   `base64-ng-tokio` companion crate after cancellation-safety, accepted-byte,
   and backpressure review. The core `tokio` feature remains inert; use the
@@ -140,7 +149,7 @@ Planned behind admission evidence:
 | MSRV | Rust `1.90.0` |
 | Runtime dependencies | Zero external crates |
 | Unsafe policy | Scalar encode/decode remains safe Rust; audited unsafe is limited to volatile wiping, CT comparison/barrier helpers, and the reviewed SIMD boundary |
-| Active backend | Scalar by default; std x86/x86_64 AVX-512 VBMI preferred, then AVX2, then SSSE3/SSE4.1, plus little-endian std aarch64 NEON, when `simd` is enabled and platform checks pass |
+| Active backend | Scalar by default; std x86/x86_64 AVX-512 VBMI preferred, then AVX2, then SSSE3/SSE4.1, plus little-endian std aarch64 NEON, and wasm `simd128` when the admitted feature/runtime profile is present |
 | Strict decoding | Default, canonical, no whitespace |
 | Legacy compatibility | Explicit opt-in APIs |
 | Constant-time posture | Constant-time-oriented scalar validation/decode with isolated dudect-style timing evidence; no formal cryptographic guarantee |

docs/CRATE_VERSION_MATRIX.md

@@ -8,8 +8,9 @@ sets.
 ## 1.3.3 Release Plan
 
 The `1.3.3` release keeps the workspace crate family synchronized. The main
-crate carries the wasm `simd128` runtime-posture decision, release-gated wasm
-codegen evidence, and wrapped-profile helper ergonomics. Companion crates
+crate carries the narrow wasm `simd128` runtime-dispatch admission, Node/V8 and
+Wasmtime smoke evidence, release-gated wasm codegen evidence, and
+wrapped-profile helper ergonomics. Companion crates
 receive synchronized package metadata so downstream users see one coherent
 crate-family version.
 

docs/PLAN.md

@@ -1043,27 +1043,29 @@ inside the `1.3.x` line if they remain evidence-gated and do not weaken the
 - Pentest each admitted surface separately because this is several admission
   surfaces, not one feature.
 
-`1.3.3`: wasm `simd128` runtime-dispatch decision.
-
-- Decide whether a specific wasm runtime/deployment profile can be admitted.
-- First checkpoint: keep wasm `simd128` runtime dispatch unadmitted and record
-  the decision in
-  [WASM_SIMD128_RUNTIME_REVIEW.md](WASM_SIMD128_RUNTIME_REVIEW.md), because
-  current evidence is compile/codegen-only and does not prove runtime/JIT
-  timing, register-retention, cleanup, fallback, or benchmark posture.
-- Second checkpoint: add `scripts/generate_wasm_simd_evidence.sh` to emit
-  release test-harness LLVM IR with `target-feature=+simd128` and check vector
-  codegen markers while still treating wasm as non-dispatchable runtime
-  evidence.
-- If admitted, implement an explicit wasm dispatch boundary and evidence for
-  encode first, then decode only if the same evidence standard is met.
+`1.3.3`: wasm `simd128` runtime-dispatch admission.
+
+- Admit a narrow wasm `simd128` runtime profile for Standard and URL-safe
+  public encode plus normal strict decode when the binary is compiled with
+  `target-feature=+simd128`, `simd`, and the explicit
+  `allow-wasm32-best-effort-wipe` feature.
+- Record the decision in
+  [WASM_SIMD128_RUNTIME_REVIEW.md](WASM_SIMD128_RUNTIME_REVIEW.md), including
+  the limits: this does not prove every browser/JIT, runtime timing,
+  register-retention, cleanup, fallback, or benchmark posture.
+- Add `scripts/generate_wasm_simd_evidence.sh` to emit release test-harness
+  LLVM IR with `target-feature=+simd128` and check vector codegen markers.
+- Add `scripts/check_wasm_runtime_dispatch.sh` to build a wasm smoke module and
+  execute it under Node/V8 and Wasmtime, requiring `wasm-simd128` candidate,
+  active encode, and active decode backend reporting plus Standard and
+  URL-safe public API round trips.
 - Keep wasm wipe behavior fail-closed unless callers explicitly enable
   `allow-wasm32-best-effort-wipe`.
 - Document JIT, runtime, timing, and zeroization caveats without implying
   hardware-like guarantees.
-- Add CI target evidence and generated-code review for the admitted wasm
-  profile. If the runtime evidence is incomplete, keep wasm `simd128` as
-  compile/codegen evidence only.
+- Keep broader wasm/browser profiles, custom alphabets, wrapped/legacy
+  surfaces, in-place decode, and CT secret decode scalar until separate
+  evidence admits them.
 
 `1.3.4`: big-endian and niche-architecture acceleration review.
 

docs/RELEASE_EVIDENCE.md

@@ -60,13 +60,19 @@ The release gate runs:
 - fail-closed wasm wipe policy check proving default `wasm32` builds reject
   compiler-fence-only cleanup and the explicit
   `allow-wasm32-best-effort-wipe` opt-in build succeeds
-- wasm SIMD posture validation proving wasm `simd128` remains
-  compile/codegen evidence only and is not represented as an active backend
+- wasm SIMD posture validation proving the narrow wasm `simd128` runtime
+  dispatch profile, its feature gates, its runtime smoke evidence, and its
+  remaining JIT/zeroization caveats
 - wasm SIMD codegen evidence through
   `scripts/generate_wasm_simd_evidence.sh`, which emits release test-harness
   LLVM IR with `target-feature=+simd128` when the wasm target is installed and
   checks for vector shuffle, 128-bit byte-vector, and wasm bitselect markers
-  without claiming runtime/JIT admission
+  while leaving runtime/JIT behavior to the separate runtime smoke gate
+- wasm simd128 runtime smoke evidence through
+  `scripts/check_wasm_runtime_dispatch.sh`, which builds a wasm32 smoke module
+  with `target-feature=+simd128` and executes it under Node/V8 and Wasmtime
+  when installed, requiring `wasm-simd128` active encode/decode reporting and
+  Standard plus URL-safe round trips
 - fail-closed unsupported-native wipe policy documented through
   `allow-compiler-fence-only-wipe` for architectures without an implemented
   hardware wipe barrier
@@ -280,8 +286,8 @@ This currently proves `no_std` reserved builds for AVX2, SSSE3/SSE4.1, the
 AVX-512 Base64 candidate bundle (`avx512f`, `avx512bw`, `avx512vl`, and
 `avx512vbmi`), NEON, and wasm `simd128` when the corresponding Rust targets
 are installed. For wasm `simd128`, the script also builds the wasm test
-binaries with `target-feature=+simd128` so the inactive fixed-block prototype
-body remains typechecked and codegen-ready without requiring a wasm runtime.
+binaries with `target-feature=+simd128` so the admitted fixed-block wasm code
+remains typechecked and codegen-ready.
 
 Capture local runtime backend and prototype evidence with:
 
@@ -294,17 +300,18 @@ scalar-equivalence tests with `--nocapture`. The runtime report records
 `candidate_detection_mode`, which distinguishes x86/x86_64 `std` runtime CPU
 probing from compile-time target-feature reporting used by `no_std` and other
 compile-time-only targets. On CPUs with AVX-512 VBMI, AVX2, SSSE3/SSE4.1, or
-little-endian AArch64 NEON, an admitted encode path may be active for Standard
-and URL-safe alphabets. Big-endian AArch64 stays scalar, and 32-bit ARM NEON
-remains scaffold evidence. Wasm `simd128` evidence is kept in
-`scripts/check_simd_feature_bundles.sh` as compile/test-binary evidence only
-because runtime JIT behavior is outside the crate's release gate. The
-script writes
+little-endian AArch64 NEON, or wasm `simd128`, an admitted encode path may be
+active for Standard and URL-safe alphabets. Big-endian AArch64 stays scalar,
+and 32-bit ARM NEON remains scaffold evidence. Wasm `simd128` evidence is kept
+in `scripts/check_simd_feature_bundles.sh` as compile/test-binary evidence and
+in `scripts/check_wasm_runtime_dispatch.sh` as Node/V8 and Wasmtime runtime
+smoke evidence. Runtime/JIT timing behavior remains outside the crate's formal
+claim. The script writes
 `target/release-evidence/backend/MANIFEST.txt`, `runtime-backend-report.txt`,
 and `simd-prototype-equivalence.txt` so local CPU evidence can be archived. The
 manifest labels prototype-only evidence as `real-non-dispatchable` and
 separately records
-`active_backend_admitted=avx512-vbmi-or-avx2-or-ssse3-sse4.1-or-neon-encode`,
+`active_backend_admitted=avx512-vbmi-or-avx2-or-ssse3-sse4.1-or-neon-or-wasm-simd128-encode`,
 so audit logs do not confuse remaining fixed-block prototype execution with
 active dispatch admission.