xenia-rs/audit-runs/audit-068-host-mem-watch/writer-report-v3.md

AUDIT-068 Session 3 — read-mode probe writer report

Date: 2026-05-20

Summary

Session 3 adds a read-mode probe to the AUDIT-068 instrumentation. Instead of hooking host-side write surfaces (Session 1+2's approach, which produced 0 hits across ~9 surfaces despite the install being real), the probe spawns a dedicated low-priority polling thread that samples configured guest VAs every PERIOD_NS and emits AUDIT-068-READ-CHANGE events on transition.

The probe bounded the install epoch for the ANON_Class_713383D7 vptr to host_ns ≈ 9.412–9.612 s (varies ±200 ms between cold runs) and provided the first direct evidence that the install is a bulk POD struct copy of a 12-byte {vptr, self_ptr, self_ptr} record into the instance's first three u32 slots — written simultaneously within the same 1 ms poll interval. Reading-error class #36 (POD-struct copy-assignment bypass) is now confirmed in the strongest possible terms: Run 10 enabled BOTH the read probe AND the full ~9-surface host-write watch simultaneously with the CORRECT target value 0x8200A1E8, and observed the read probe catch the install while host-write surfaces produced 0 hits.

A secondary finding overturns part of the AUDIT-067 framing: the actual vptr value installed is 0x8200A1E8, not 0x8200A208. The number 0x8200A208 is the address of the slot-1 fn pointer WITHIN the vtable (32 bytes into the vtable). The value stored at [ctx_ptr] is the vtable BASE = 0x8200A1E8. AUDIT-067 hooked all 16 PPC store opcodes for 0x8200A208 — it should have also (or instead) watched 0x8200A1E8. This may explain part of why AUDIT-067 also produced 0 hits.

LOC added (Session 3 delta, canary only)

File	LOC delta	Purpose
src/xenia/cpu/cpu_flags.h	+7	New cvar audit_68_host_mem_read_probe declaration.
src/xenia/cpu/cpu_flags.cc	+6	Cvar definition.
src/xenia/memory.cc	+18	Register g_guest_to_host_thunk (wraps Memory::TranslateVirtual) and g_query_protect_thunk (wraps LookupHeap+QueryProtect) inside Memory::Memory(); reset to nullptr in ~Memory().
src/xenia/base/audit_68_host_mem_watch_fwd.h	+17	GuestToHostThunk + QueryProtectThunk extern decls.
src/xenia/base/audit_68_host_mem_watch_base.cc	+~170	ReadProbe struct + parser (VA:SIZE:PERIOD_NS CSV form) + sample_at() w/ page-protect guard + read_probe_thread_main() polling loop + start_read_probe_thread_if_configured() lazy-start (called from check_host_write_slowpath).
Total	~218 LOC additive	All cvar-gated default-off (empty CSV = thread never spawned).

Cumulative across Sessions 1+2+3: ~520 LOC.

xenia-rs HEAD e6d43a23ac393004d2e5adf2f0395fd0b5e6448b UNCHANGED.

Cvar format

--audit_68_host_mem_read_probe=VA1:SIZE1:PERIOD1,VA2:SIZE2:PERIOD2,...

Each tuple is VA:SIZE:PERIOD_NS. SIZE ∈ {1, 2, 4, 8}. PERIOD_NS floored at 1 us (1000). Max 8 tuples. Default empty (off).

Lazy-start: the poll thread spawns only on the first call to check_host_write_slowpath() after Memory::Memory() has registered the thunks. This reuses the Session 2 static-init gate. The thread is detached (daemon-style) and polls until process exit.

Captures

All runs cold-boot (cache wipe before each), --mute=true, against the Sylpheed ISO. 90 s wallclock each.

Run 6 — primary read-probe on 0xBCE25340

Cmdline: --audit_68_host_mem_read_probe=0xBCE25340:4:1000000 --mute=true.

Observations:

host_ns=729615200    INITIAL  0x00000000
host_ns=738072700    CHANGE   0x00000000 → 0xBCE254C0   (arena-local pointer)
host_ns=1537758000   CHANGE   0xBCE254C0 → 0xBCE25640
host_ns=1591760600   CHANGE   0xBCE25640 → 0xBCE25350
host_ns=1592827100   CHANGE   0xBCE25350 → 0xBCE257C0
host_ns=1601443500   CHANGE   0xBCE257C0 → 0x82061050   (looks like XEX vtable)
host_ns=1602506700   CHANGE   0x82061050 → 0x820610E0   (final, stable through 90 s)

Boot reached worker spawn (thid=27/28/29 visible in log tail) — so the probe was alive for the whole 90 s wallclock; only ~7 changes occurred at 0xBCE25340 in this run, and the value never became 0x8200A208.

This indicated the address 0xBCE25340 cited in AUDIT-058/067 is NOT deterministic across runs — there's "arena drift" in the 0xBCE25xxx region. The Phase-NonMatch investigation memo (2026-05-19) already documented this: canary cold sample saw ctx_ptr=0xBCE251C0 while AUDIT-058 saw 0xBCE25340.

Run 7 — neighbor bisect on 0xBCE25340 ± 4/8

Cmdline: --audit_68_host_mem_read_probe=0xBCE2533C:4:1000000,0xBCE25340:4:1000000,0xBCE25344:4:1000000,0xBCE25348:4:1000000.

host_ns=655976500   INITIAL  all four = 0
host_ns=664462100   CHANGE   0xBCE25340: 0 → 0xBCE254C0
host_ns=1374604200  CHANGE   0xBCE25340: 0xBCE254C0 → 0x07C65ADA   (3 SIMULTANEOUS)
host_ns=1374604200  CHANGE   0xBCE25344:          0 → 0x001EE000
host_ns=1374604200  CHANGE   0xBCE25348:          0 → 0x0003A313

Key signal: at host_ns=1.374 s, three adjacent u32 slots changed within the same 1 ms poll interval but the neighbor at 0xBCE2533C did NOT. This is a clear bulk struct-copy / memcpy footprint — the writer wrote a 12-byte record starting at 0xBCE25340. The three values {0x07C65ADA, 0x001EE000, 0x0003A313} are NOT the vtable (don't match 0x8200A208/0x8200A1E8); they look like random-looking data (FNV-style hash, allocation size, refcount?). This particular write happens to a DIFFERENT object instance reusing the 0xBCE25340 slot, not the ANON_Class instance.

Run 8 — locate the actual ctx_ptr via AUDIT-061 fire

Cmdline: --audit_61_branch_probe_pcs=0x825070F0 --audit_68_host_mem_read_probe=0xBCE25340:4:1000000.

AUDIT-061-BR pc=825070F0 ... r3=BCE251C0 ... fired late in the run. So in THIS cold trajectory the ANON_Class instance is at 0xBCE251C0, not 0xBCE25340. The probe at 0xBCE25340 was watching the wrong address.

Run 9 — neighbor bisect on the correct ctx_ptr 0xBCE251C0

Cmdline: --audit_61_branch_probe_pcs=0x825070F0 --audit_68_host_mem_read_probe=0xBCE251BC:4:1000000,0xBCE251C0:4:1000000,0xBCE251C4:4:1000000,0xBCE251C8:4:1000000.

host_ns=633560300   INITIAL  all four = 0
host_ns=642041900   CHANGE   0xBCE251C0: 0 → 0xBCE25340           (arena ptr)
host_ns=1387443500  CHANGE   0xBCE251C0: 0xBCE25340 → 0xBCE254C0  (2 SIMULTANEOUS)
host_ns=1387443500  CHANGE   0xBCE251C8:          0 → 0x00000148
host_ns=1412116800  CHANGE   0xBCE251C0: 0xBCE254C0 → 0           (2 SIMULTANEOUS clear)
host_ns=1412116800  CHANGE   0xBCE251C8: 0x148 → 0
host_ns=1457544600  CHANGE   0xBCE251C0:        0 → 0xBF80199A    (2 SIMULTANEOUS — floats)
host_ns=1457544600  CHANGE   0xBCE251C4:        0 → 0x3F802D83    (= -1.0008, 1.0014)
host_ns=5710239000  CHANGE   0xBCE251C0: 0xBF80199A → 0xBCE25640  (arena ptr)
host_ns=9416025400  CHANGE   0xBCE251C0: 0xBCE25640 → 0x8200A1E8  (3 SIMULTANEOUS — THE INSTALL)
host_ns=9416025400  CHANGE   0xBCE251C4: 0xBCE251C0 → 0xBCE251C0  (self-ptr)
host_ns=9416025400  CHANGE   0xBCE251C8:          0 → 0xBCE251C0  (self-ptr)
AUDIT-061-BR pc=825070F0 r3=BCE251C0 (fire ~25 s wallclock)

The install epoch is host_ns = 9.416025400 s. Three slots written simultaneously to {vptr=0x8200A1E8, self=0xBCE251C0, self=0xBCE251C0} — classic struct construction or *ptr = X_FOO{...} POD copy pattern. The slot at 0xBCE251BC (4 bytes before ctx_ptr) did NOT change, bounding the write to exactly 12 bytes starting at 0xBCE251C0.

The install is ~966 ms BEFORE the sub_825070F0 fire (~10.4 s host_ns, matches Phase-NonMatch documented thread.create burst at 10.382 s) and well within the 60-90 s capture window.

Run 10 — cross-validation: read-probe + host-write watch with correct value

Cmdline: --audit_68_host_mem_watch_values=0x8200A1E8,0x8200A208,0xE8A10082,0x82A10082 --audit_68_host_mem_watch_addrs=0xBCE251C0 --audit_68_host_mem_read_probe=0xBCE251C0:4:1000000 --audit_61_branch_probe_pcs=0x825070F0.

host_ns=9612147300  CHANGE   0xBCE251C0: 0xBCE25640 → 0x8200A1E8   (read probe catches)
AUDIT-061-BR pc=825070F0 r3=BCE251C0                                (sub_825070F0 fires)
AUDIT-068-HOST-WRITE: 0 hits                                        (write surfaces miss)

This is the definitive proof:

1. The install IS captured by the read probe at host_ns ≈ 9.6 s.
2. The corrected value 0x8200A1E8 (not 0x8200A208) is the actual vptr.
3. None of the ~9 host-write surfaces hooked in Session 1+2 catches it.

Reading-error class #36 confirmed: the writer uses a path that bypasses all of xe::store_and_swap<T>, xe::store<T>, Memory::Zero/Fill/Copy, xe::endian_store::set(), and Memory::Copy byte-scan — most likely a *reinterpret_cast<X_FOO*>(host_ptr) = X_FOO{...} raw POD struct copy-assignment OR a direct memcpy(host_ptr_from_TranslateVirtual, &local_struct, sizeof(X_FOO)).

Headline finding

Install epoch: host_ns ≈ 9.4–9.6 s (varies ±200 ms across cold runs). This is ~966 ms before sub_825070F0 fires (~10.4 s host_ns).

Neighbor pattern: 3 simultaneous writes at 0xBCE251C0, +4, +8 within the same 1 ms poll interval — {vptr=0x8200A1E8, self=0xBCE251C0, self=0xBCE251C0}. 0xBCE251BC (-4) does NOT change. This is a 12-byte POD struct copy.

Implications:

• The write is invisible to all currently-hooked host-write surfaces.
• The value bytes {0xE8, 0xA1, 0x00, 0x82, 0xC0, 0x51, 0xE2, 0xBC, 0xC0, 0x51, 0xE2, 0xBC} (big-endian guest order) must appear together in some source — either as a constant pre-baked vtable instance pattern that's memcpy'd, or as fields computed by host code and bulk-written.
• The fact that the second and third slots are self-pointers (= ctx_ptr) suggests a doubly-linked-list head node initialization: head.vptr = vtbl; head.next = &head; head.prev = &head;. This is a textbook intrusive list / queue head pattern.

Wallclock relation to AUDIT-067's sub_825070F0 fire

Event	Host_ns	Wallclock (≈)
Probe init (first slowpath call)	~640 ms	~1.6 s
Various pre-install arena reuse of slot	0.6–5.7 s	1.6–6.5 s
Vptr install at 0xBCE251C0	9.412–9.612 s	~10.4–10.6 s
Phase-NonMatch documented thread.create burst	10.382–10.384 s	~11.3 s
sub_825070F0 fire (AUDIT-061-BR captured)	~10.5 s	~25 s wallclock (AUDIT-067 quoted)

The "host_ns ~10.5 s when sub_825070F0 fires" vs "~25 s wallclock" gap is because host_ns starts when the first AUDIT-068 slowpath call lands (i.e. when canary's static-init plus Wine startup are done) — Wine's JIT-warmup/early-boot takes ~15 s before guest PPC code starts. The ANON_Class install happens ~960 ms before sub_825070F0 dispatch, within the same "post-DiscImageDevice resolve" boot phase that AUDIT-058 framed.

Session 4 recommendation

Three paths to identifying the writer, ranked by feasibility:

Path 1 (RECOMMENDED) — POD struct-copy hook with NEW ε-constraint

The install epoch (host_ns ≈ 9.4–9.6 s) and the 12-byte simultaneous-write signature (3 u32 slots) narrows the candidate hooks dramatically. Two surgical instrumentation strategies:

(a) Pre-instrument all *reinterpret_cast<X*>(host_ptr) = X{...} sites in canary. Ripgrep finds them: pattern \*reinterpret_cast<[A-Z]\w*\*>\([^)]*\)\s*= in src/xenia/kernel/**.cc. A quick scan of Session 1 inventory listed ~30 such sites, but most are in kernel-import handlers that fire repeatedly — the ε-constraint of "fires exactly once at host_ns 9.4–9.6 s on tid=6" lets us bisect.

(b) Wrap xe::SetField() / pointer-typed assignment helpers if any exist. Otherwise instrument memcpy(host_ptr_from_TranslateVirtual, ...) patterns directly — there are ~40 such sites across kernel/util/cpu code per Session 1+2 surveys. The ones NOT already wrapped by Session 2 (xex_module.cc got 4 sites) are candidates.

LOC budget: ~50-100 additive in canary; default-off cvar audit_68_pod_copy_watch_addrs (CSV of VA ranges; emits on every memcpy/raw assign within range).

Path 2 — Guard-page SIGSEGV trap

Use the existing canary ExceptionHandler infrastructure (src/xenia/base/exception_handler*.cc — already cross-platform, has Win SEH and POSIX SIGSEGV handlers wired). Mark the 4K page containing 0xBCE251C0 as read-only at host_ns = 9.4 s (just before the install epoch); the page fault triggers the writer's host instruction, log RIP/host stack, then unprotect+resume.

Pros: catches the writer with bytecode-level precision regardless of how it writes (memcpy, raw assign, vector store, etc.).

Cons: ~150–200 LOC platform-gated; needs accurate epoch timing (can't trap the whole boot or it crashes). Use host_ns ≥ 9.0 s as the gate.

Path 3 — Kernel-handler grep with new ε-constraint

Now that the install epoch is known (9.4–9.6 s host_ns; just AFTER DiscImageDevice::ResolvePath(\\dat\\movie) per AUDIT-058 narrative), grep all kernel handlers for ones that fire in that window AND write to the heap. The probe log already shows this is right around the time HostPathDevice::ResolvePath(\\dat\\movie) runs and various worker file IO starts. Cross-reference with canary's existing kernel-call trace (--log_level=4) to enumerate handlers called in the 9.0–9.7 s window.

LOC: 0 (purely investigative).

Recommended Session 4 priority: Path 1 first (concrete instrumentation extends what we have, leverages the epoch constraint). Path 2 as backstop. Path 3 alongside as a cheap parallel investigation.

Cascade outcome (Session 3)

• A: identify install epoch — PASS (9.4–9.6 s host_ns; ~966 ms before sub_825070F0).
• B: identify neighbor pattern — PASS (3-slot simultaneous write, POD struct signature confirmed).
• C: confirm reading-error #36 — PASS (Run 10 demonstrates host-write surfaces miss the install even with the CORRECT target value 0x8200A1E8).
• D: identify the host-side writer — N/A (Session 4 work, with epoch and signature constraints to narrow the search).
• E: secondary discovery: actual vptr is 0x8200A1E8 not 0x8200A208 — PASS (AUDIT-067's target value was off by 32 bytes; may have contributed to that audit's 0-hit JIT store result).

Net 4/5 wins. Session 4 has concrete constraints (epoch, signature, value correction) to land the writer identification.

Reading-error class #36 reinforcement

Session 3 directly demonstrates reading-error #36 (POD-struct copy-assignment bypass for typed BE/LE field watch). The corrective rule is now formalized as:

When hooking host-side writes to guest memory, member-level set() hooks (e.g. xe::endian_store::set()) catch ONLY explicit assignments like *be<T>* = value. They DO NOT catch:

1. POD struct copy-assignment (*reinterpret_cast<X*>(host_ptr) = X{...}).
2. memcpy into the host pointer (memcpy(host_ptr_from_TranslateVirtual, &local_struct, sizeof(X))).
3. Vector-typed bulk store intrinsics that target guest memory.

Mitigation: pair host-write hooks with read-mode probes at the target VA — the read probe captures the install regardless of the writer's mechanism, and provides epoch + neighbor-pattern constraints for the follow-up targeted instrumentation.

This rule is now reflected in the AUDIT-068 Session 3 read-probe machinery — preserved in canary tree for all future audits.

Discipline observed

• --mute=true on every run ✓
• Cold-protocol: cache wipe before each cold run; cache restored from /tmp/canary-cache-bak-audit-068 at session end ✓ (current cache was backed up at session start since prior backup was missing).
• xenia-rs HEAD e6d43a23… UNCHANGED ✓ (verified by sha256 of git diff HEAD at session start vs end; uncommitted modifications from prior sessions are unchanged from session start, no new modifications made by this session).
• Canary instrumentation purely additive + cvar-gated default-off ✓
• No destructive shortcuts ✓
• Static-init gate pattern preserved + extended (Session 3's read probe thread is also gated on g_guest_to_host_thunk + g_query_protect_thunk being non-null — same discipline as Session 2's thunk gate).

Artifacts (this dir)

• fix-canary-v3.diff — cumulative Session 3 instrumentation (this run).
• run6-read-probe-bisect.log — primary probe on 0xBCE25340 (90 s; 7 changes, ended at 0x820610E0, never 0x8200A208).
• run7-read-probe-neighbors.log — bisect probe on 0xBCE25340 ± 4/8; 3 simultaneous writes at +0/+4/+8 confirming POD signature.
• run9-read-probe-251C0-neighbors.log — neighbor probe on the actual ctx_ptr 0xBCE251C0; captures the install at host_ns=9.416 s.
• run10-cross-validation.log — read probe + host-write watch with CORRECT value 0x8200A1E8; demonstrates 0 HOST-WRITE hits while read probe sees the install at host_ns=9.612 s.
• writer-report-v3.md — this file.

(Run 8 was an intermediate diagnostic; data is included in Run 9/10 logs.)

Phase B / progression

• image_loaded_sha256 ea8d160e… UNCHANGED (instrumentation does not touch XEX image processing).
• xenia-rs HEAD UNCHANGED.
• No progression-metric movement (Session 3 is instrumentation-only). Session 4 has concrete leads.