1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
# SMUIO and the four unidentified SMN bases — surveyed, both negative
Read-only, using the batch+health-check protocol from
FINDING-NO-PSP-MEMORY-APERTURE.md. Every batch passed
(`sos_alive`, SMU `TestMessage`->0x1235, `MEMSIZE=0x5ff0`); no recovery needed.
## (1) SMUIO — 2 live registers, GPIO-shaped, nothing else
0x00016800 REAL 00000000 cccccccc 00000000 00000005 00000000
0x00016a00 ALIAS (dead)
0x02401000 MIRROR 00104002 = byteswap(addr)
0x03440000 MIRROR 00004403 = byteswap(addr)
Bounded walk of the whole block `0x16800..0x16c00` (step 0x20) found exactly
**two** live registers:
0x016840 = fffffff0
0x016880 = 0000000f
Those are complementary masks (top-28 / bottom-4), which is the classic shape of
a GPIO direction register paired with a value/enable register — 4 pads active.
The `0xcccccccc` at `0x16804` is a fill pattern, not data.
Assessment: a handful of GPIO pads. No mailbox, no buffer, no length field,
nothing parsing host input. Not an attack surface. Driving the pads would be a
hardware-effect experiment (I2C lines, straps), not a PSP compromise, and is out
of scope for a read-only pass.
## (2) The four unidentified live bases — small config blocks
0x01300000 REAL 0140000160008000 0000... (16 B then zeros)
0x10100000 REAL 0210791407001000 1000040600000100 ...
0x1a300000 REAL 0210781407001020 1000040600000100 ...
0x1f000000 REAL ffff070000000000 ... 000008d0
* `0x10100000` and `0x1a300000` are near-identical, differing in three nibbles
(`7914` vs `7814`, `1000` vs `1020`, `0404` vs `0304`) — two instances of the
same structured config block, almost certainly per-port link/IP straps.
* None matches any offset in the flash image.
* None contains ASCII, PSP module bytes, or Thumb-looking code.
* All are small: content goes to zero within ~16-32 bytes.
Assessment: static configuration/strap blocks. No host-parsed input, no
security relevance.
## Net
The MMIO map is now surveyed end to end. Summary of everything reachable:
| block | verdict |
|---|---|
| MP0 / MP1 | audited hard (PSP + SMU) |
| GC / SDMA | reachable; F32 ISA unreversed; cannot reach MP0 |
| DF | only a **flash aperture** (read-only, matches archive exactly) |
| UMC | NOT reachable via SMN (all mirror/alias) |
| ATHUB / MMHUB | NOT reachable via SMN (all mirror/alias) |
| DCE | power-gated; only `0x34c0` decodes |
| SMUIO | 2 GPIO registers |
| THM | read-only probe, 1 live value |
| 4 unknown bases | static config blocks |
| **PSP SRAM / TMR** | **no aperture exists** |
Nothing here is a vulnerability. The register-fabric avenue is exhausted.
## Follow-up (STALEUS paper, CVE-2025-54509)
See `ARCH-INSIGHTS-FROM-STALEUS-PAPER.md`. AMD's SMN refuses under-privileged
accesses by returning **0x0 or 0xFFFFFFFF**, so those values cannot distinguish
"no register here" from "present but access denied". Host SMN accesses via PCIe
config space are security level 7 (least privileged); the PSP is level 0.
`regguard` now reports `DENIED?` for those values and provides `timing_probe()`
to separate the two cases. Conclusions in this file that rest on MIRROR/ALIAS
signatures are unaffected; any that rest on all-zero reads need re-checking.
|
