Test oracles come from ACPI 6.5, the SDM and ToyOS's own reads; Linux is a goal in issues (#919/#915 follow-up)

[Japabu]

Problem and result

This is the follow-up the orchestrator ruled on #919 (fixtures, comment 2026-10-14T01:05) and #915 (rulings 6154972242 and 6157570149). The owner's rule (2026-10-13): a reading taken under Linux is a black-box measurement. It may sit in evidence, or in an issue as a goal or floor. It is never a test oracle in the tree. At this head the reworded exit grep of issues/the-tree-names-linux-as-an-authority.md prints nothing, so this PR closes that issue.

Items, and what each oracle is now

1. Fixtures and test oracles

File / row	Was	Oracle now
tests/metal/t14-linux/ (SOURCE, turbostat-idle.txt, turbostat-loaded.txt)	in the tree, read by counters_on_metal	removed. Byte-identical copies with their provenance are in evidence pr-929/t14-linux (sha256 listed in its README). The readings issue records them as a measurement
tests/toyos.rs counters_on_metal	busy clock held to the lowest of Linux's loaded turbostat intervals over the spin (3800 MHz); idle range printed beside Linux's	SDM Vol. 3B §22.7.2 (325462-093): MPERF counts at a fixed rate, the TSC's, and APERF at the actual clock. Every CPU's APERF/MPERF across the spin must be ≥ 1, so its busy clock is at or above the rate MPERF counts at (the TSC's, 2419.2 MHz on the T14). That is not base frequency: Intel lists 2400 MHz for that part. ToyOS's idle busy fraction and spinning clock are printed and not held
lib/acpi/tests/thinkpad_t14.rs	"held against what Linux read" (PM-Timer, INT_SRC_OVR, GPE block, buttons); cited a fixtures/thinkpad-t14/SOURCE that no longer exists	ACPI 6.5 Table 5.9 (FADT offsets 46, 48, 52, 53, 56, 64, 80, 88, 89, 92), Table 5.10 (PWR_BUTTON, flag bit 4, clear) and Tables 5.25/5.26 (override bus 0, source 9, GSI 9, flags 0x000d = active high, level). The captured bytes are the machine's and stay. The dangling citation is gone. The FADT test is renamed the_t14s_fadt_names_its_fixed_hardware_and_sci
lib/acpi/tests/resource.rs only_the_memory_ranges_of_a_root_bridge_become_windows	"the shape the T14's firmware answers in, as Linux's own journal reports it"	ACPI 6.5 §6.4.3.5.1, byte 3 Resource Type (0 memory, 1 I/O, 2 bus number). The ranges are crafted inputs, and the claim is the type rule
tests/toyos.rs acpi_events_on_metal	INT_SRC_OVR and EC 0x66/0x62 GPE 0x6e as Linux printed them	the row values decoded by ACPI 6.5 Tables 5.9, 5.10, 5.25 and 5.26 (the unit test above), and the EC at the ports and GPE the T14's ECDT names (§5.2.15). ToyOS's own T14 boot read the same values (kernel.log L283, L344, L365). The asserted strings are unchanged
tests/toyos.rs acpi_death_on_metal	lock word required in UEFI type 10, "where Linux's print of the same map puts it"	ACPI 6.5 §5.2.10: the FACS "must not be reported as system AddressRangeMemory". Table 15.6 maps UEFI types 1, 2, 3, 4 and 7 to AddressRangeMemory, and the row refuses those. Type 10 (the T14) and reserved types now pass

The expected values in thinkpad_t14.rs, resource.rs and acpi_events_on_metal are unchanged. Only their provenance changed, and I checked each value against the cited field. Two rows changed what they accept, counters_on_metal and acpi_death_on_metal, and the negative controls below cover both.

2. issues/the-tree-names-linux-as-an-authority.md: reworded, met and closed

The reworded exit lets through only Linux's madvise (sdk/libc, the interface that libc implements) and issue slugs (toyos-beats-linuxs-latency-on-the-t14). Those are the five lines the old grep still prints. At the merged head b2d75d4f8, the new grep prints nothing (git grep exit 1, log):

git grep -n -i -P "linux(?!'s \`madvise\`|s?-)" -- kernel sdk/libc/src lib/acpi lib/hda lib/xhci \
  lib/bcachefs system/fileserver system/logkeeper system/netstack/i219 system/netstack/shard \
  system/netstack/node/tests tests/metal tests/toyos.rs tests/guest

The file is deleted (f8acc182d). No file cites its slug or path. Its rule already lives in root CLAUDE.md and reviewer.md, so nothing needed folding.

3. The four Linux-oracle security issues

The four are each-boot-prints-the-vulnerabilities-lines-linux-prints.md (Linux's lines), spec-ctrl-and-gds-stay-as-firmware-left-them.md (Linux's reads), tsx-stays-as-firmware-left-it.md (Linux's reads) and no-entry-or-switch-clears-the-bhb-fills-the-rsb-or-issues-an-ibpb.md (Linux's sequences). These are the four children of the security track that are neither the vendor-guidance function nor among the nineteen floors. Each one's exit and oracle now name the vendor's guidance, through a-pure-function-decides-…-from-its-vendors-guidance.md, together with ToyOS's own reads. Linux's lines, reads and sequences become a goal compared in evidence, never a test's expected value. In each-boot-prints-…, the T14's logged words must also equal the T14's words that the pure-function issue commits with provenance. Without that clause, a read of ARCH_CAPABILITIES as 0 would pass, because the line would state the function's verdict on 0. Nothing else in those files changed. Their slugs, descriptions and mutations are as they were.

4. issues/README.md

#913's review S1 raised a conflict: the README said a track "does not carry a design, a stage table…", yet the crypto, SSH and Wi-Fi tracks carry stages at their briefs' request. The rule is replaced, not given an exception. A staged track now lists its stages in order, each with what it builds, the design decisions its brief settled and its exit. A track still carries no rationale or review history. The replacement also drops "written to the length a defect is". The staged tracks run to hundreds of lines (Wi-Fi is 404), so that sentence conflicted with the same tracks.

Pointers that followed

• linuxs-readings-of-the-t14-…: the turbostat section is now a measurement linked to the evidence, and Linux's 3800 MHz stays there as a goal. Its exit is every Linux reading another issue owes before the wipe, published in evidence.
• toyos-explains-itself.md (orchestrator's addition): the exit no longer holds each T14 counter against Linux's reading. A row now holds each counter to the bound Intel's SDM gives it, where it gives one, as counters_on_metal holds the busy clock to the rate MPERF counts at. Linux's reading is a goal compared in evidence. Nothing else in that file changed.
• suite-rows-that-are-measurements-…: "a turbostat frequency floor" becomes "a floor at the rate MPERF counts at".
• no-program-measures-toyos-against-linux-on-one-machine.md (orchestrator's addition): the exit no longer commits the outputs as fixtures with "Oracle: Linux". Both runs' outputs go to evidence. Linux's are a goal ToyOS's are compared against, never a fixture a test reads. The pair-check function's oracle is its own rule over the x2APIC IDs it is handed.
• the-tree-says-who-uses-each-thing.md: two mentions of t14-linux/.

Checks

The head is 572b6c982. The merge is b2d75d4f8: f8acc182d merged with origin/main at e136c77fd. Host: macOS arm64.

• cargo run -- --ci host at 51414738d (review round 1): exit 0, 86 steps green (log). The head 572b6c982 changes two issue sentences on top of it. Re-judging counters offline on toyos-cpuvuln leaves the tree; what the kernel read of it stands on Intel's and AMD's documents #915's T14 readback with the reworded judge gives PASS counters (log).
• cargo run -- --ci host at b2d75d4f8: exit 0, 86 steps green (log). The earlier run at 446b912bd was also green and is superseded.
• Exit grep before the merge (log): exit 1 (no match) at HEAD. At origin/main the same grep prints the 22 hits this PR removes. The old grep at HEAD prints only the five allowed lines.
• Negative controls (script, log) ran at 07c881cac. Each patch was checked, applied, run and reverted in one run. Later commits change issue files only, and the merge brings no change to counters_on_metal, acpi_death_on_metal or lib/acpi/tests, so the controls stand.
  • counters_on_metal re-judged offline on the T14 head readback recorded for toyos-cpuvuln leaves the tree; what the kernel read of it stands on Intel's and AMD's documents #915 (--metal --metal-readback <dir> counters with both boots' readbacks present, so no image was built and no machine was touched). It gives PASS counters: every CPU spins at 3830 MHz, APERF/MPERF 1.583 (log). With the bound mutated to 1.6 (patch), above the recorded 1.583, it gives FAIL counters (log). Both runs exit 1 overall for a reason outside this row: this host holds no timing record for the machine, so the run's timing judgment is red. The row verdicts are the lines quoted.
  • acpi_death_on_metal's FACS rule was probed through a throwaway host test on planted readbacks (patch, log), exit 0. Types 1, 4 and 7 are refused as AddressRangeMemory. Types 10 and 0 pass the FACS step and stop at the next missing line. The old judge accepted only type 10, so a reserved-type FACS that §5.2.10 permits was refused before.
• No guest and no metal run. The changed judges were exercised offline, and every other row change is a comment.

Decisions taken (orchestrator, after the first draft)

• The counters floor is the rate MPERF counts at, the TSC's (2419.2 MHz on the T14). A higher bound would be a measurement, not a derivation. Linux's 3800 MHz stays a goal in evidence.
• no-kernel-address-is-drawn-per-boot.md and no-user-address-is-drawn-per-spawn.md keep "Oracle: Linux's bits". They are among the nineteen kept floors.

🤖 Generated with Claude Code

https://claude.ai/code/session_016UzbDnM9m6nQWhbjGi6Lv1

[Japabu]

Review of #929 at b2d75d4f8

Architecture

The direction is right, and the change is small: +98/−273, no production code, and test code shrinks. The test judges stop reading Linux's turbostat files. The ACPI unit tests keep the machine's captured bytes and now cite ACPI 6.5 for what those bytes mean. Linux's readings move to evidence as a goal, and the issue that tracked Linux citations closes now that its grep is clean. Nothing gains an owner or a mechanism. Two of the rewritten oracle statements are not quite true as written. Both fixes are small.

Verified

• ACPI values. lib/acpi/tests/thinkpad_t14.rs checked against ACPI 6.5 Table 5.9 offsets: SCI_INT@46=9, SMI_CMD@48=0xb2, ACPI_ENABLE/ACPI_DISABLE@52/53=0xf0/0xf1, PM1a_EVT_BLK@56=0x1800, PM1a_CNT_BLK@64=0x1804, GPE0_BLK@80=0x1860, PM1_EVT_LEN/PM1_CNT_LEN@88/89=4/2, GPE0_BLK_LEN@92=32.

  • Flags@112 = 0x0020c4e5: bit 4 (PWR_BUTTON) is clear, so the fixed-feature button applies (Table 5.10).
  • The second interrupt source override is bus 0, source 9, GSI 9, flags 0x000d. Bits 1:0 = 01 (active high) and bits 3:2 = 11 (level), per Tables 5.25/5.26.
  • In resource.rs, the QWord descriptor's byte 3 encodes 0 memory, 1 I/O, 2 bus (§6.4.3.5.1), which matches common::{MEMORY, IO, BUS}.
  • acpi_events_on_metal asserts the same strings as before. The EC ports and GPE come from the ECDT, which system/acpiserver/src/aml.rs attaches, so the oracle statement is true.

• acpi_death_on_metal. ACPI 6.5 §5.2.10 forbids reporting the FACS as AddressRangeMemory; it does not require NVS. Table 15.6 maps UEFI types 1, 2, 3, 4 and 7 to AddressRangeMemory. The judge refuses those five types, and it refuses a line with no parseable type. The kernel only logs this line after lib/userbound/src/firmware.rs:341 lock_word has accepted type 0 or 10, so the judge is a fence against a kernel regression. The planted-type probe (ctl-facs-probe.log) is a real control: 1, 4 and 7 are refused; 10 and 0 pass on to the next line.

• Moved turbostat files. All three are byte-identical to the evidence copies: the blob ids at origin/main (d59763d1e, 298df6085, df181dbee) equal the evidence tree's blob ids, and the sha256 sums equal the evidence README's. They contain no hostname, serial, MAC or BIOS string; the only labels are the Ubuntu kernel version and the date.

• Greps. The PR's exit grep prints nothing (exit 1). Every hit of git grep -n -i linux -- tests lib kernel build is one of:

  • a host platform (build/flash.rs, tether.rs, userlandhost.rs, release.rs, tests/common/clock.rs);
  • an externally defined interface (lib/gpt LINUX_FS GUID, linux/fs.h ioctl, sdk/libc madvise);
  • the pinned TinyCC corpus;
  • a goal-issue slug.

  No test or fixture takes an expected value from Linux. Deleting the-tree-names-linux-as-an-authority.md is justified; nothing cites its slug.

• Issue edits stay in scope. The four security issues and toyos-explains-itself.md change only in their exit and oracle sentences. In issues/README.md the conflicting rule is replaced, not given an exception.

• Counters control. The re-judge on toyos-cpuvuln leaves the tree; what the kernel read of it stands on Intel's and AMD's documents #915's T14 readback gives PASS at bound 1.0 and FAIL at 1.6, against a recorded 1.583.

• Host checks. Per the reviewer role, I ran no build. ci-host-r2.log is stamped at b2d75d4f8…, ends 86 step(s), all green / EXIT 0, and is at this exact head.

Findings

BLOCKER 1 — tests/toyos.rs:5063-5068, :5223, PR body "Decisions taken"

• What: The row says APERF/MPERF ≥ 1 means "at or above its base frequency". The body says "the SDM's base frequency (2419 MHz on the T14)". The paragraph gives MPERF two rates two lines apart: "MPERF counts at the TSC's rate" (5063), then "close to the maximum non-turbo frequency" (5066).

• Why it matters: The bound the code applies is the MPERF/TSC rate, 2419 MHz. That is not base frequency. The T14's i5-1135G7 (NOTICE:499) has a 38.4 MHz crystal × 63 TSC, 2419.2 MHz. Intel lists its base (cTDP-up) as 2.40 GHz, max non-turbo ratio 24.

• Failure scenario: A CPU held exactly at its guaranteed 2400 MHz reads 0.992 and fails. The message then claims it was "below its base frequency", which is false.

• Status of the claim: The bound itself (≥ the MPERF rate during a short spin under turbo) is a fine floor. Only the claim about it is wrong.

• Fix, either of:

  • say what is held: the busy clock at or above the rate MPERF counts at (the TSC's, about the nominal frequency); or
  • hold the ratio to the max non-turbo ratio × 100 MHz / TSC if the readback carries MSR_PLATFORM_INFO.

  Correct the body's "2419 MHz base" either way. No rerun is needed for a wording fix.

BLOCKER 2 — issues/each-boot-prints-the-vulnerabilities-lines-linux-prints.md:12-18

• What: The re-scoped exit holds each line to "what [the pure function] decided for that CPU from the words ToyOS read there". The oracle is "ToyOS's own reads". The mutation it keeps is "ARCH_CAPABILITIES read as 0 reds the T14".
• Failure scenario: With the read mutated to 0, ToyOS's own read is 0. The function decides from 0, and the line states that decision, so a row built exactly to this exit stays green. Before this PR the mutation reached because Linux's line was the fixed expectation. The re-scope dropped what made it reach.
• Fix: One clause. The T14's line is held to the function's verdict on the T14's words committed with provenance by a-pure-function-decides-… (its exit already commits each proving machine's words). Alternatively, the logged words must equal those committed words.

SUGGESTION 1 — issues/README.md:65. The replacement also drops "it is written to the length a defect is". The body does not mention that. Either restore it (it does not conflict with listing stages) or say in the body that it was removed and why.

SUGGESTION 2 — issues/toyos-explains-itself.md:82. "holds each counter … to the bound Intel's SDM gives it" cannot be met for counters the SDM gives no bound for, such as SMI count, package energy and temperatures. Add "where it gives one" so the exit stays checkable.

SUGGESTION 3 — tests/toyos.rs:5209. above_base holds APERF/MPERF ratios, including the ones below 1 that the row refuses. aperf_per_mperf says what it is.

SUGGESTION 4 — tests/toyos.rs:5064,5067. One paragraph cites the same SDM topic once by title and once as "§22.7.2". SDM section numbers move between revisions, and I could not check §22.7.2 offline. Use one citation and pin the revision, as kernel/src/arch/x86_64/control_regs.rs:282 does ("253669-093US").

SUGGESTION 5 — issues/linuxs-readings-…-wipe.md:16. "Every reading another issue owes" can be checked only by searching all issues. Name the issues it means; today that appears to be no-program-measures-toyos-against-linux-on-one-machine.md.

Note for the orchestrator, outside this PR's scope: issues/no-program-measures-toyos-against-linux-on-one-machine.md:21-23 still plans "the outputs committed as fixtures … Oracle: Linux". That conflicts with the rule this PR enforces, and it would reopen what the deleted issue closed. It is not one of the four security issues, so I have not blocked on it.

Verdict

SEND BACK. Both blockers are wording fixes to an oracle statement, and neither needs another metal or guest run.