|
|
truth
Prong 2 succeeded after dropping the arm that wedged the card. LOAD_TA lets the
host choose app_phy_addr and the PSP's returned status classifies what it found:
real signed TA image 0x0 loads, session allocated
readable VRAM, invalid 0x34 signature verification failure
range overlapping the TMR 0xa
Two different junk buffers both give 0x34, so the status is not noise, and a
real image gives 0x0, so the path works. Both controls pass and the PSP
heartbeat stays alive through every probe -- non-destructive, unlike the
absent-address probing that cost a power cycle.
Validated against independent ground truth rather than trusted. TMR is PA
[0x300000,0x1600000) from the SMU/PSP fields, measured previously by a different
method; sweeping the oracle across that boundary agrees 7/8.
The single mismatch is the most useful row. 0x2ff000 is one page BELOW the TMR
base but reads INSIDE, because app_len makes the source RANGE extend into the
TMR. So the refusal covers [start, start+len), not the start address alone --
and the upper edge confirms it, with 0x15f0000 reading INSIDE while 0x1600000
reads outside. Page-granular results are available by shrinking app_len.
Scope stated honestly: this classifies host-visible VRAM (MC) addresses, so it
can map the TMR page-exactly and discover protected ranges we do not already
know about, but it does NOT reach PSP-internal space and therefore says nothing
about Route C's window.
Note why this one worked when the data-channel attempts did not: it needs only a
STATUS channel, and that was always present -- 0x34 had already been seen in
load_asd.py for a bit-flipped image without anyone asking what other values the
same field could take.
Harnesses added: hw/psp_addr_classify.py, hw/psp_addr_classify_validate.py.
|
