# RAS TA: actually invocable (prior campaigns never were), and audited — negative

## Prior campaigns never invoked RAS at all
`fuzz_campaign.py` recorded RAS returning `0x80000000|cmd` for every command and
I read that as "unsupported". It was **my own harness misreading the buffer**:
RAS echoes the command at `+0x04` with bit 31 set. The real status is at
**`+0x08`**. RAS commands also come from **`frame[0]`, values 0-4** — not
`ta_cmd_id`:

    0 ENABLE FEATURES  1 DISABLE FEATURES  2 TRIGGER ERROR
    3 QUERY_BLOCK_INFO 4 QUERY_SUB_BLOCK_INFO

Response region is `+0x810..0x823` (matches `ras_attach_response_buffer`'s
`bzero(ptr+0x810, 0x14)`), plus `+0x410`.

## asic == 49 HOLDS on this card, so the callbacks are live
`ras_device_register` installs the handler pointers only when
`dword_406060[0] == 49`. Proof it is satisfied: cmd 0 returns status 0 in 1458
runs but **40978 in 18** — input-dependent, which is impossible if `off_4060AC`
were NULL (NULL -> unconditional `return 0`). 40978 is emitted by
`ras_gfx_mode_config`. So `off_4060AC = ras_apply_gfx_feature` is executing.

Installed and host-reachable: `ras_apply_gfx_feature` (cmd 0),
`ras_parse_trigger_request` (cmd 2), `ras_probe_chiplets`.
Permanently NULL: `off_4060B8` (cmds 3/4) — it is **not in the install list**,
which is why QUERY_BLOCK_INFO/QUERY_SUB_BLOCK_INFO always return 40976.

## Campaigns run (all negative, card healthy throughout)
* cmds 0/1/3/4, **6000 rounds**, request area fuzzed: 0 hangs, 0 PSP-range
  pointers in the response.
* cmd 2 TRIGGER_ERROR, **2000 rounds**: all rejected at 40962/40986 — the
  block-type gate was never satisfied because `v4` (64-bit at request+4) must be
  **2 or 4** with high dword 0.
* cmd 2 with the gate satisfied, **2500 rounds**: new status **40977** appeared
  (227x), i.e. host input now reaches the **register-access layer**
  (`ras_reg_read/write{,_chiplet,64}`). Still 0 hangs, 0 leaks,
  `MEMSIZE=0x5ff0` and `sos_alive` checked every 200 rounds.

## Refinement of FINDING-SYSDRV-CHIPLET-UNBOUNDED-INDEX.md
That doc says "all 21 call sites pass literal 0". Disassembly of
`ras_reg_write_chiplet` @0x403b04 shows the first RPC argument is a **mapped**
value, not a literal 0:

    CMP R2,#2 / BCS .L1 ; MOVS R0,#2      a3 < 2  -> 2
    .L1 ITE NE ; MOVNE R0,#0 ; MOVEQ R0,#8  a3 > 2 -> 0 , a3 == 2 -> 8

So the value handed to SYS_DRV 0x7006/0x7007 is one of **{0, 2, 8}** — still
bounded, so the conclusion (no unbounded chiplet index from RAS) stands, but the
stated reason was imprecise. The `SXTBLS` signed-byte index into `dword_404838`
is guarded by `CMP R7,#2` + `LS`, so it cannot go negative.

## Status
RAS is genuinely host-reachable and now genuinely exercised. No bug found.