Miri interprets the FFI-free leaf crates, one of them at MSVC layout #169

Merged

enricobuehler merged 2 commits from worktree-miri-ci into main 2026-08-11 21:57:25 +00:00

Conversation 0 Commits 2 Files Changed 1

+187

enricobuehler commented 2026-08-11 21:17:31 +00:00

Owner

Copy Link

Copy Source

Adds a non-blocking miri job to .gitea/workflows/audit.yml, per §7 of the rust-safety programme. One commit, one file.

What this buys — one narrow, real thing

It interprets pf-driver-proto 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 is 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 drift there is silent corruption, not a compile error. Nothing else in CI checks it at MSVC layout.

What it does not buy

This is not unsafe coverage and must never be reported as such. Miri can execute on the order of 2% of the host's unsafe; it cannot run ash, windows-rs, ffmpeg, CUDA or the WDK, and in those crates the unsafe is the foreign call. No "Miri coverage" number is published anywhere in the job.

Verification — run 17447, conclusion success

Real counts, read out of the log rather than inferred from a green tick:

step	result
leaf crates, native (pf-driver-proto + pf-host-config + pf-gpu)	21 + 12 + 4 passed
pf-driver-proto @ x86_64-pc-windows-msvc	21 passed
punktfunk-core -- fec::gf8 with +avx2,+ssse3	2 passed

Zero FAILED, no annotation fired, 5.5 min wall clock against a 30-min timeout. The other seven audit jobs were unaffected.

Every step was also measured on 192.168.1.25 with a cold target dir and cold sysroot cache before being committed — 43 s / 26 s / 63 s, 132 s total. Nothing in the job's comments is extrapolated.

Corrections to the §7.3 spec, found by running it

• The bulk punktfunk-core step is dropped. The doc's -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. Only the narrow fec::gf8 selection survives, and it was timed first.
• nightly-2026-08-10 is not the compiler the doc cites. It resolves to rustc 1.99.0-nightly (969b803cb 2026-08-09), not 12c36e253 2026-08-10: 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. All three steps were re-run green on the dated pin the job actually installs, and the CI log confirms it.
• Step C's RUSTFLAGS are load-bearing in both directions. fec-rs dispatches through runtime is_x86_feature_detected!, which Miri answers from compile-time target features. Probed: bare → avx2=false, so the step would silently interpret the scalar fallback; with the flags → avx2=true and _mm256_shuffle_epi8 genuinely executes under the interpreter. GFNI is false either way, so that branch is explicitly not covered.
• RUSTC_WRAPPER: "" is a guard, not a fix, and the comment now says so — audit.yml sets no sccache today, and cargo-miri warns Ignoring RUSTC_WRAPPER, Miri does not support wrapping and carries on regardless.

Design notes

• 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 instead of a green zero-test run. Both paths were exercised directly.
• 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 rather than disabling the check.
• pf-bitstream and the FFI crates are excluded with 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 other audit jobs on every driver-proto edit.

Known follow-up, not addressed here

act_runner runs run: steps as sh -e {0}, not bash. set -o pipefail is accepted by this image's /bin/sh (verified in the run above), but that is an implicit dependency: if it ever regressed, cargo … | tee … || ok=0 would read tee's status and a failing pf-driver-proto beside a passing pf-host-config would still satisfy the guard — a false green on step A. Adding shell: bash to the three steps removes the dependency; left out here so the merged file is byte-identical to the one verified green.

Do not flip this to blocking on day one — wait until several weeks of green establish the nightly-drift rate.

Adds a **non-blocking** `miri` job to `.gitea/workflows/audit.yml`, per §7 of the rust-safety programme. One commit, one file. ## What this buys — one narrow, real thing It interprets `pf-driver-proto` **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 is 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 drift there is silent corruption, not a compile error. Nothing else in CI checks it at MSVC layout. ## What it does not buy This is **not unsafe coverage** and must never be reported as such. Miri can execute on the order of 2% of the host's unsafe; it cannot run `ash`, `windows-rs`, `ffmpeg`, CUDA or the WDK, and in those crates the unsafe *is* the foreign call. No "Miri coverage" number is published anywhere in the job. ## Verification — run [17447](https://git.unom.io/unom/punktfunk/actions/runs/17447), conclusion `success` Real counts, read out of the log rather than inferred from a green tick: | step | result | |---|---| | leaf crates, native (`pf-driver-proto` + `pf-host-config` + `pf-gpu`) | **21 + 12 + 4 passed** | | `pf-driver-proto` @ `x86_64-pc-windows-msvc` | **21 passed** | | `punktfunk-core -- fec::gf8` with `+avx2,+ssse3` | **2 passed** | Zero FAILED, no annotation fired, **5.5 min** wall clock against a 30-min timeout. The other seven audit jobs were unaffected. Every step was also measured on `192.168.1.25` with a cold target dir and cold sysroot cache **before** being committed — 43 s / 26 s / 63 s, 132 s total. Nothing in the job's comments is extrapolated. ## Corrections to the §7.3 spec, found by running it - **The bulk `punktfunk-core` step is dropped.** The doc's `-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. Only the narrow `fec::gf8` selection survives, and it was timed first. - **`nightly-2026-08-10` is not the compiler the doc cites.** It resolves to `rustc 1.99.0-nightly (969b803cb 2026-08-09)`, not `12c36e253 2026-08-10`: `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. All three steps were re-run green on the dated pin the job actually installs, and the CI log confirms it. - **Step C's `RUSTFLAGS` are load-bearing in both directions.** `fec-rs` dispatches through *runtime* `is_x86_feature_detected!`, which Miri answers from compile-time target features. Probed: bare → `avx2=false`, so the step would silently interpret the scalar fallback; with the flags → `avx2=true` and `_mm256_shuffle_epi8` genuinely executes under the interpreter. GFNI is false either way, so that branch is explicitly not covered. - **`RUSTC_WRAPPER: ""` is a guard, not a fix**, and the comment now says so — `audit.yml` sets no sccache today, and `cargo-miri` warns `Ignoring RUSTC_WRAPPER, Miri does not support wrapping` and carries on regardless. ## Design notes - **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 instead of a green zero-test run. Both paths were exercised directly. - **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 rather than disabling the check. - `pf-bitstream` and the FFI crates are excluded with 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 other audit jobs on every driver-proto edit. ## Known follow-up, not addressed here act_runner runs `run:` steps as **`sh -e {0}`, not bash**. `set -o pipefail` is accepted by this image's `/bin/sh` (verified in the run above), but that is an implicit dependency: if it ever regressed, `cargo … | tee … || ok=0` would read *tee's* status and a failing `pf-driver-proto` beside a passing `pf-host-config` would still satisfy the guard — a false green on step A. Adding `shell: bash` to the three steps removes the dependency; left out here so the merged file is byte-identical to the one verified green. Do not flip this to blocking on day one — wait until several weeks of green establish the nightly-drift rate.

enricobuehler added 1 commit 2026-08-11 21:17:32 +00:00

ci(audit): interpret the FFI-free leaf crates under Miri, one at MSVC layout ... 6e4638dab5

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 added 1 commit 2026-08-11 21:57:18 +00:00

Merge branch 'main' into worktree-miri-ci 3ea411fa39

enricobuehler scheduled this pull request to auto merge when all checks succeed 2026-08-11 21:57:24 +00:00

enricobuehler merged commit bbd26ea82c into main 2026-08-11 21:57:25 +00:00

enricobuehler deleted branch worktree-miri-ci 2026-08-11 21:57:31 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#169