SouveraineOS/saf/device/evidence/secure_load_tz_frontier.md

# PAF · Secure-load / TrustZone frontier

> **🔴 SUPERSEDED 2026-06-29.** Secure-load is **RESOLVED** for the modem — the MSS loads clean
> (MBA boots, MPSS loads, `remoteproc running`, **zero −22 on the modem path**) via DELTA-1
> (`c2923cb49` MPSS assign-ordering). This doc is kept as the **historical −22 / fastrpc_mem
> investigation record**. The −22 that still floods the logs is the **SLPI's** SDSP heap, not the
> modem's — see `slpi.md`. The current frontier is the firmware-internal OFFLINE/52 park, not
> secure-load. (Body below is the 2026-06-26 investigation as-written.)

## 2026-06-26 (OPUS session) — mem-protect SKIP broke the boot on hardware; reverted. LOS does mem-protect differently, not skip it.

**Platform is now clean and reproducible (this part is solid, keep it):**
- ONE canonical branch **`blueline`** (was split across `mobian-sdm845-7.1` + `blueline-slpi-build`,
  neither complete — consolidated). It = Mobian `mobian-sdm845-7.1` base (mainline 7.1.1 tag +
  full 179-patch sdm845 device series: camera/imx sensors, q6voice, haptics, fuel-gauge, panels)
  + our 6 fixes. Other branches renamed `reference/mobian-7.1.1-base`, `archive/superseded-*`.
- Guard against drift: **`tools/verify-fixes.sh`** (13 checks, asserts SOURCE CONTENT not commit
  messages; covers our 6 fixes AND the inherited Mobian migrations). Run before every build.
- Build: `pmbootstrap build --src=references/linux-7.1.1-sdm845-CANONICAL linux-postmarketos-qcom-sdm845`
  (host `make` is NOT the path — build.md:7). Deploy: on-device `apk add --allow-untrusted` →
  `boot-deploy` auto-flashes `boot_a`. `uname -r = 7.1.1-sdm845`. Rollback image:
  `build-output/boot_a-rollback-20260626-1605.img.gz`.
- **Found + fixed the silent killer behind every prior "flash and test":** the phone's kernel and
  its `/lib/modules` were ABI-mismatched — `qcom_q6v5_mss` gave `Exec format error`, the modem
  driver never loaded, so the modem was dead regardless of any fix. Matched build → driver loads,
  modem remoteproc `4080000.remoteproc` now registers.

**The mem-protect skip (`need_mem_protection = false` for sdm845) is REFUTED — likely roll back:**
- It removed the `-22` from the modem path as designed — but the modem now fails EARLIER:
  `Booting .../mba.mbn → PBL returned unexpected status 0xEF110000 → can't start rproc: -22`.
  It never reaches "MBA booted".
- The r2 baseline (below) had the modem boot MBA then XPU-crash-loop at 52. So the skip REGRESSED
  the boot. `qcom_scm_assign_mem` (`q6v5_xfer_mem_ownership`, qcom_q6v5_mss.c:463/489) transfers the
  MBA region HLOS→MSS_MSA so the modem PBL can read MBA; skipping starves PBL. **The assign is
  load-bearing. The real gate is WHY TrustZone returns -22 (EINVAL), not the call's existence.**

**The LOS claim in `HANDOFF_20260626_OPUS.md` was unverified inference — treat as RETRACTED:**
- It blended mainline (`need_mem_protection`) with downstream (`subsys_vmid` / `qcom,mem-protect-id`)
  concepts into one story.
- LOS Pixel 3 runs the **downstream msm-google 4.9 kernel**; its modem loader is `subsys-pil-msa`,
  NOT mainline `qcom_q6v5_mss.c`. We have NOT pulled that source (Tier 1 still open) — so what LOS
  does was never read off real code.
- Hardware contradicts the inference: if LOS did no mem-setup and MBA self-unlocked XPU, the skip
  would have worked. It made things worse.

