xenia-rs/audit-runs/review-a-step1c-crowbar-v3/investigation.md

Crowbar v3 — ctx-state install verbatim

Date: 2026-05-21 Predecessor: v2 at audit-runs/review-a-step1b-crowbar-v2/. Status: LANDED. Hypothesis FALSIFIED: wedge is NOT crowbar-soluble at the ctx-state-only level. Case (D) needed (recursive secondary-object install). v3 produces same composite progression score as OFF baseline.

TL;DR

• v2 found case (C): [ctx+44] is a secondary-object pointer. vtable[36] reads it and dispatches through it.
• v3 captured canary's actual [ctx+44] value = 0xBCE25640 (via the audit_68_host_mem_read_probe cvar) along with the rest of the 64-byte ctx head, then installed that state verbatim in ours.
• Worker tid=15 now passes the [ctx+44] load (loads 0xBCE25640 into r3) but 0xBCE25640 is unmapped in ours's address space (ours's allocator returns 0x4D1Dxxxx VAs; canary's xenon-arena VAs in the 0xBCExxxxx range have no equivalent in ours).
• Reading [0xBCE25640] returns 0 → CTR=0 → bctrl faults at PC=0 with r3=0xbce25640 (was r3=0x0 in v2 — confirming the install worked, just deeper recursion needed).
• 3x OFF / 3x ON runs deterministic: swaps=1, draws=0, unique_render_targets=0 identical. Composite progression Δ = 0.

Captured canary ctx state

Canary cold run (90s, --mute=true), with cvars:

--audit_61_branch_probe_pcs=0x825070F0
--audit_68_host_mem_read_probe=0xBCE251C0:8:1000000,0xBCE251C8:8:1000000,
                               0xBCE251D0:8:1000000,0xBCE251D8:8:1000000,
                               0xBCE251E0:8:1000000,0xBCE251E8:8:1000000,
                               0xBCE251F0:8:1000000,0xBCE251F8:8:1000000

AUDIT-061-BR confirmed ctx_ptr=0xBCE251C0 (per AUDIT-068 S3 expectation; no arena drift in this run). Read probe captured the install timeline:

host_ns	event
9.556 s	Install starts: [ctx+0]=0x8200A1E8 (vtable), [ctx+4]=ctx, [ctx+8]=ctx, [ctx+12]=1 (refcount), [ctx+16]=0x01000000, [ctx+32]=0xFFFFFFFF
9.571 s	[ctx+44]=0xBCE25640 written, [ctx+48]=0xBE568F00 written (looks float-ish)
9.754 s	Transient [ctx+32]=1 and [ctx+40]=0x30057018 writes that are cleared next probe tick — likely temporary scratch during a function call
9.755 s	Stable post-install state

Final ctx bytes (saved at ctx-canary.bin):

  +  0: 82 00 A1 E8 BC E2 51 C0 BC E2 51 C0 00 00 00 01   <- vptr / self / self / refcount
  + 16: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  + 32: FF FF FF FF 00 00 00 00 00 00 00 00 BC E2 56 40   <- ...sentinel... / [ctx+44]=0xBCE25640
  + 48: BE 56 8F 00 00 00 00 00 00 00 00 00 00 00 00 00   <- [ctx+48]=0xBE568F00 (-0.21f?)

Install path in ours

v3 adds crowbar_maybe_install_ctx_from_file() (~63 LOC) that reads the binary at $XENIA_CROWBAR_CTX_BIN and writes the bytes via mem.write_u8(ctx_ptr + i, byte) — same pattern as v2's crowbar_maybe_install_vtable_from_file(). Plus ~12 LOC of comments and the call-site addition. ~75 LOC additive over v2.

The 64-byte ctx file overwrites the v2 init at +0/+4/+8/+12 with identical values (verified — they match), and fills +16..+63 with the captured state.

Post-install log confirms exact write:

CROWBAR: installed 64 bytes at ctx_ptr=0x4d1d9000
CROWBAR: post-ctx-install ctx[+  0] (=0x4d1d9000) = 0x8200a1e8
CROWBAR: post-ctx-install ctx[+ 32] (=0x4d1d9020) = 0xffffffff
CROWBAR: post-ctx-install ctx[+ 44] (=0x4d1d902c) = 0xbce25640    <-- secondary obj ptr installed
CROWBAR: post-ctx-install ctx[+ 48] (=0x4d1d9030) = 0xbe568f00

The fault (v3)

Identical fault PC, different r3 — that's the smoking gun:

	v1 (no ctx install)	v2 (init +0..+12 only)	v3 (full 64 bytes)
FAULT PC	0	0	0
LR	0x82506e38	0x82506e38	0x82506e38
CTR	0	0	0
r3	(any)	0x0	0xbce25640
r30 (ctx_ptr)	0x4D1D9000	0x4D1D9000	0x4D1D9000
tid	15	15	15

