Adds a non-blocking `miri` job to audit.yml, per rust-safety-programme.md §7.
What it buys is one narrow, real thing: pf-driver-proto interpreted CROSS-COMPILED to
x86_64-pc-windows-msvc, on a Linux runner, with no Windows box in the loop. That crate is
`#![forbid(unsafe_code)]` and path-dep'd by BOTH the main workspace and the driver
workspace, so it is the layout oracle for every frame and IOCTL crossing that boundary,
and nothing else in CI checks it at MSVC layout. It is NOT unsafe coverage — Miri can
execute on the order of 2% of the host's unsafe and cannot run ash, windows-rs, ffmpeg,
CUDA or the WDK — so no "Miri coverage" number is reported anywhere.
Three steps, every one of them measured on 192.168.1.25 with a cold target dir and cold
sysroot cache, on the dated toolchain the job installs, BEFORE being committed:
step A pf-driver-proto + pf-host-config + pf-gpu 21 + 12 + 4 pass 43 s
step B pf-driver-proto @ x86_64-pc-windows-msvc 21 pass 26 s
step C punktfunk-core fec::gf8 with +avx2,+ssse3 2 pass 63 s
Four corrections to the §7.3 job spec, found while doing this and folded into comments:
* `-p punktfunk-core fec packet crypto` does not parse — cargo rejects the extra
positionals. Corrected (filters after `--`) it selects 63 tests and was killed at a
25-minute cap with not one test complete, so the bulk step is dropped entirely and only
the narrow `fec::gf8` selection is kept, timed at 63 s.
* `nightly-2026-08-10` resolves to rustc 1.99.0-nightly (969b803cb 2026-08-09), NOT the
12c36e253 2026-08-10 the doc cites: `nightly-<date>` names the day rustup PUBLISHED the
build, which is compiled from the previous day's commit. The doc's hash came from the
ROLLING `nightly` channel and was mislabelled. All three steps were re-run and are green
on the dated pin actually installed here.
* fec-rs dispatches its GF(2^8) multiply through RUNTIME `is_x86_feature_detected!`, so
step C's RUSTFLAGS are load-bearing in both directions. Verified by probe: bare,
avx2=false and the step would silently interpret the scalar fallback; with the flags,
avx2=true and `_mm256_shuffle_epi8` genuinely executes under the interpreter. GFNI stays
false either way, so that branch is simply not covered.
* `RUSTC_WRAPPER: ""` is a guard, not a fix, and the comment says so — audit.yml sets no
sccache today, and cargo-miri warns "Ignoring `RUSTC_WRAPPER`, Miri does not support
wrapping" and carries on regardless.
Non-blocking via a step-level `||`, not job-level continue-on-error, following the
precedent audit.yml already documents for docs-site-audit. Each step additionally asserts
a non-zero pass count, so a crate rename or a filter that stops matching surfaces as a
warning rather than as a green zero-test run. Both paths were exercised directly: a
failing run emits the annotation and still exits 0, and a zero-selection run trips the
guard, while a green run with empty bin/doctest targets does not false-positive.
Leak checking stays ON (no -Zmiri-ignore-leaks); the two deliberate leaks in the tree are
named in a comment so whoever expands coverage annotates those sites instead of blanket-
disabling the check. pf-bitstream and the FFI crates are excluded with the reasons inline
so they are not helpfully re-added. `paths:` is deliberately not widened to
crates/pf-driver-proto/** — that filter is workflow-level and would fire all six audit
jobs on every driver-proto edit.
enricobuehler