**PRINCIPLE (Casey, 2026-06-26): LineageOS is the ONLY known-working modem reference on this device.
Other sdm845 devices (op6 / enchilada / beryllium / shift) are IRRELEVANT to the secure-load / XPU
question — do not cite them as modem-bringup evidence. The downstream Pixel-3 stack is the authority.**

**Current phone state:** booted on `blueline` 7.1.1 (the skip build). Modem PBL-fails every boot;
SLPI crash-loops ~10s (the `-22` spam every 10s is the SDSP/SLPI hyp-assign, NOT the modem).

**OPTIONS — left for Casey to choose (not picking one):**
1. **Revert the skip** → restore the MBA-boots-then-XPU-52 baseline on the clean 7.1.1 platform,
   then work secure-load Tier 0/1 from a known state.
2. **Pull `msm-google` downstream kernel** → diff `subsys-pil-msa` mem-setup + hyp-assign vs
   mainline. Answers "what does LOS actually do" with real code (Tier 1).
3. **Downstream-kernel hybrid** (Droidian / Halium pattern) — this doc's honest realistic
   1–2 week path to working telephony.
4. **Chase the TZ `-22` directly** — why does mainline's `qcom_scm_assign_mem` get EINVAL on
   blueline (VMID / mem-protect-id / TZ expectation)? Open-ended.

---

## 2026-06-26 — TRIGGER RESOLVED: this doc is the plan. Hard secure-memory evidence captured.

