dmcub/hw — hardware PoC path for FINDING-2 (Option A: bring up the DMCUB)

Status: RUN ON HARDWARE, 2026-09 (Navi 31 over USB4, tinygrad AM). The DMCUB was brought up from a cold, uninitialised display block and FINDING-2 was reproduced: see EVIDENCE-type8-poc.txt. Every script also keeps its offline --selftest (header parsing, address arithmetic, window layout, register write order, frame encoding, and a model of the target firmware case).

Results in one line each:

• dmcub_probe.py — DCN is powered and DMU registers are live; DMCUB was halted.
• dmcub_bringup.py — backdoor load is blocked on this part (CW0/CW1 and SEC_CNTL writes are dropped); --phase psp_load boots the core (SCRATCH0 = 0x3).
• dmcub_poc_type8.py — 5/5 out-of-range panel_inst values returned planted bytes; confirmed to k = 227.

Why bring-up is needed at all

The rig drives the card through tinygrad's AM userspace driver, which initialises no display IP (psp_out/ATTACK-SURFACE.md:190 — the same blocker that stalled the HDCP display-state path). So there is no DMCUB firmware loaded, no cache windows and no inbox1 ring to submit a command to. This directory ports dmub_srv_hw_init + dmub_dcn32_* (vendored in ../ref/) onto that stack.

Corrected on hardware: the plan was to avoid the PSP entirely via dmub_dcn32_backdoor_load, on the assumption that the instruction window is fetched from framebuffer with no signature check in our path. That is wrong on Navi 31 — DMCUB_REGION3_CW0_*, CW1_* and DMCUB_SEC_CNTL silently drop host writes and read back 0, while CW3/4/6, INBOX1_* and DMCUB_CNTL retain them. The backdoor sequence therefore runs to completion and the core never boots.

The working path is --phase psp_load: GFX_CMD_ID_LOAD_IP_FW with GFX_FW_TYPE_DMUB and the signed $PS1 payload (status 0), then windows, mailbox, release — after which DMCUB_SCRATCH0 = 0x3 (dal_fw, mailbox_rdy). The stock signed image is used unmodified throughout. A hung DMCUB is revived by re-running psp_load + release; no ATX cycle was needed at any point, and the rest of the GPU stayed healthy.

Order of operations

# 0. offline, no hardware:
python3 dmcub_hwregs.py   --selftest
python3 dmcub_bringup.py  --selftest
python3 dmcub_poc_type8.py --selftest

# 1. READ-ONLY gate: is DCN powered, is the DMCUB already running?
python3 dmcub_probe.py --json probe.json

# 2. review the exact register sequence (writes nothing)
python3 dmcub_bringup.py --state-out bringup.json

# 3. bring the core up
python3 dmcub_bringup.py --state-out bringup.json --apply

# 4. the PoC: plant markers, submit type-8, check the reply
python3 dmcub_poc_type8.py --state bringup.json          # dry run
python3 dmcub_poc_type8.py --state bringup.json --apply

dmcub_probe.py decides whether steps 2-3 are needed at all: if something has already brought the DMCUB up, the PoC can inject into the existing ring.

Observed safety (and one PoC artifact)

Reads whose source leaves every mapped window return zeros and do not fault the core (verified at panel_inst = 300, 1000, 0x4000, 0xFFFF), so the "unbacked access" hazard this PoC was designed around did not materialise. One DMCUB hang was seen, after a sweep that planted gate bytes across the whole fw_state window — i.e. the PoC corrupting live firmware state, not the bug. Plant only what a run needs.

Why this PoC cannot wedge the card

The leak is memcpy(frame + 4, ctx + 8*panel_inst + 0xaea0, 8) with ctx = 0x66000300 — inside cache window 6, whose backing VRAM we allocate. So the PoC:

• plants known 8-byte markers at ctx + 8*k + 0xaea0 and sets the stride-0x7b8 gate byte, both from the host, for k in the derived deterministic range 2..23 (source and gate mapped);
• treats k = 0, 1 as the baseline — those are the only legitimate values, since the part has two panels;
• refuses any k whose source leaves the window (k > 227 for this image) unless --allow-wild is passed. That is the unbacked-access case psp_out/CONSTRAINTS.md warns about ("any probe that makes an on-die engine access unbacked memory can take out the SMU");
• re-checks liveness (DMCUB_SCRATCH0.dal_fw + DMCUB_TIMER_CURRENT advancing) after every submission and stops at the first anomaly.

Every address touched stays inside a window the host mapped. The evidence is therefore stronger and safer than a wild read: the reply must contain our bytes from an offset the command is never supposed to reach.

Expected result, and what would falsify the finding

If indices ≥ 2 come back as zeros, or identical to k = 1, or the frame's ret_status bit is never cleared, then the index is bounded somewhere the static audit missed and FINDING-2 must be retracted.

Known unknowns (updated after the run)

1. ~~DCN power/clock~~ — resolved: DCN is already powered on this card after ATX-on; DENTIST/DCCG read real values and DMU registers are live. No display power work was needed.
2. Register access. Use adev.rreg/wreg(idx); they pick BAR vs RSMU indirection themselves. Do not hand-roll a wreg(14)/rreg(15) window (see the mistake recorded in dmcub_hwregs.py). validate() now proves the path with a known-value control plus a scratch write/readback, because every DMCUB register reads 0 before initialisation.
3. ~~Backdoor load may be fused off~~ — resolved: it is blocked (FINDING-5).
4. VBIOS window is a zeroed 64 KB stand-in; no VBIOS command is exercised, but if boot itself reads VBIOS tables this may need the real image.
5. DMCUB_SCRATCH15 is written 0 (the field is psp_version & 0x001100FF), which is what a non-PSP load implies; if the firmware gates behaviour on it, expect boot to differ.