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
|
# 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.
|
