amd-psp-re.git/fw, branch main

Record PSP security investigation artifacts and probes

2026-10-09T14:11:31Z

GCP->ASD 0x403: ASD-internal chain PROVEN end-to-end in emulator (real handlers)

2026-10-08T17:04:04Z

gcp_asd_403_write.py runs real asd_topology_update(0x100) x2 + asd_platform_op_403(0x403) unpatched: 0x100(0) + 0x100(1,desc[0xC]=P) forge the op_403 allowlist entry via index-90 topology aliasing (count slot v6.u16[126]=1, pointer slot v6[91]=P confirmed), then op_403(90,4,TARGET,VALUE,0,4) fires SVC 0x7C with addr=0x5000000 value=0xC0FFEE42 width=4 = our CHOSEN operands. SUCCESS. Chain now: GCP->ASD svc2 reach (HW proven) + flat ungated dispatch (verified) + 0x100x2 forge (emu proven, real handlers) + op_403->SVC0x7C chosen write (emu proven) + SVC0x7C broad phys write GCP lacks (static). Only remaining: HW end-to-end = deliver 3 svc2 RPCs in one FE0A ROP chain (one-shot/ boot) writing a benign observable target. Harness-extension task, not a new unknown. Updated eval doc.

GCP->ASD lead: aliasing resolved for our build (index 90) + HW service-2 reachability PROVEN

2026-10-08T17:01:31Z

