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