# GCP ROP -> SYS_DRV opcode 0x109A discloses SYS_DRV's distinct runtime stack guard

**Status: hardware-confirmed targeted SYS_DRV-private information disclosure
on RX 7900 XTX.** Prerequisite: code execution/ROP in the GCP TA via the
separately demonstrated FE0A foothold. This is an impact of the existing
unbounded-index defect in `feature_mask_get`; it is not a second independent
root cause. It is not direct unauthenticated host access, SYS_DRV code
execution, a device-key read or a CPU-RAM write.

## Signed-code path and chosen address

GCP ROP can issue `SVC 0xF2` to SYS_DRV service 1 with the ACL-free opcode
`0x109A`. Signed `.54` SYS_DRV handler `sub_E11A78` takes request dword 14 as
an unchecked 32-bit index and reads the first word at
`(0xE60308 + 12 * index) mod 2^32`. It returns that word in request dword 15;
dword 16 is an **AND of the next two source words**, not two raw words. As
`gcd(12, 2^32) = 4`, each word-aligned *arithmetic address* is selectable,
but the read still requires a live SYS_DRV-domain mapping and permissions.
The earlier hardware read of `0xE257D0` in
`psp_out/FINDING-FEATURE-MASK-GET-UNBOUNDED-INDEX.md` established the route.

The signed SYS_DRV image places a stack-guard word at **VA `0xE01F20`**,
containing placeholder `0x33333333` on disk. In signed `sub_E041D4`, the
prologue `LDR R0, =0xE01F20; LDR R4, [R0]` saves it on the stack; the
return path at `0xE04244..0xE0424A` compares it and calls the stack-failure
path on mismatch. The adjacent signed ARM instruction at `0xE01F24` is
`0xE59F0004`, an exact-word read control.

The calculated indices, independently checked modulo 32 bits, are:

| request index | selected SYS_DRV VA | role |
| ---: | ---: | --- |
| `0x2AAA2D02` | `0xE01F20` | live SYS_DRV stack guard |
| `0x1554D7AD` | `0xE01F24` | signed instruction `0xE59F0004` |

## Hardware observations

1. After a fresh **power-only** ATX cycle (`sysdrv_guard_cycle.log`,
   `LINK UP`), signed ASD and GCP loaded successfully, GCP session ID 1.
   Three read-only SYS_DRV `0x109A` requests read index 0 (control
   `0x00000006`/`0x0000003F`), the guard
   **`0x53399B88`**, then exact signed code `0xE59F0004`.
   FE0A reached grace `0x5A`, all fault-frame words were zero, the final
   SYS_DRV handler status and GCP FE07 were both 0 (`sysdrv_guard_read.log`).
2. Following another power-only cycle (`sysdrv_guard_compare_cycle.log`,
   `LINK UP`), a read-only three-RPC GCP ROP chain first asked ASD service 2
   opcode `0x404` index 9 for the *caller's own* GCP guard at `0x40614C`,
   then asked SYS_DRV service 1 `0x109A` for its guard and for the signed-code
   control. In that **same boot**, GCP's guard was **`0xB713D5B0`** and
   SYS_DRV's guard was **`0xF9D3D645`**; the signed code returned
   `0xE59F0004` exactly. FE0A reached grace `0x5A`, the entire fault frame
   was zero, the third handler status was 0, and final FE07 was 0
   (`sysdrv_guard_compare.log`). Neither returned guard equals the signed
   placeholder. The two SYS_DRV readings differ across fresh boots.

All scripts and full logs are under `/root/psp/hw/` on the test box:
`gcp_rop_sysdrv_guard_read.py`, `gcp_rop_sysdrv_compare_guard.py`,
`sysdrv_guard_{cycle,read,compare_cycle,compare}.log`. No TSU, SPI flash,
MMIO writes, oversized opcode `0xD`, or guessed address sweep was used.
The test-box ring remained responsive and no probe was left running.

## Impact and limits

The compromised GCP TA can recover a **different process's live stack
canary**, defeating that mitigation's secrecy for SYS_DRV despite GCP's own
separate canary being readable to GCP already. This is a direct confidentiality
breach across the GCP/SYS_DRV boundary, and is distinct from ASD opcode
`0x404`'s separately confirmed ASD-private canary disclosure
(`fw/FINDING-GCP-ASD-404-STACK-GUARD-DISCLOSURE.md`). Exploiting the guard
still needs an *independent* SYS_DRV memory-corruption bug; this read alone
provides neither SYS_DRV control flow nor access to arbitrary other process
pages. Other mapped SYS_DRV secrets, including live second-client crypto
objects, remain to be identified and verified with provenance and lifecycle
controls.