# sOS `.54` services 4–15: registration provenance in the available signed ELF corpus

**Static scope, no new card probe.** This closes a *corpus-specific registration inventory*, not live-card service availability or all possible signed firmware images. In particular, an emulator table `[0,1,0,…]` previously observed at `0xE4A8` is **not** the card table: real GCP→ASD service-2 calls succeeded.

## Signed sOS mechanism

`sub_22B4` (`SVC 0xF2`) reads a byte from the 16-entry service table at `0xE4A8`: ID `>=16` is rejected (46), a zero entry is unregistered (47). Service 1 is permission-exempt. Other populated slots require caller cap bit `0x80`; service 3 additionally requires type 1. Thus a type-5 GCP caller could in principle address a *registered* service 4–15, subject to its message/stack-window and target process state. No evidence here grants GCP any new service.

The sole signed writer found by xrefs to `0xE4A8` is `sub_47C0`, reached through `SVC 0x74` (sOS `sub_59E8` case 35). Raw code validates the target process with `sub_1978`, bounds service ID `<16`, and writes `table[service_id]=process_id`; it does not enumerate live registrations. In sOS `.54`, the two real `SVC 0x74` sites are loader `sub_15F24:0x167A0` (register) and unload `sub_17CA4:0x17D06` (R1 is zero; deregister). The loader derives the service ID through `sub_141AC`'s signed `amd.dr.driverID` property and registers it only on the driver-image path. Ordinary TA path sets the candidate driver ID to zero instead. Independently proving trust in signed metadata and the live set of loaded drivers requires separate evidence.

## Reproducible signed-ELF survey

`python3 fw/scan_service_registrations.py psp_out/elf psp_out/versions_win/elf_all` scanned **144** local ELF paths, halfword-aligned executable spans for the `SVC #0x74` bytes and strict 24-byte TLVs (`amd.dr.driverID\0`, type 1, 4-byte value) for declared driver IDs. Results:

* **20** byte hits, all in **10 sOS ELF paths**, two per image. Both hits in signed sOS `.54` were verified as real instructions in loader/unload disassembly. A byte scan is not a CFG proof for every older build.
* **30** driver-ID TLVs, all **value 2**, all in ASD ELF paths (including signed `asd_33.0.0.163_18debcc4.elf`, at file offset `0x177D`). No property for service ID 4–15 appears in these two extracted-ELF trees.
* The signed SYS_DRV `.54` extracted ELF lacks this property; sOS's boot service-1 registration must not be inferred from the absence of an ELF TLV. The property scan does not inspect signed container metadata not present in an ELF or images outside these trees.

A further **filesystem-only** survey on the test host (no GPU access) examined all **117** `/root/psp/contall/*.bin` signed containers for the same exact property TLV. It found **17** validated driver-ID TLVs, all value **2**, all in `asd_*` containers; no other `amd.dr.driverID` string, malformed match, or non-ASD validated TLV appeared. This is a second local corpus, not a runtime table dump.

An **expanded, read-only repository inventory** scanned all **239** `psp_out/**/*.elf` paths with `python3 fw/scan_service_registrations.py psp_out`, plus all **421** `psp_out/**/*.bin` files with the same strict TLV header/value check (the 32 `.bin` paths elsewhere in this repository had no `amd.dr.driverID` string). The ELFs yielded **46** valid driver-ID property hits, all **value 2**, all ASD-named paths; every SVC-`0x74` byte candidate was in an sOS-named path (including copies and a `test_sos54.elf` of unverified provenance). The BINs yielded **57** valid hits, again all value **2**. The one generically named file, `psp_out/ta_raw.bin`, contains the identifying string `AMD-TEE ASD Driver`; the other valid hits are ASD-named files. Other sOS BINs contain the property *name* without its strict property header, consistent with their loader's lookup constant, not evidence that sOS declares itself driver ID 2. This extension checks file bytes, **not** image signatures, CFG for all builds, compressed/encrypted metadata, or the card's live registration table.

Consequently **no additional 4–15 service implementation is identified in the available local extracted ELFs or BINs**. It is *not* a finding that the live table entries are zero: live registrations, containers outside these surveyed directories, loads/unloads, and any unextracted drivers remain open. The recent GCP ROP gate-read fault (`fw/ATTEMPT-SYSDRV-53-LIVE-LOG-GATES-READONLY-FAULT.md`) specifically argues against a speculative card registry sweep with the same chain. No unsafe service registration was invoked.