|
|
The version caveat from the last commit -- that this tree's HDCP/DTM/ASD work is
against builds the RX 7900 XTX never loads -- is now discharged for HDCP and DTM.
TAs are NOT in the SPI flash. spi_parse.py on flash_BIOS2_KNOWNGOOD extracts 24
payloads (bootloader, sOS, PSP drivers 0B/40/59/5C/5E, KDB, SPL, TOC, SMU, UMC,
IP-discovery, MPIO) and no HDCP/DTM/RAS/ASD; on a dGPU they come from the host
driver blob. The PSP images that ARE in flash are enc_option=1 encrypted, which
is why a byte-search for our sOS/SYS_DRV/TA bodies missed every single one --
the shape of a broken method, not a real absence, and it was nearly written down
as a finding. An ad-hoc directory parse done alongside it was also misaligned:
spi_parse.py documents loc[63:62]=3 as image-slot-relative and I read the
address as absolute, producing a plausible table of the wrong offsets. The tool
existed; I should have looked first.
Extracted from /lib/firmware/amdgpu/psp_13_0_0_ta.bin into the existing
<ta>_<version>_<sha8>.elf convention: hdcp_23.0.0.63, dtm_18.0.0.22,
asd_33.0.0.217, plus ras_27.0.2.5 which is the ELF builder's positive control --
same code path, and it must reproduce db2ed53e, the hash we already had. It does.
pspemu/ta_entries.py resolves GP entries from the image instead of hardcoding
them: header+0x10 -> trampoline, +0xA0 -> create, +0xB0 -> invoke. verify()
re-derives HDCP/RAS/DTM and requires the values the harnesses have always used,
3/3 exact. It does NOT work for ASD, which yields zeros; that is reported as
"does not apply" rather than letting zeros pass for answers.
Results, every run gated on a discriminator read from the emulator's own memory
(the loaded trampoline pointer) so a silently-failed swap cannot look like a
result:
fuzz_hdcp 815 -> 817 blocks, 400 ok both
hdcp_cmd0f identical output except one fault PC
hdcp_subcmd12 identical output except one fault PC
dtm_ras byte-identical output
The sole difference anywhere is 0x0040433c vs 0x004042b4 -- the same code at a
different link address. The err_state=7 one-shot latch and the subcmd12 overrun
thresholds carry over unchanged.
Correcting a misattribution from earlier in this session: I reported
poc_copystate_heap_overflow as "CONFIRMED on the card's HDCP 23.0.0.63". Wrong
twice. That harness builds no HDCP component at all -- it drives sysdrv_env, so
it is a SYS_DRV crypto finding that was never HDCP-version-dependent. And the
monkeypatch meant to inject the card's image never fired; the instrumentation
said "Components built during the run: []" while the harness printed a confident
RESULT: CONFIRMED. An injection that silently no-ops is indistinguishable from a
successful experiment unless you check, which is why every run above checks.
ASD remains uncovered: the entry resolver does not handle its layout, so no
claim is made about ASD on the card's build.
|
