FINDING: the PSP ring frame's vmid byte is host-controlled, propagated into the PSP's own memory accesses, and unvalidated

Evidence class: [HW] — Navi 31 / RX 7900 XTX, live sOS/SYS_DRV 0.49.0.54. Status: host-controlled VMID propagation CONFIRMED. Cross-context access NOT achieved.

How this was reached

The fence_addr finding opened the ring frame as a surface no earlier pass had examined. Sweeping all 16 dwords of psp_gfx_rb_frame at dword resolution (hw/frame_sweep.py) found the dword at +32 kills the PSP. That offset is not reserved:

Confirmed on hardware

hw/vmid_test.py <vmid> <frame_type>, one measurement per fresh boot:

1. Any non-zero vmid wedges the PSP — a seventh host-triggerable DoS trigger, requiring work/atx_power.py cycle 25. frame_type is ignored entirely.
2. The host-supplied value is propagated into the PSP's own memory accesses. The interrupt log during the attempt shows VMC protection faults tagged with the host-supplied VMID, at the PSP's own command buffer address:

IH client=SOC21_IH_CLIENTID_VMC src=(0) vmid=1(1) pasid=0 ctx=[0x8000088, 0x40, 0x0, 0x0]

The PSP fetched its command through VM context 1 because the frame said so. Nothing validates the field, and the failure mode is death rather than an error status.

Fault-level characterisation (strengthens point 2)

hw/vmid_fault.py reads MMVM_L2_PROTECTION_FAULT_STATUS after a single attempt:

0x100d33 decodes as a read fault with MORE_FAULTS, WALKER_ERROR and MAPPING_ERROR set. So the PSP issued a read of its own command buffer through VM context 1, and the page-table walk for that context failed. The control leaves the status register at zero, so the fault is attributable to the frame byte and nothing else.

What was NOT achieved

Configuring the MM hub's VM context 1 with the same root page table as context 0 and flushing its TLB does not make vmid=1 work (hw/vmid_proof.py conf: vmid=0 succeeds, vmid=1 still fails). Two obvious explanations are ruled out by measurement:

• the configuration did not apply — hw/vmid_ctx_verify.py reads the registers back: after programming, context 1 matches context 0 exactly (base=0x1, cntl=0x1fffe07, start=0, end=0xffffffff) on the single MM hub (mm_insts=[0], vmhubs=1);
• contexts 1-15 disabled at L2 — regMMVM_CONTEXTS_DISABLE reads 0x0.

So either the PSP's accesses are translated through a hub or context set other than the MM contexts, or something further is required that is not visible from these registers. A controlled access under a host-chosen context was therefore not demonstrated, and no memory-corruption primitive follows from this on a bare-metal part.

A first version of this experiment did before/after inside one boot and reported "not a translation-context selector"; that verdict was void because one vmid=1 attempt kills the PSP, so the "after" control inherited a dead PSP. Restructured to one measurement per boot.

Why it still matters

Even a success here would not be a bare-metal primitive, and that is worth stating plainly: the host already owns context 0's page tables and already chooses the addresses in the frame, so directing the PSP through a different host-owned context grants the host nothing it did not have. On a bare-metal part an unvalidated vmid is therefore only a DoS. The concerning shape is a virtualized (SR-IOV) configuration: a frame field naming the translation context, honoured by trusted firmware and unchecked, is the classic confused deputy — a guest naming another guest's context. This is a hypothesis about virtualized parts, not a demonstrated result; SR-IOV is not available here (already recorded as a blocker for the RLCV work).

Suggested fixes

1. Validate vmid against the context the ring's owner is entitled to; reject anything else with a status.
2. Fail with a status rather than dying when translation faults.
3. Reject or ignore frame_type explicitly rather than silently.