Record PSP security investigation artifacts and probesHEADmain

1 files changed, 54 insertions, 0 deletions

diff --git a/fw/CANDIDATE-GCP-ASD-101-OWNERLESS-RECORD-ERASE.md b/fw/CANDIDATE-GCP-ASD-101-OWNERLESS-RECORD-ERASE.md
new file mode 100644
index 0000000..095ce67
--- /dev/null
+++ b/fw/CANDIDATE-GCP-ASD-101-OWNERLESS-RECORD-ERASE.md
@@ -0,0 +1,54 @@
+# ASD `.163` `0x101`: ownerless indexed channel-record erase
+
+**Status:** signed-code global-record destruction candidate, synthetic
+signed-dispatch proof. No victim channel on the card, independent hardware
+teardown effect, or exact restoration oracle. Do **not** invoke this
+stateful opcode on hardware merely for a return code.
+
+`asd_dispatch` (`0xD013B8`) routes service-2 `0x101` to `sub_D08C08`
+with just caller-selected `msg[1]` as its channel index. GCP→ASD service
+2 access has separately been demonstrated for other opcodes, but **this
+opcode was not invoked on the card**. The signed leaf checks only
+`index <=31` (`0xD08C08`), calls `sub_D0A7A8(index)` and
+`sub_D0AEB0(index)`, **ignores both results**, then zeroes exactly the
+selected 92-byte record at `0xD33510 + 92*index` via `bzero_core` and
+returns zero. There is no active-state, channel-owner, or requesting-TA
+identity check before the zero. The two helpers may change ASIC/link
+resources; this audit deliberately did not execute their real effects.
+A cleared channel may desynchronize other channels or global allocation
+tables, but that consequence was not demonstrated.
+
+`python3 psp_emu/harness/probe_asd163_101_ownerless_record_zero.py`
+compiled and passed using the signed `.163` dispatcher/leaf. It plants
+synthetic private records at channels 5 and 6 and intercepts only the two
+stateful helpers to return failure `0x1234`. Invoking channel 5 with
+synthetic caller scalar 2 returned zero, erased **all 92 marker bytes** in
+channel 5 despite both failed helpers, and left adjacent channel 6
+unchanged. Index 32 returned 5 with no helper visit or change. After
+replanting the synthetic record, caller scalar 7 produced the same erase.
+This proves the signed erase ordering and lack of caller binding at the
+reviewed leaf, **not** that either scalar corresponds to a real sOS
+service caller identity or that a live other-client record was hit.
+
+A **real signed DTM `.19` producer** confirms this opcode is used for
+topology removal, not merely a dispatch label. `dtm_sysdrv_rpc_101` at
+`0x4010DE` places `{0x101, channel}` on the stack and calls service 2
+through `SVC 0xF2` (`0x4010F2..0x4010F6`). DTM's signed `TA_InvokeCommandEntryPoint` (GP command 5) requires low
+paramTypes nibble 7, a nonnull buffer and declared size `>=0x50`; command
+IDs 2 and 4 route to `dtm_cmd_topology_update` and
+`dtm_cmd_topology_update_v2` with args at buffer `+16`. Both call the
+`0x101` wrapper with `req[0]` when `req[1]==0`
+(`0x40114A..0x40114C` and `0x4011A8..0x4011AA`); their nonzero
+`req[1]` branches issue `0x100` topology updates. This establishes a
+signed DTM invocation route, **not** a live build, arbitrary host access,
+or cross-process ownership proof. A
+global channel-erasure API may be intentional for a display manager;
+calling it from compromised GCP is not automatically a new ASD defect
+without a demonstrated boundary/impact distinction.
+
+Existing signed HDCP clients consume ASD channel state during link/auth
+operations, but a naturally active channel on the card, which process
+owns each index, and a safe victim readback/restoration procedure have not
+been established. The effect is a conditional cross-client integrity/DoS
+candidate, not a measured cross-client hardware fault. Do not infer
+arbitrary CPU-MMU writing or ASD code execution from an indexed zero.