# NEW: the complete SYS_DRV ACL opcode-range table — three opcode families we never knew existed

Found while hunting host-reachable bugs. The project's opcode model for SYS_DRV was
recorded as *"0x1000-0x10A6, 0x3008-0x3160, 0x4014/0x4015, 0x8004-0x800A"*.
**That model was incomplete.** The authoritative source is the ACL range table at
`0xE23398`, walked by `sub_E05A24` before every dispatch:

| idx | lo | hi | capability mask |
|---|---|---|---|
| 0 | 0x1100 | 0x11ff | 0x200 |
| 1 | 0x2005 | 0x2005 | 0x200 |
| 2 | 0x2000 | 0x20ff | 0x40 |
| 3 | 0x3000 | 0x30ff | 0x1000 |
| 4 | 0x3100 | 0x31ff | 0xffff0 |
| 5 | 0x103d | 0x103d | 0x400 |
| 6 | 0x103f | 0x103f | 0x800 |
| 7 | 0x4000 | 0x400f | 0x2000 |
| **8** | **0x6000** | **0x60ff** | **0x4000** |
| **9** | **0x7000** | **0x70ff** | **0x8000** |
| 10 | 0x8000 | 0x80ff | 0x10000 |

Entries 8-10 were entirely absent from our model. Note also that `0x31xx` demands
**sixteen** capability bits while every other range needs **one** — the asymmetry
noted in `VULN-SYSDRV-3103-OVERFLOW.md` is real and visible here.

## The 0x70xx family = TA register access (RAS emits it)
    0x7001 -> ta_reg_access_simple(write)   0x7002 -> ta_reg_access_simple(read)
    0x7006 / 0x7007 -> 64-bit variants      0x7004 -> no-op return 0
    0x7008 -> dram_range_query (read-only range check, performs NO write)

`ta_reg_access_simple` is **allowlist-gated**: the register ID must resolve through
`reg_allowlist_lookup` (SLWR hash table @0xE79034), then `attr_permits_usage`
checks the requested width/flags against the granted ones, before `SVC 0x7B`
(read) / `SVC 0x7C` (write). Sound.

RAS emits `0x7001/0x7002/0x7006/0x7007/0x7008` — so this family **is** reachable
from a host-loadable TA, but the allowlist bounds it.

## The 0x60xx family = OTP read + an MMIO-write primitive
    0x6001 -> otp_block_read(param[0], HIDWORD(param[0]))
    0x6002 -> tlv_buffer_copy(param[0], HIDWORD(param[0]))
    0x6003 -> frame_validate

### `tlv_buffer_copy` is a real MMIO-write primitive — but unreachable
    if ( a2 > 0x200 ) return err;         // <= 512 bytes
    if ( a2 << 29 == 0 )                  // 8-byte aligned
      memcpy(v12, a1, a2);                // into a 512-byte stack buffer
      for ( i = 0; i < a2>>3; ++i ) {
        if ( fw_teardown_all(v12[i]) == 0 ) return err;
        SVC 0x7C                          // write(addr=v12[i].lo, val=v12[i].hi, 4)
      }

Disassembly confirms **both operands come from the attacker buffer**:

    LDR.W R0, [R7,R4,LSL#3]   ; addr  = v12[i].lo
    BL    fw_teardown_all     ; the only gate, on the address
    LDR   R1, [R1,#4]         ; value = v12[i].hi   (UNCONSTRAINED)
    MOVS  R2, #4
    SVC   0x7C

`fw_teardown_all` is a misnomer (our own annotation): it is an **address allowlist**
— `fw_slot_scan_a/b/c` + `fw_slot_any_busy` accept only
`base + (i<<25) + (j<<16)` forms for i in 0..5, j in 0..1, with bases
`0x31005f04 / 0x31004f00 / 0x31004a40 / 0x31000200`. So ~24 exact addresses plus
~36 short ranges in SMN `0x31000000-0x3b01xxxx`, up to 64 writes per call, with
**fully attacker-chosen 32-bit values**.

Structurally this is a second Route C. **It is not reachable:** scanning every
`SVC 0xF2` site in all six modules, **no module emits 0x6001/0x6002/0x6003**
(only SYS_DRV holds the literals, in its own dispatcher comparisons).

> **RETRACTED — the emitter exists.** That scan covered the six modules known at the
> time (ASD, HDCP, DTM, RAS, SYS_DRV, sOS). **POWERPLAY emits all three**
> (`powerplay_sysdrv_rpc_6001/6002/6003` at `0x402516`/`0x402542`/`0x4024ac`, 35 call
> sites between them), and POWERPLAY is loadable and invokable on our card. It ships
> only in AMD's Windows driver train, which is why it was absent from the scanned set.
> See `fw/FINDING-SYSDRV-60XX-EMITTER-FOUND-POWERPLAY.md`. Host-controllability of the
> written values is still unresolved, so this is not yet a bug — but it is no longer
> "unreachable".

## Status
No new host-reachable bug **at the time of writing**. What this adds is a corrected,
authoritative opcode model for SYS_DRV, three previously-unknown families, and one more
instance of the recurring pattern: **a genuine primitive behind an absent emitter**
(then the fifth — `ring==0xFFFF` x2, `0xFFFF0005`, `0x54-0x56`, and `0x60xx`).

**Update:** `0x60xx` no longer belongs on that list. POWERPLAY emits it. The lesson is
that "absent emitter" is a statement about the module set searched, not about the
platform, and every such claim in this tree should name its set.