The trigger condition below ("still 52, modem boots then refuses RF → the gate is the
secure-load/TZ layer → this doc is the plan") is now MET, with a concrete error string instead of
inference. On the rebuilt r2 LLVM kernel (slot A, live ssh), `dmesg` shows the modem **crash-looping
on a hardware secure-memory protection fault**:

```
qcom-q6v5-mss 4080000.remoteproc: fatal error: modem_xpu_int.c:456:[modem_sec_xpu_I]XPU violation
(also crash #1: "SFR Init: wdog or kernel error suspected")
```
and EVERY modem + slpi restart logs the shared TZ rejection:
```
qcom_scm firmware:scm: Assign memory protection call failed -22   (qcom_scm_assign_mem → -EINVAL)
SDSP fastrpc hyp-assign rejected by TZ (-22)
```

**XPU = eXtreme Protection Unit**, the hw memory guard TZ programs. `modem_sec_xpu XPU violation` =
the modem firmware touched a region the XPU forbids → its secure memory regions aren't assigned
right for mainline → crash → q6v5 recovers → repeat → never RF-inits → **52**. The fastrpc/SLPI
`assign -22` is the same mechanism (TZ refusing mainline's hyp-assign); fastrpc tolerates it, the
modem can't. **The gate is concretely the secure-memory-assign / XPU region setup — pull the
`assign_mem -22` thread.** (See modem.md TOP LEAD #11, slpi.md.)

CAVEAT (don't overclaim): this XPU crash-loop was captured on **7.1.1 r2**. The 6.16.7 / 7.1rc1
captures recorded the modem "up + QMI registers" (lead #10) — QMI still answers here too, in the
up-windows between crashes, so a single-sample `running` looked fine before. OPEN: re-check whether
6.16.7 *also* XPU-crash-loops (i.e. always-present, just not noticed) or whether 7.1.1 worsened it —
diff `journalctl -p err` across both kernels before assuming XPU is identical on the older tree.

Original status (pre-2026-06-26): **alternative, not primary.** The primary lever was Opus's
reserved-memory geometry fix (`modem_dt_rf_analysis_20260622.md` candidate #1: revert the
`sdm845-google-common.dtsi` override so MPSS = `0x7800000` / MBA = `0x96500000`, matching both
working devices). That swing did not clear the 52; the secure-load/TZ layer (this doc) is now primary.

It is written assuming the reader has `modem.md`, `modem_dt_rf_analysis_20260622.md`,
`tools/modem-online-provisioner/RESULTS.md`, and `android-capture-20260622/EFS_FINDINGS.md` in head.

## Trigger condition (the decision point)

Flash the reserved-memory DT fix to `boot_a`, cold-boot pmOS, one `--dms-set-operating-mode=online`:
- **online works** → geometry was the gate. Stay mainline; push the fix upstream (sdm845-mainline /
  pmaports), bisect the `google-common` override. **This doc is not needed.**
- **modem fails to load** (`remoteproc Boot failed`) → the firmware was signed for the old geometry;
  the override existed for a reason. Revert; geometry is load-bearing-correct as-is. Come here.
- **still 52 (modem boots clean, refuses RF)** → the gate is **not** the DT geometry. It is in the
  secure-load / TrustZone / subsystem-coordination layer. **This doc is the plan.**

## The gate, precisely (today's hard proof — do not re-derive)

Source: `tools/modem-online-provisioner/RESULTS.md` (raw QMI over `AF_QIPCRTR`, 2026-06-22).

- Modem is in **op-mode 3 = OFFLINE** (deepest non-persistent off state). Not LPM, not transient.
- **Accepts** every read, non-RF writes (DMS/NAS indication registration), and **DMS Set Operating
  Mode = RESET (0x002E mode 4) → OK**.
- **Refuses every RF-requiring transition**: online → **52 DeviceNotReady**; low_power → **60
  InvalidTransition**; NAS Set System Selection Preference (0x0033) → **25 DeviceUnsupported**; DMS
  ATEL UI-ready (0x0064) → **58** (arg-rejected, message id confirmed correct).
- After the accepted **RESET**, firmware re-initialises **straight back to OFFLINE** and refuses
  again, with **zero** sys-info/serving-system indications in an 8 s listen. The firmware is inert
  on RF by decision, not attempting and failing.

**Conclusion (raw-level, not inference):** no AP-side QMI message or ordering unlocks RF. The
choreography-replay path (`qcril_online_sequence.md`) is closed: the modem rejects the pre-online
writes *themselves* before we reach the online flip. QCRIL only succeeds on Android because the
firmware has **already self-completed RF-init** there; on pmOS it never does.

## Why this points at secure-load / TZ (the RESET argument)

A QMI RESET re-initialises the modem firmware **without re-doing the cold-boot setup** — PIL image
auth, the TZ/SCM state, the bootloader (ABL/XBL) modem init, and sibling-subsystem coordination are
all established **once at cold boot** and persist through a QMI reset. The RESET reproducing OFFLINE
tells us the gate lives in that **persistent cold-boot environment**, not in a one-shot race or a
userspace omission. That environment is exactly four things, in suspect order:

1. **DT reserved-memory geometry** — Opus's test (may already settle it).
2. **Sibling subsystem / Protection-Domain coordination** — the modem RF-init can gate on a PD
   registered over glink/pd-mapper by ADSP/CDSP/**SLPI**. pmOS DT has **no SLPI region at all**
   (absent in the `modem_dt_rf_analysis` table; Android + enchilada both carry `slpi@0x96700000`).
   Never confirmed up on pmOS. Mainline-fixable if so — *not* TZ.
3. **PIL / SCM secondary auth** — image auth clearly succeeded (modem boots), but a non-fatal
   secondary secure step (a hash-table segment, a secure-regulator vote, a TUST handshake) may not
   have completed, leaving the firmware in a degraded RF-locked mode.
4. **Bootloader / verified-boot state** — pmOS boots a hand-built `--header_version 0` image with a
   custom cmdline. If ABL sees an unverified/inconsistent chain, it can skip modem secure-env init
   that stock Android gets.

## Ranked investigation — cheapest discriminator first

### Tier 0 — free, same boot (run the instant reserved-memory fails, before any build)
1. **Mine dmesg for the secure/PD layer.** Image auth succeeded, so look for *non-fatal* warnings:
   `dmesg | grep -iE 'pas|scm|auth|hash|mba|qcom_q6v5|remoteproc|glink|pdr|pil'`.
   A non-zero `qcom_scm_pas_*` return, a PDR restart-notification timeout, or a glink intent-failure
   is a citable pointer into #2/#3.
2. **Confirm sibling DSPs are up and their PDs registered.**
   `for r in /sys/class/remoteproc/remoteproc*; do printf '%s: %s %s\n' "$r" "$(cat $r/name 2>/dev/null)" "$(cat $r/state 2>/dev/null)"; done`
   and `qrtr-lookup | grep -iE 'adsp|slpi|cdsp|sns|domain'`. If SLPI/ADSP is `offline`/absent and
   the modem waits on its PD, **that is the gate and it is mainline-fixable** (firmware path +
   remoteproc node + a `pd-mapper` entry), not TZ. This is the highest-value cheap check — the whole
   elimination tracked `remoteproc2` (modem) closely and never verified the siblings.
3. **Timing/missed-response.** `strace -f -p $(pidof pd-mapper)` and rmtfs during a QMI RESET. If
   the modem's RF-init window closes before pd-mapper/rmtfs answer a request, you'll see the missed
   response. (Likely already excluded — services are confirmed up post-boot — but cheap to confirm.)
4. **LDO13 rail state — the one rail NOT on the eliminated list.** Unlike the refuted #9 LDO set
   (ldo4/6/8/9/10/11/15/16/18/23/27, which were *absent* from pmOS), `ldo13` IS defined in
   `dt-work/blueline-pmos.dts:5466`, and on SDM845 LDO13 feeds RFFE (per OpenStick prior art — the
   `l13: voltage operation not allowed` line is benign on MSM8917 but not automatically so here).
   Static dumps show a state delta: pmOS `ldo13 … 0 0 0 …` vs Android `pm8998_l13 … 0 1 0 …`, and
   there is **no** `l13`/`voltage operation not allowed` line in the captured pmOS dmesg. **Live
   check at the moment of `online`:**
   `for r in /sys/class/regulator/regulator.*/; do n=$(cat $r/name 2>/dev/null); [ "$n" = ldo13 ] && echo "$n state=$(cat $r/state) @ $(cat $r/microvolts)uV"; done`
   — is it `on` @ 1.8 V while the modem is booted-but-refusing-RF? Then retry `online` and watch
   whether L13 flips. Likely falls to the same "modem votes RF via RPMh, not the AP framework"
   refutation as #9 — but it's the one rail never explicitly probed, so confirm live before closing.
   Plus `dmesg | grep -iE 'l13|voltage operation not allowed'` on the same boot.

### Tier 1 — diff the downstream kernel (the real working reference for secure-load)
Enchilada proves the mainline *stack* works on SDM845; it does **not** prove the secure-load code
paths work on blueline's exact modem. The authority for those is **Google's downstream Pixel-3
kernel** (`msm-google`, 4.4-era — confirm the exact branch against `boot_a`'s kernel version on
`android.googlesource.com/kernel/msm-google` before cloning). Pull it and diff, against mainline,
exactly three things:
- `drivers/remoteproc/qcom_q6v5_mss.c` — the PAS auth + mba mem-setup + reset sequence.
- `drivers/soc/qcom/{scm,pdr_interface,smem}` — the secure-channel and PD-restart path.
- modem `reserved-memory` + `qcom,smem-states` + `power-domains` in the DT.

The reserved-memory hit is the first output of this method; the SCM/auth/PDR delta is the next.
This is the strongest "honest swing" if reserved-memory alone fails — methodical, sourced, no RE
of opaque blobs. **Artifact we have but haven't used this way:** `android-reference/vendor-stack-20260621/`
(vendor RIL + MBN tree). **Artifact we still need:** the downstream kernel source tree.

### Tier 2 — instrument the firmware's own RF-init (the only inside view)
Every capture so far is userspace (QCRIL/radio logs). Nobody has captured the **MPSS firmware's own
RF-init trace** — the ordered set of things it reads and waits for. On rooted Android (slot A),
QCSuper continuous diag over **`/dev/diag`** (local — confirmed working; USB-diag is HAL-locked on
this production Pixel, per `pmos_fix_plan.md`) captures the F3/log stream during a cold boot. An
open F3 decoder (linux-msm / sdm845-mainline ecosystem; QCSuper has partial decode) turns it into
the firmware's RF-init step list. Diff which of those steps can't complete on pmOS. This is the one
instrument that can name the gate from inside the firmware; everything on pmOS only observes the
refusal. **Read-only capture — do not write EFS.**

### Tier 3 — TZ / SCM RE (the hard pole, deprioritize)
If Tiers 0–2 point at a specific SCM call or secure state: disassemble the QSEE trustlets or diff
XBL/ABL's modem init. Long, uncertain, opaque. Keep as the escalation, not the plan.

## The strategic fork (be honest about the 1–2 week telephony goal)

Mainline-native secure-load RE (Tier 2–3) is realistically **not** a 1–2 week path to working
telephony/SMS/data — it's open-ended research. If Tier 0 + reserved-memory don't clear 52, the
fastest route to "telephony on Linux like I have on rooted Android" is to use the stack that already
works on this silicon:

- **Downstream-kernel hybrid (Droidian / Halium / pmOS-downstream pattern):** boot the downstream
  `msm-google` kernel under a Linux userspace, where the modem firmware gets the exact cold-boot
  environment it expects so RF-init completes, then drive it with the vendor `qcrild` already pulled
  in `android-reference/`. Trades mainline purity for a known-good outcome. This is the realistic
  1–2 week path.

- **WRONG TURN — do not burn time on this:** "run vendor QCRIL on the *mainline* kernel via
  libhybris" will **not** fix it. QCRIL does not trigger RF-init (the firmware self-arms on Android;
  QCRIL only queries/confirms — proven by today's raw results). The gate is the cold-boot
  environment, so only changing that environment (DT → subsystems → TZ → bootloader) **or** booting
  the downstream kernel helps. Vendor-RIL-on-mainline addresses a different (already-solved) layer.

Net: **reserved-memory fix + Tier 0 (free) → if clear, stay mainline; if not, decide
mainline-secure-load-research vs downstream-kernel-hybrid on evidence, not on momentum.**

## Artifacts

- **Have:** `android-reference/vendor-stack-20260621/` (libril-qc-hal-qmi.so + 174-file MBN tree +
  selection DB); `tools/modem-online-provisioner/{qrtr_raw.py,qrtr_seq.py}` (send any QMI PDU over
  AF_QIPCRTR — validated against DMS 0x002D); QCSuper efs-shell + diag over `/dev/diag` on rooted
  slot A; `slotb-backup-20260621/pmos-7.1-boot.img` recovery; 6.16.7 known-good kernel; EFS clones.
- **Need (not yet pulled):** downstream `msm-google` kernel source (Tier 1 ground truth); an open
  Hexagon F3/diag decoder (Tier 2); possibly a devcoredump/minidump parser if SSR ever yields one
  (today it did not — modem doesn't crash, it deliberates).

## Guardrails (secure-load-specific)

- pmOS-side secure-load investigation is **read-only**: `dmesg`, `/sys/class/remoteproc/*`,
  `/sys/kernel/debug/{remoteproc,msm_subsys}/*`, `qrtr-lookup`. Safe.
- diag/F3 capture is on **rooted slot A `/dev/diag`** — read-only capture. Never write EFS or NV
  from these probes (shared unslotted `modemst1/2` — a write is seen by both slots).
- **Never flash/patch TZ, trustlets, XBL, or ABL** — brick territory. `references/edl-pixel` exists
  as last-resort recovery but **assume no EDL safety net**; behave as if a bad flash is permanent.
- Only ever touch `boot_a` / pmOS. Never slot B, `system_a`, the shared EFS, or userdata.
- Recovery image: `slotb-backup-20260621/pmos-7.1-boot.img`. Document every slot switch + flash.
- One `online` attempt per boot (a failed attempt poisons the modem until a power cycle).
- Standard hard constraints apply: pmOS is Alpine/ash (no `[[ ]]`/arrays); `rmtfs -P -s` (never
  `-r` alone); never add `pmic@4`/`pmic@5` SPMI nodes; sudo pw `147147`.

## On link-in
Not yet referenced from `START-HERE.md` or `PAF/README.md` (left for the Opus handoff to wire, to
avoid colliding with in-flight edits). If reserved-memory fails, point START-HERE's "actual
frontier" at this doc and demote the reserved-memory lever to the trigger-condition note above.