# The leaked AMD/Xbox SP tree: what it is worth, and how it must not be used

`~/src/amd_data` is a Microsoft Xbox security depot (`//depot/yukon/security/`,
projects `xsec`/`xbsec`) containing genuine AMD source — headers carry
*"Trade secret of Advanced Micro Devices, Inc. Copyright (c) 2010"*. Dated 2014,
so Durango/Kryptos APU era.

Of 28 GB, ~23 GB is `tools/` (toolchains, gcc HTML docs) and ~1.5 GB is build
drops. The signal is `sp/hwinit/`, `scp/`, `inc/` — roughly 60 MB.

## The lineage is measured, not assumed

`sp/hwinit/ccp.h` engine IDs against our independently reversed `pspemu/ccp.py`:

| ID | AMD 2014 source | our model | |
| --- | --- | --- | --- |
| 0 | AES | AES | match |
| 1 | XTS_AES_128 | XTS-AES | match |
| 2 | **TRNG** | **DES3** | differs (known generational change) |
| 3 | SHA | SHA | match |
| 4 | RSA | RSA | match |
| 5 | PASS_THROUGH | PASSTHRU | match |
| 6 | ZLIB | ZLIB | match |
| 7 | ECC | ECC | match |

Seven of eight match exactly. That agreement is the evidence for treating the
subsystem as an ancestor; it is why constants below are trusted at all.

## Taken into the emulator (verified, not copied)

* **SHA-224 = CCP SHA type 2.** The source enumerates `SHA_1_FUN=1`,
  `SHA_224_FUN=2`, `SHA_256_FUN=3`; type 3 agrees with what we had already
  reversed, which is what makes 1 and 2 credible. No firmware we hold requests
  SHA-224, so it is **verified against hashlib** (empty, short, multi-block,
  256-byte inputs) in `tests/test_smoke.py` rather than trusted.
* **SHA-1 is named but deliberately NOT implemented.** It needs a 5-word state
  and a different compression function; nothing we hold requests it. Naming it
  makes an encounter report the real reason instead of "unsupported type 1" —
  a wrong implementation would be worse than an honest refusal.
* **`CMD_ERROR_NAMES`**, the full `CCP_CMD_ERROR_*` table (0x00–0x25). Queue
  failures now report what the hardware said. Codes outside the table render as
  `UNKNOWN(0x..)` rather than being silently mapped to something plausible.

Operationally interesting entries: `0x14 IDMA_PROTECTION_FAULT` and
`0x24 ODMA_PROTECTION_FAULT` — a CCP DMA into protected memory is *reported*,
not silently dropped. That matters to the confused-deputy-writer angle.

## Also present, not yet used

* `sp/hwinit/fuse.h` — fuse addressing `{Chain:8, Offset:10}`; chains
  `SERIAL_NUM=1`, `GNB=4`, `ESRAM=9`. Relevant to the dormant P2 fuse work.
* `ccp_job_t` field semantics — `soc`/`ioc`/`wfw`/`eom`/`init`/`prot`/`key_id`,
  and the memory-type field (`0` external, `1` **internal key storage**,
  `2` LMI, `3` reserved).
* `scp/.../syscalltable.c` — an SVC dispatch table for an AMD-built ARM security
  kernel; structural comparison for the sOS SVC work.
* `psp_pccp_reg.h` — PSP CCP register bitfields, including TRNG control.

## Not present

No `$PSP` directory format (zero hits) — nothing for the IFWI parser. No
sOS/sys_drv lineage. Only three files mention SMN.

## The trap: this is a vocabulary source, NOT an address source

The `mm*`/`ix*` offsets are for a 2014 Xbox APU. `mmPSP_TMR_INTSTS = 0x1E00008`
is almost certainly not our card's address.

Lifting addresses from here would be the same version-mismatch failure that has
already cost this project twice: the v53 symbol map being wrong for the TSU
subsystem, and `bl_set_boot_stage`'s `0x2161C` control coming from a different
build. Field meanings and error enumerations survive generations; addresses do
not. Anything numeric taken from this tree needs a per-register decode control
on our own hardware before it is believed.