open-standards/.github/workflows/wai-formal-verification.yml
Transaction Science ec45aaaca9 toolchain: Rust 1.98.0 -> 1.99.1 (change-controlled pin)
Approved by the owner on 2026-10-22. Procedure: change `channel`, run
`rustup show`, then run the pipeline.

What changed
- rust-toolchain.toml and eoc/eoc-rs/rust-toolchain.toml: channel "1.98.0"
  becomes "1.99.1". These are the only two pins in the tree, and the root one
  governs every other cargo root.
- 64 workflows under .github/workflows (the forge's CI): every `Install Rust
  1.98.0`, `rustup toolchain install / default / component add / target add
  --toolchain 1.98.0` and `--default-toolchain 1.98.0` now names 1.99.1
  (409 lines). Two of those lines are in build steps rather than install
  steps (wai-conformance.yml's two `wasm32 (unix)` steps each
  `rustup target add --toolchain`), and they move with the rest: a target
  added to a toolchain that is not installed is an error.
- Left as they are, because they record what was measured on 1.98.0:
  standards-build.yml's "Verified on a native arm64 Linux container (rustc
  1.98.0)", wai-conformance.yml's note on Rust 1.98's LLD 22, and the
  "rustc 1.98.0 (example)" strings in receipts, vectors and docs. The
  one-codegen-unit workaround that note explains also stays. 1.99.1 ships
  LLD 23.1.1, which the note says links those inputs, but removing the
  workaround should wait for a run at the CI path on x86_64.

Why
- 1.98.0 has a P-critical miscompile, rust-lang/rust#161441 (I-miscompile,
  regression-from-stable-to-stable). rustc emits a vacant (null) method slot
  in a trait-object vtable, so a safe dynamic call jumps to address zero
  (undefined behaviour). RELEASES.md records the fix in 1.98.1 ("rustc: fix
  miscompilation in generating vtables").
- 1.99.1 is the current stable (channel manifest dated 2026-10-15; rustc
  58cf8f9c3 2026-10-13). It also fixes 1.99.0's own regressions: wcslen on
  UEFI and embedded targets, x86_64 FFI `bool` returns, and the rust-lld rpath
  on macOS.

Evidence
All of it ran on the build host ([email protected], aarch64-apple-darwin)
through ~/kani-logs/remote/rb. Nothing was built on the dev Mac.

- `rustup show`: the active toolchain is 1.99.1-aarch64-apple-darwin,
  "overridden by .../rust-toolchain.toml" (and by eoc/eoc-rs's own file
  there). rustc 1.99.1 (58cf8f9c3 2026-10-13), LLVM 23.1.1, clippy 0.1.99,
  rustfmt 1.10.0. The baseline is rustc 1.98.0 (88d9e12ae 2026-08-18).
- Scope: every cargo root the pin governs, which is 46 of the 49 tracked
  lockfiles. The other three: two are vendored crates that resolve inside
  their parents, and wai/wai-rs/fuzz builds on its own pinned nightly.
- Trees. The final tree is main at 96117c570 plus these two commits. Main
  moved four times while this ran, and each root's evidence comes from the
  newest tree it was run on:
  - 13 roots on the final tree: every root main changed after 1a465f23d,
    and every root that consumes such a crate by path.
  - 12 roots on 1a465f23d plus these two commits.
  - 7 roots on b16816671 plus these two commits.
  - 14 roots on aa61ab3b9 plus the pin change.
  For each root in the last three groups, checked with git diff and the
  lockfiles' path packages: none of its files, and no crate it reaches by
  path, differs on the final tree.
- Each root got:
  (a) `cargo fmt --all -- --check` on the pin and on 1.98.0. The output is
      byte-identical in all 46. CI gates no root on rustfmt, and none is
      rustfmt-clean on main.
  (b) `cargo clippy --locked --keep-going --workspace --all-targets` on both
      toolchains, with the diagnostics compared line by line. After the
      previous commit, no root has a diagnostic that only 1.99.1 reports.
      openpay's one differing line is the same lint at the same site,
      reworded.
  (c) `cargo test --workspace --locked`.
  (d) the root's other CI steps that can run on this host: feature-gated
      tests, conformance suites, release-profile tests, the aac page-set
      checks, and every clippy -D warnings gate. The gates are
      standards-build's macOS meter and omni lints (jouleclaw-energy x2,
      jouleclaw-omni metal, jouleclaw-loader-gguf, jcp, proof, eoc, sandbox),
      wai-pack, wai-quantum-cli (default, no-default and metal),
      wai-quantum-service, wai-quantum-qpu and wai-quantum-desktop.
- Totals: `cargo test --workspace` ran in 43 roots: 12,532 passed, 1 failed,
  101 ignored. The other 3 roots are wasm32-only, and their
  `cargo build --release --target wasm32-unknown-unknown` passed. Every
  other CI step passed (62 of 62).
- On the final tree: scripts/check-lockfiles.sh (cargo 1.99.1) found all 47
  lockfiles current, and scripts/check-advisories.py passes.
- tokio is 1.54.1 in every lockfile cargo reads. That is patched for both
  RUSTSEC-2026-0386 (>= 1.53.3) and RUSTSEC-2026-0384 (>= 1.54.1). The 1.53.1
  in vendor/wtransport/Cargo.lock is the upstream file kept with the vendored
  source; cargo resolves wtransport inside its parents, and both gates skip
  that file.
- What is not green, each one reproduced on 1.98.0:
  - wai-ops-gpu: under the debug profile, `corpus` trips the debug_assert at
    exec.rs:187 on both toolchains. CI runs it in release only, and that
    passes (6/6).
  - wai-ops: clippy::derived_hash_with_manual_eq (deny-by-default) on both
    toolchains. No CI job runs clippy there.
  - wai-vector/wasm: `--all-targets` cannot build the lib-test target (its
    own `panic_impl`) on either toolchain. `clippy --lib` for wasm32 reports
    0 diagnostics on both.
  - eoc-cascade's hit_calibration_process_energy test reads real energy
    counters, and it fails some of the time on the loaded shared host. In
    interleaved runs each toolchain passed 18 of 20. The full eoc-rs suite
    passed on the final tree (741 passed).
- Environment, not code:
  - wai-quantum-desktop embeds the Studio's build, so wai/quantum-studio was
    built first (`npm ci`, `node build.mjs`), as CI does.
- Not covered here: the x86_64 and arm64 Linux and Windows legs; the GPU,
  NPU, FPGA, emulator and hardware-meter legs; wasm32 tests under Node,
  wasmtime and wasip2; and the fuzz job.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-03 17:42:20 -05:00

252 lines
12 KiB
YAML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

name: wai formal verification (integer core)
# The other half of the determinism contract.
#
# `wai-byte-equality` establishes byte-exactness by SAMPLING: it decodes fixed
# vectors on five real OS/arch combinations and asserts identical bytes. That
# proves the paths agree on the inputs someone thought to write down.
#
# This job REASONS instead. It runs a model checker (Kani/CBMC) over the same
# sources, for every input in a bounded window, and discharges the property the
# byte-exactness claim actually rests on: arithmetic totality. Rust integer
# overflow panics in debug and wraps in release, so an overflowing decoder is
# not one implementation but two, and which one a sink runs depends on how it
# was compiled. A decoder proved free of overflow, out-of-bounds access and
# non-termination is a decoder whose bitstream means exactly one thing.
#
# This is not redundant with the matrix: the matrix decodes WELL-FORMED vectors,
# so it cannot see defects that only a malformed or adversarial stream reaches.
# Four such defects in the bypass escape were found here and fixed, and the
# harnesses stand so they cannot come back.
#
# The proofs are bounded (small symbolic CDFs, fixed-length symbolic streams,
# explicit unwind limits). Bounded is not universal, and the job claims only
# what it checks.
#
# It also checks the integer operator set (wai/extensions/integer-operators.md):
# the harnesses of its test plan, in wai/wai-ops/src/proofs/, which the host
# includes beside the operator set's sources. They prove the roundings, the
# requantisation, a 32-bit fabric's limb product and epilogue, the soundness of
# the bound rules against the interpreter, the stage operators' totality and
# refusal order, the plans, and the graph form's parse. Each harness states its
# window. The harnesses run in shards; the first job holds the shards to
# covering every harness exactly once.
# One run per branch at a time. A push supersedes the run before it.
#
# There is one `macos` runner and it is the dev Mac, so every macOS job in this
# repo queues on it. With no concurrency group, a session pushing four versions
# of a branch queued four complete sets of runs and every one of them had to
# drain: on 2026-10-05 a PR's 21 contexts settled none in 70 minutes behind a
# backlog of 25 runs, and the queue grew faster than it cleared. Only the newest
# commit's verdict is wanted, so the older runs are cancelled.
#
# Verified on this forge (Forgejo 16.0.5) in `ci-test` before being added here:
# the key parses, and a newer push moves an older run to `cancelled` even while
# it is still queued, which is the case that matters.
#
# `cancel-in-progress: true` also applies to `main`. That is deliberate and
# safe here: main advances by merge commits whose tree contains the commits
# before them, so the newer run covers the older one's changes.
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
on:
pull_request:
paths:
- 'wai/wai-verify/**'
# The verified source itself must be able to fire this job, or a change
# can regress totality and merge green.
- 'wai/wai-rs/src/rans.rs'
- 'wai/wai-rs/src/int_entropy.rs'
- 'wai/wai-rs/src/int_transform.rs'
- 'wai/wai-rs/src/wai_video_policy.rs'
- 'wai/wai-rs/src/staged/predict.rs'
- 'wai/wai-rs/src/staged/wir1_arith.rs'
# Verified by K10 as the fast path of the reference IGDN, and #[path]-included
# because int_transform's IGDN dispatches to it, so it must also compile under
# the model checker (its cfg(kani) branches are compiled nowhere else).
- 'wai/wai-rs/src/int_kernels.rs'
# The integer operator set: its sources, which the host includes module by
# module, and its harnesses (src/proofs/).
- 'wai/wai-ops/src/**'
- '.github/workflows/wai-formal-verification.yml'
push:
branches:
- main
paths:
- 'wai/wai-verify/**'
- 'wai/wai-rs/src/rans.rs'
- 'wai/wai-rs/src/int_entropy.rs'
- 'wai/wai-rs/src/int_transform.rs'
- 'wai/wai-rs/src/wai_video_policy.rs'
- 'wai/wai-rs/src/staged/predict.rs'
- 'wai/wai-rs/src/staged/wir1_arith.rs'
- 'wai/wai-rs/src/int_kernels.rs'
- 'wai/wai-ops/src/**'
- '.github/workflows/wai-formal-verification.yml'
jobs:
# Does this pull request's own diff touch the paths below? This forge matches a
# workflow's `paths:` against the push, so a merge of main into a branch fires the
# workflow whatever the pull request changes; every job here waits on this answer.
# A push to main, a schedule, or anything the script cannot determine answers
# `true` (scripts/pr-touches-paths.py).
relevant:
name: does this change touch it
runs-on: linux
outputs:
run: ${{ steps.gate.outputs.run }}
steps:
- uses: actions/checkout@v5
with:
fetch-depth: 0
- id: gate
run: |
set -euo pipefail
r=$(python3 scripts/pr-touches-paths.py .github/workflows/wai-formal-verification.yml \
"${{ github.event.pull_request.base.sha }}" \
"${{ github.event.pull_request.head.sha }}")
echo "this change touches wai-formal-verification: $r"
echo "run=$r" >> "$GITHUB_OUTPUT"
# Every harness the host compiles runs in exactly one shard of the matrix below:
# one no shard runs would be compiled and never checked. No toolchain is needed;
# the script reads the included sources and this file.
shards:
needs: relevant
if: needs.relevant.outputs.run == 'true'
name: every harness in one shard
runs-on: linux
timeout-minutes: 10
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Every harness runs in exactly one shard
run: python3 -I wai/wai-verify/check_shards.py .
kani:
needs: relevant
if: needs.relevant.outputs.run == 'true'
name: kani (${{ matrix.shard }})
runs-on: ${{ matrix.os }}
timeout-minutes: 120
strategy:
fail-fast: false
# Each shard is a list of `--harness` filters: a harness runs when its full name
# contains one. The integer operator set's harnesses (K1–K33 of its test plan)
# are in proofs::, split so that no shard runs much past an hour; the two 512-bit
# isqrt harnesses and the longest stage harnesses have shards of their own.
# Harnesses gated by cfg(kani_open) are not compiled here.
#
# Each shard runs where its memory fits, and two of them no longer fit the
# general runners.
#
# The rans64 totality proof (k26) peaks at about 28 GiB of resident memory and
# takes about 690 s of verification (measured with /usr/bin/time -l on a 256 GB
# host). The `linux` runners have 15 GiB shared by two jobs, and CBMC ran out of
# memory there, so it was moved to `macos` -- which is a host carrying two CI
# labels, an inference server and a simulation sweep, and was measured at load
# 185 on 32 cores.
#
# `isqrt512` then began failing on `linux` the same way, but as a timeout rather
# than an allocation error: 1 h 59 m 46 s against this job's 120-minute budget. A
# model checker that runs out of time has refuted nothing and proved nothing, so
# it is the one failure mode a proof gate must not reach by accident.
#
# Both now run on `macos-proofs`: a 28-core, 96 GB Mac Studio at load ~6, with a
# runner of capacity 1 so a harness never shares the box with another. The label
# is deliberately narrow -- that host has the Command Line Tools but no full
# Xcode, Metal, node, browsers or Java, so it must not answer the general `macos`
# label, where a missing tool reads as a code failure. It has rustup, and these
# shards install their own prover.
#
# Every other shard has run to completion on the linux runners.
matrix:
include:
- { shard: integer-core, os: linux, harness: "rans:: int_entropy:: int_transform:: wai_video_policy:: staged_predict:: staged_wir1_arith::" }
- { shard: arith, os: linux, harness: "proofs::arith::k01 proofs::arith::k03 proofs::arith::k13_isqrt_u128 proofs::arith::k17 proofs::arith::k32 proofs::limb::" }
- { shard: isqrt512, os: macos-proofs, harness: "proofs::arith::k13_isqrt_i512 proofs::arith::k13_isqrt_ceil_i512" }
- { shard: stage, os: linux, harness: "proofs::stage::k23 proofs::stage::k27 proofs::stage::k28 proofs::stage::k29_residual_step_32bit_identity_registered proofs::stage::k30 proofs::stage::e11 proofs::stage::e12" }
- { shard: stage-long, os: linux, harness: "proofs::stage::k29_residual_step_32bit_identity_every_range" }
- { shard: rans64-t2, os: macos-proofs, harness: "proofs::stage::k26" }
- { shard: sound, os: linux, harness: "proofs::sound::" }
- { shard: plan, os: linux, harness: "proofs::plan::" }
steps:
- uses: actions/checkout@v4
# dtolnay/rust-toolchain cannot help — it calls `rustup`, which is absent
# on the linux runner's image. The macOS runner executes on the host, which
# has rustup in ~/.cargo/bin, but launchd's PATH omits that directory: it
# is put first, so the host's install is found and left as it is.
- name: Install rustup + toolchain
shell: bash
run: |
set -euo pipefail
export PATH="$HOME/.cargo/bin:$PATH"
if ! command -v rustup >/dev/null; then
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs \
| sh -s -- -y --profile minimal --default-toolchain 1.99.1
fi
echo "$HOME/.cargo/bin" >> "$GITHUB_PATH"
# Kani ships its own pinned nightly and a CBMC build; both are slow to
# fetch, so they are cached on the verifier version. Not on either macOS
# label: those runners execute on the host, so `~` is the host's own home,
# where Kani is installed, and a restore would write over a live install.
# The test is a prefix, not `!= 'macos'`, because `macos-proofs` is a second
# such host -- and `runner.os` is `macOS` for both, so one key would also
# have them overwriting each other's.
- name: Cache Kani toolchain
if: ${{ !startsWith(matrix.os, 'macos') }}
uses: actions/cache@v4
with:
path: |
~/.cargo/bin/kani
~/.cargo/bin/cargo-kani
~/.kani
key: kani-0.67.0-${{ runner.os }}
# The same steps on every runner: Kani 0.67.0 unless that version is installed,
# then its setup unless it is set up. Setup fetches the release bundle (CBMC and
# the driver) and installs the pinned nightly, which the bundle's `toolchain`
# links to in ~/.rustup. Run again, it fetches and installs both again, so it is
# skipped when the bundle and its toolchain are both in place: on the macOS
# host, which is set up, it would rewrite a live install. The cache holds the
# bundle but not ~/.rustup, so a container sets up every time.
- name: Install Kani
shell: bash
run: |
set -euo pipefail
export PATH="$HOME/.cargo/bin:$PATH"
if [ "$(cargo kani --version 2>/dev/null || true)" != "cargo-kani 0.67.0" ]; then
cargo install --locked kani-verifier --version 0.67.0
fi
k="$HOME/.kani/kani-0.67.0"
if [ ! -x "$k/bin/kani-driver" ] || [ ! -x "$k/bin/cbmc" ] || [ ! -e "$k/toolchain/bin/rustc" ]; then
cargo kani setup
fi
cargo kani --version
- name: Verify the shard's harnesses
working-directory: wai/wai-verify
shell: bash
run: |
set -euo pipefail
export PATH="$HOME/.cargo/bin:$PATH"
# Every harness must verify. A failing harness is a real finding
# about the decoder, so this job is allowed to be the thing that
# blocks the merge.
#
# The harnesses are in the library. The crate's one binary, the
# `wai-verify` tool, needs the `cli` feature, and a target whose
# required features are off stops `cargo kani` from building any;
# `--lib` selects the library alone.
args=()
for f in ${{ matrix.harness }}; do args+=(--harness "$f"); done
cargo kani --lib "${args[@]}"