| Filename | Latest commit message | Latest commit date |
|---|---|---|
The meters sampled the processor power a non-privileged reader reports and
sealed it OnChipCounter, but they never read the channel it comes from: on
macOS 27 the processor channels of IOReport's Energy Model group read zero for
an unprivileged reader, and the reader takes its power from another report it
selects. The liveness rule (energy-measurement §3.1) passed on the reported
samples, which move, while no counter was ever put to it.
energy_burst::PowerSource says what a reader's samples are. A Counter's
differences can seal OnChipCounter under §3.1, §4 and §2.3; a Reported power
is refused as OnChipCounter whatever its brackets show (Bracket::on_chip_figure,
on_chip_refusal) and seals ModelBased under the same bracket rules
(Bracket::figure). wai_meter, wai_video_meter, wai_world_meter,
wai_quantum_meter, wai_prov and wai_stage_measure --energy macmon now seal
ModelBased, naming the reader as the method; rapl:<domain> stays a counter.
energy-measurement §3.1 (the test is run on the counter), §2.9 and §7 say so,
and the extensions that described the meters' figures as on-chip readings are
corrected. No committed record changes class: the provenance vector's figures
are unlabelled and keep their bytes.
Also: the relay's powercap tests module after its impl, and platform-decode's
test helper uses is_multiple_of.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit
|
||
| .. | ||
| captured.jpeg.wai | ||
| captured.receipt.json | ||
| README.md | ||
A provenance vector for the reach conformance runs
captured.jpeg.wai is a wai.image.jpeg envelope and captured.receipt.json its signed
asset-provenance receipt (wai::provenance::AssetReceipt): three steps
(origin.synthesize, encode.png, encode.jpeg), a Merkle root over them, the total
joules, and an Ed25519 signature. Its pixels are a synthesized pattern (rings and a
gradient), not a photograph.
Provenance. Both files are written by wai_prov (wai-rs/src/bin/wai_prov.rs), which
synthesizes the pixels, encodes them to PNG and then to JPEG, wraps the JPEG and signs the
lineage. The key is the tool's published test seed, the byte 0x70 repeated 32 times
(public key 19204c8c…ef067791), and the signer_id is the tool's label,
did:example:wai-prov: a key whose seed is published attests nothing, so its id names no
origin (jwp-receipts §7.1, §7.8). The figures, 426844 µJ for encode.png and 140425 µJ
for encode.jpeg (unlabelled; origin.synthesize is unmetered), are the ones wai_prov
bracketed when it first wrote this asset, at an earlier revision that signed under an
origin-bound id. Its samples were the processor power a non-privileged reader reports, not
a counter it read and showed live, so the figures are ModelBased at best
(energy-measurement §3.1); being unlabelled, the receipt states no class. --carry carries them onto the same bytes
and signs them again under the label; nothing is measured again. wai_prov carries a
figure only from a receipt that verifies and whose steps have this run's operations, input
and output hashes and work.
To regenerate, from wai/wai-rs (the codecs feature links the system codec libraries):
cargo run --release --no-default-features --features provenance,codecs,receipt_claims --bin wai_prov -- \
../wai-web/reach/test/vectors/provenance \
--carry ../wai-web/reach/test/vectors/provenance/captured.receipt.json
The receipt is carried onto itself, so the command writes both files again byte for byte;
on a host whose synthesis or encoders give other bytes, the lineage differs and the
command refuses. Without --carry, wai_prov brackets each encode afresh (a usable
figure is labelled ModelBased), and the receipt and its hash below change.
The receipt profile of the reach builds exists to check receipts like this one, so the
conformance runs (../../conformance.js) verify it on every rung: the content hash and
the signature must verify, a copy with one bit changed must fail the content check, and
a copy with its joule total raised by one must fail the signature check. The receipt's
hash, signer id, step count and joule total must read as the receipt states them; the
total crosses the JavaScript boundary as a 64-bit integer, a BigInt where the engine has
one and a Number where it does not.
| file | SHA-256 |
|---|---|
captured.jpeg.wai |
4382082d2bbd1ef5358315afd578fc533d74bf973a57d4c45033c89c847a22a3 |
captured.receipt.json |
97c5c24a03eae1c6a2d0e5374ad13c5ca00de00d696f40116f41c66b7097ff64 |