The lwz r11, 0(r3) at PC 0x82506e28 (per v2's disasm) loads from r3 = [ctx+44]. In v2, r3=0, so reads [0]=0. In v3, r3=0xBCE25640, so reads [0xBCE25640]. Both reads return 0 because:

• v2: page 0 isn't mapped (well, it might be but the value is 0).
• v3: page 0xBCE25640 is definitely unmapped in ours.

Ours's heap is at 0..0x6FFFFFFF (per KernelState::heap_alloc). The xenon physical-region VAs (0xBC000000..0xC0000000) never appear in ours's allocator namespace — MmAllocatePhysicalMemoryEx just calls heap_alloc() which returns low VAs.

Why this falsifies the v3 hypothesis

The brief's hypothesis: "with the full ctx state pre-installed AND the 4 workers spawned, ours produces swaps≥2 or draws≥1."

Outcome: ctx state IS installed, 4 workers ARE spawned and resumed, but the dispatch on the secondary object fails because the secondary object's VA isn't mappable.

This is exactly case (γ) → fault at new structural location that the brief predicted. The new fault PC isn't actually new (still 0), but the new fault PRIMARY CAUSE is different: in v2 the cause was "ctx+44 not initialized"; in v3 it's "ctx+44 points to an unmapped VA."

Composite progression score

Per brief's option 6 metric (excluding the matched_prefix term, which needs canary cross-comparison not available in check digests):

score = 1*swaps + 10*draws + 100*unique_render_targets

Run	swaps	draws	unique_RT	score	instructions
OFF-1	1	0	0	1	25,000,000
OFF-2	1	0	0	1	25,000,000
OFF-3	1	0	0	1	25,000,000
ON-1	1	0	0	1	20,000,167 (faulted)
ON-2	1	0	0	1	20,000,167 (faulted)
ON-3	1	0	0	1	20,000,167 (faulted)

Δ = 0. The instruction count dropped from 25M to 20.0001M in ON runs because the fault halts the run early at instr=20000167, ~167 instr after the crowbar trigger (threshold=20M). Confirms the workers can't even complete one meaningful iteration before faulting.

LOC delta

• crates/xenia-kernel/src/exports.rs: +63 LOC (helper)
  • 13 LOC (call-site comments + wire-up) = +76 LOC over v2.
• audit-runs/review-a-step1c-crowbar-v3/: artifacts (ctx-canary.bin, canary-probe-run1.log, off-{1,2,3}.json, on-{1,2,3}.json, this doc, summary.md, re-validation.md, fix.diff).
• No tests added: the helper is structurally identical to v2's crowbar_maybe_install_vtable_from_file, which has no test (it's a diagnostic, opt-in via env var).
• canary instrumentation: 0 LOC (reused existing audit_68_host_mem_read_probe cvar).

What this confirms

1. v2's case (C) framing is structurally correct: [ctx+44] IS a secondary-object pointer that vtable[36] dispatches through.
2. Cross-engine pointer-VA mismatch is real and non-trivial: ours's allocator namespace doesn't include 0xBCxxxxxx VAs.
3. The wedge is ≥4-deep (vtable + ctx primary + ctx secondary pointer + secondary object's own vtable + fn-pointer slot). Crowbar approach saturates without much deeper state capture.

What this does NOT confirm

• That the actual canary VA 0xBCE25640 is the ONLY secondary object. There may be more pointers in deeper ctx slots (we only captured 64 bytes; the full struct may be larger).
• That installing the secondary object would suffice. The secondary object likely has its own pointer fields (head node of a linked list — looks like a queue/work-list given the doubly-linked-list pattern at +4/+8).

Recommendation

Stop the crowbar approach. The wedge is structurally too deep for state synthesis to be cheaper than fixing the natural-activation gap. Per Q5 of the boot-state review (methodology-assessment.md): the matched-prefix metric is on the wrong thread, and the wedge is inherently a thread-activation problem, not a state-construction problem.

Pivot recommendations (in order of cost):

1. AUDIT-069 follow-up — the 25 vs 1 "other producers" gap from Session 5 is more actionable than the worker-spawn gap. The XAudio thread resume at canary 1.726 s is a candidate trigger that produces 8-24 helpers ahead of the wedge.
2. Recursive ctx-state capture (option β from brief) — write a probe-graph tool that captures canary's pointer-reachable closure from ctx_ptr (BFS via audit_68_host_mem_read_probe, follow each pointer field that's in the BC arena, capture another 64 bytes, repeat). Estimate: 200-400 LOC tooling + needs ours-side memory allocator extension to map BC-arena VAs. High complexity vs gain.
3. Pointer-translation table (option α) — map canary BC-VAs to ours allocator-VAs on install. Needs canary-vs-ours linked allocator walk; ~300 LOC.

The natural-activation path (Step 2 of the boot-state roadmap) is likely cheaper than any of these crowbar extensions.