Aliasing: off_D024D4=0xD42798 (op_403 base), dword_D115E0=0xD42890 (topology table), 0xF8 apart. count slot v6.u16[a1+36]=0xD427E0+2a1 -> entry0+4 at a1=90; pointer slot v6[a1+1]=0xD4279C+4a1 -> entry1+0x14 at a1=90. 0x100 copies desc[0xC] into entry1+0x14 = the pointer op_403 derefs. Full our-build chain specified (index 90 = agent's 'later build'). HW WIN: GCP FE0A ROP svc 0xf2 SERVICE 2 opcode 0x100 a1=0xFF -> status 0x5 (asd_topology_update out-of-range return) => GCP reached ASD and ran 0x100. service-1 control -> 0xffff0009 (different TA). GCP->ASD reachability (the stated kill-switch) CONFIRMED positively on RX 7900 XTX. ASD dispatch is flat/ungated so 0x403+0x100 both reachable. Remaining: end-to-end seed->match->SVC0x7C (emu+hw).

eval: GCP->ASD op_403 confused-deputy -> SVC 0x7C privileged physical write (credible, verified core)

2026-10-08T16:57:38Z

Verified another agent's lead against OUR images. Confirmed in asd2/sos2: (1) asd_platform_op_403 (0xd023c8) uses UNBOUNDED index a1=req.byte[4] to select pointer slot v6[a1+1] + count slot v6.u16[a1+36]; on match of (addr=req[8], subtype=req[5]) it fires SVC 0x7C (val=req[0xC], width= req[0x14]); subtype 4 skips the extra check; GCP ROP controls all fields. (2) SVC 0x7C = sub_6F3A-> sub_3D8C->sub_6D20: broad physical/MMIO write below 0xCB00000 minus two protected windows -- exactly the MMIO-write cap GCP's ACL denies (0x6002) -> real lateral escalation. (3) service 2 == ASD; GCP already calls ASD service-2 legitimately (FE08 rpc_201) so it holds the permission; ASD dispatch is a flat opcode jumptable via BLX asd_dispatch;SVC 0x75 with NO session/ACL gate -> 0x403/0x100 directly reachable. (4) opcode 0x100 = asd_topology_update (0xd1061c) writes topology entry dword_D115E0+96*a1, sets +4=1 (active/count) and copies caller 0x40-byte descriptor from req[8] -> the seed material. NOT yet established: the aliasing in OUR build (agent's addrs/index 88 are card build 33.0.0.217; our op_403=0xd023c8 and 0xD0E038 is a vtable builder here -> re-derive the index that lands off_D024D4[a1+1] on dword_D115E0, runtime tables, resolve in-emulator); end-to-end seed->match->SVC0x7C; and HW service-2 reachability. Recommended: cheap HW service-2 reach test, emulator end-to-end, then HW. Full writeup in fw/EVAL-GCP-TO-ASD-0x403-KERNEL-WRITE.md

hw: no deterministic crypto-output placement - SVC 0xB5 client check (sub_1978) rejects

2026-10-08T16:39:42Z

Pinned the per-boot knob: SVC 0xB5 return gates sub_E0DEF4 and is sub_27F8->sub_1978(client), which returns OK only if client<0x20 AND proc_table[client] active-bit set; else 37 -> whole validation fails for ANY output buffer (buffer-independent). Hardware pass-rate test (op0x35 len4 @0x410380, dumped, fresh ATX/boot): ~25 boots across rnglen/rngdet/rngdet4/passrate ALL reject 0xffff000f, buffer never written; the lone acceptsweep 'pass' (11/11) did NOT reproduce - its exact config now rejects 10/10. Verdict: output-buffer crypto ops reliably reject from the GCP confused-deputy; no deterministic placement exists; reject is client/session state we don't control. Asymmetry: dir==1 INPUT buffers bypass validation (unvalidated reads) but dir==2 OUTPUT buffers are client-gated. Oracle closed; inline create-handle read-back remains the only reliable channel. Updated SIM doc.

sim: confirm GCP crypto ROP message is correct; localize 0xFFFF000F to SVC 0xB5 client-window check

2026-10-08T15:04:33Z

Operator asked whether our ROP sets everything up correctly and whether we can simulate + inspect args at call time. Built psp_emu/harness/gcp_crypto_argcheck.py: reconstructs the EXACT op-0x35 request our hardware harness builds and runs it through the firmware's own sub_E087E4 -> sub_E1DC30 dispatcher with real sub_E0DEF4/sub_E0AB44 validators, hooking dispatcher+validator+RNG leaf. Proven (not inferred): dispatcher sees opcode=0x35, buf0(ptr,len) from msg[2]/msg[3], dir=2 (output), sub_E04F38 reached with our exact (out,len), buffer written. len 4/16/32 ALL succeed with permissive SVC 0xB5 -> hardware len-sensitivity is NOT a message bug. Modeling SVC 0xB5 with limit=base+8 reproduces the hardware exactly: len4 passes (RNG runs), len16/32 return 0xffff000f with sub_E04F38 never reached. So the reject is the window bound check (ptr+len vs [base,limit]), not our setup. Ground-truth chain: sub_E0DEF4 passes iff [ptr,ptr+len] subset of [b1,l1]|[b2,l2]|[E25710,E25714]; SVC 0xB5=case100=sub_178C+sub_27F8 fills the descriptor from the CLIENT process entry (type5 mode1 -> [0x400000,0x800000]; else b1=proc[6] narrow). Accept/reject turns on client type/mode + the SYS_DRV global fallback region at validation time -- state our ROP does not set -> explains per-boot variance. Recorder sub_22B4 writes tcb[24]=*(tcb+0x34)-0x44, tcb[25]=tcb[16]. Full writeup in fw/SIM-GCP-CRYPTO-ROP-ARGCHECK.md.

crypto output oracle: ABANDON - confused-deputy output-buffer validation is run-to-run nondeterministic

2026-10-08T14:48:59Z

Pinned the op-0x35 accept behavior across many boots: the IDENTICAL request (op 0x35, ptr=0x410380, len=4) was ACCEPTED in one boot-series (acceptsweep, status 0) and REJECTED 5/5 in another (rngdet4, 0xffff000f). Same opcode/ptr/len/harness -> SVC 0xB5 validation of confused-deputy output buffers is run-to-run non-deterministic (boot-series correlate; likely the recorded window tcb[24]/[25] from the type-5 gate varies with boot stack layout). Consequence: cannot reliably land a crypto DATA write -> seeded-RNG determinism question unanswerable via this path (never got one confirmed RNG buffer write; the earlier 'identical output' was stale GCP memory, disproven via create baseline). Reliable: only the inline create-handle read-back (not an engine oracle) + the GCP->SYS_DRV DoS. Recorded in harness doc.

crypto output read-back: principle OK (create handle), but RNG 'identical output' was STALE GCP memory

2026-10-08T14:30:08Z

Follow-up to the hijack retraction. Pointing a crypto op output at GCP memory clear of the ROP chain should let us read engine output back. Principle validated by op 0x01 create: handle 0x10 read back via the message copy-back = a confirmed crypto output read-back. RNG (op 0x35) data-buffer demo BLOCKED: output->0x410500 (len 4 and 32) gate-rejects (status 0xffff000f = dword_E1DF48 buffer-gate fail) -> RNG never wrote. Decisive control: a create baseline (writes nothing to 0x410500) dumped the SAME bytes bb18bb63... as the RNG runs across 3 boots. So the 'identical random-looking output' is STALE GCP memory at 0x410500, NOT RNG output -> the deterministic- seed hypothesis does not apply (RNG didn't run). 0x410500 is GCP-mapped (dump reads it) but SVC 0xB5 rejects it as an op-0x35 OUTPUT buffer; earlier single-op ptr_sweep accepted op0x35->0x410500 len4 at status 0, so the gate accept/reject is harness/len/state-sensitive, not yet pinned. Updated harness doc.

re-evaluate GCP attack surface (post-retraction): capability-capped SYS_DRV reach + ranked avenues

2026-10-08T14:09:18Z

fw/ASSESSMENT-GCP-ATTACK-SURFACE-CURRENT.md. Verified: GCP code-exec, svc 0xf2 -> SYS_DRV/ASD, crypto + free-opcode surface executes. Reachable but CAPPED: crypto (TA-scoped, no device key, bounded), free high opcodes (inert/getters/bounded = fuzz_sysdrv ground), confused-deputy buffer write (hits GCP's own shared buffer, or SYS_DRV DoS), ASD (validated). NOT reachable: all gated primitives (OTP 0x6001, MMIO 0x6002, overflow 0x3103, reg 0x70xx) -- opcode ACL, GCP lacks caps. Ranked remaining avenues: (A) GCP's OWN address space -- unexplored, needs NO escalation; GCP is the content-protection/crypto-session TA so its in-process keys/device-bound secrets are directly dumpable with our code-exec [highest value]; (B) lateral to POWERPLAY(0x60xx)/RAS(0x70xx) for the gated fuse/ MMIO primitives; (C) the confused-deputy GCP->SYS_DRV DoS (real, low sev); (D) exhaustive mem-safety of the reachable surface; (E) widen the svc-0xf2 window past 0x800000. Verdict: capability-capped into SYS_DRV; realistic next win = harvest GCP's own secrets; fuse crown jewels run through POWERPLAY/ RAS.

overview: correct the retracted SYS_DRV-hijack claim -> GCP self-corruption + SYS_DRV DoS only

2026-10-08T14:06:43Z