009: Magisk ship pack through US-S5-1 + US-S4 OpenSSH/Jelly/Gallery2.

Release-keys/AVB, CVE clean+hi batches, Yama/slabrand, Pro branding,
bundled apps, and AXP-class product surface docs/scripts.

docs/009-fortify-diag-capture-plan.md

@@ -0,0 +1,240 @@
+# Plan: captura verificable del fallo FORTIFY
+
+> Revisión posterior: [auditoría del diagnóstico del 27/09](009-fortify-diag-review-20260927.md).
+> El «canal VERIFICADO» de abajo solo demuestra parte de la persistencia:
+> SysRq-x puede dejar la misma marca que se observa tras SysRq-c. Además, el
+> escritor no funciona antes de ramoops_probe. La ausencia de AXPDIAG1 tras
+> fortify-diag **no descarta fortify_panic**, ni demuestra watchdog. Se conserva
+> abajo el historial original de las pruebas.
+
+Parte de `docs/009-fortify-bounds-boot-failure-20260927.md`.
+Referencia LAB: combo4 `#16` (sin FORTIFY). No flashear diagnóstico hasta
+tener canal de captura comprobado en esa referencia.
+
+## Hallazgos en combo4 (2026-09-27, solo lectura)
+
+| Señal | Valor |
+|-------|--------|
+| boot_completed | 1 |
+| pstore montado | sí, vacío |
+| last_kmsg / debugfs | no accesibles como shell |
+| Magisk / su | no activos (virgin AXP) |
+| cmdline | `console=null`, `androidboot.ramdump=disabled` |
+| config | `CONFIG_PSTORE=y`, `PSTORE_RAM`, `PSTORE_CONSOLE`, `ACCESS_RAMOOPS` |
+| bootreason tras recover | `reboot` / `bootloader` (no identifica el panic FORTIFY) |
+
+Conclusión: el kernel **tiene** pstore/ramoops, pero LAB no entrega traza
+útil tras el reboot a fastboot. Cambiar más CONFIGs sin canal de evidencia
+repite el bucle anterior.
+
+## Objetivo del arranque de diagnóstico
+
+Distinguir, con registro persistente o serial:
+
+1. `fortify_panic` (caller + backtrace)
+2. fallo CFI
+3. watchdog / softlockup
+4. fallo de carga de módulos / ABI
+
+Sin eso, no atribuir el logo Google a audio/WLAN ni a FORTIFY genérico.
+
+## Pasos (orden)
+
+1. **Canal de captura en combo4 (sin FORTIFY)**  
+   - Confirmar cómo Pixel 4a/sunfish expone ramoops tras panic
+     (`ACCESS_RAMOOPS`, partición `klog`/`logfs`, `ramdump=disabled`).  
+   - Probar un panic controlado mínimo en un boot **solo diagnóstico**
+     (no ship) y verificar que shell/root puede leer
+     `/sys/fs/pstore/console-ramoops*` tras el siguiente arranque bueno.  
+   - Alternativa: UART/serial o `androidboot.console` no-null si el lab lo
+     permite. Si el canal falla, no flashear FORTIFY otra vez.
+
+2. **Instrumentar `fortify_panic`** (solo en árbol de ensayo)  
+   - Antes del `BUG()`: `pr_emerg` con `%pS` del return address + stack.  
+   - Mantener el panic (no convertir en no-op).  
+   - Misma receta ksync (GOODMAKE + kernel FORTIFY+POS0+bounds).
+
+3. **Marcas CFI / módulos**  
+   - Si el log muestra CFI: seguir esa vía.  
+   - Si aparece durante `insmod`/init de vendor: comparar CRC/ABI de
+     módulos (requiere root o dump desde recovery).  
+   - Si watchdog sin fortify/CFI: otra clase de hang.
+
+4. **Empaquetador**  
+   - Quitar el `|| true` que traga el SIGILL de `magiskboot` en VERIFY, o
+     verificar el header en el laptop con el mismo SHA. Defecto de script,
+     no causa del reboot (imagen unpack OK en laptop).
+
+5. **Solo después** de una traza atribuible: cambio mínimo (call site,
+   excepción justificada, o más port). No stubs. No ship FORTIFY.
+
+## Estado 2026-09-27 (tras Rooted debugging)
+
+- `adb root` OK.
+- `vendor.ramoops.decryption.error=1` en boot normal.
+- Causa 1: `/vendor/bin/ramoops` hardcodea
+  `/sys/devices/soc/.../size` pero el kernel expone
+  `/sys/devices/platform/soc/...` (y vía `/sys/class/misc/.../size`).
+  Binario parcheado en `/data/local/tmp/ramoops.fix` para class paths.
+- Causa 2: tras eso, kernel log `ramoops: Failed to set key, -22` (EINVAL)
+  al escribir AES en sysfs. pstore sigue vacío. Remount pstore denegado por SELinux.
+- Claves RSA sí existen en `/data/vendor_ce/0/ramoops/{priv,pub}.pem`.
+- `boot_debug/crash.txt` es basura userspace antigua, no kernel FORTIFY.
+- Build `fortify-diag` (panic instrumentado) sigue en curso.
+
+## Captura post fortify-diag (2026-09-27 ~01:36)
+
+Tras flash diag → fallo → recover combo4 `#16` + `adb root`:
+
+- pstore vacío; `boot_debug/kernel.txt` vacío; sin `FORTIFY_DIAG` en claro.
+- Dump `/dev/access-ramoops` (4 MiB): entropía alta (cifrado); 0 strings útiles.
+- Decrypt sigue fallando (`Failed to set key, -22`).
+
+Prueba de canal con **SysRq-c** en combo4:
+
+- Bootloader registró `androidboot.bootreason=kernel_panic` (panic real).
+- **Aun así** pstore vacío y alt cifrado sin plaintext.
+
+Conclusión: en este LAB un `kernel_panic` **no** produce traza legible vía pstore
+hasta arreglar el pipeline AES/ramoops. El síntoma FORTIFY (antes del SysRq)
+había dejado `bootreason=reboot`/`bootloader`, no `kernel_panic` — hipótesis
+abierta: reset/wdog distinto de `fortify_panic`, o el bootloader reescribe el
+motivo al pasar por fastboot.
+
+Siguiente trabajo de captura: diag **sin cifrado** (pstore/ramoops plaintext)
+o arreglo del setkey; no más flashes FORTIFY hasta tener canal verificado con
+SysRq → fichero legible en pstore.
+
+## Captura plaintext (2026-09-27 ~01:45)
+
+Hallazgos en combo4 tras Rooted debugging + reboot sin unlock:
+
+| Señal | Valor |
+|-------|--------|
+| `dumpsys user` | `RUNNING_LOCKED`, Unlock time unknown |
+| `sys.user.0.ce_available` | vacío |
+| `/data/vendor_ce/0/ramoops` | `Required key not available` |
+| `mount \| grep pstore` | vacío tras `on boot` umount |
+| Remount manual `pstore` + `use_alt=0` | monta OK, **sigue sin ficheros** |
+| `/dev/pmsg0` + reboot | no aparece `pmsg-ramoops-*` |
+| SysRq-c | `bootreason=kernel_panic`, alt cifrado, primary vacío |
+
+Causa de sistema (no solo FORTIFY):
+
+1. `init-ramoops.rc` hace `umount /sys/fs/pstore` en `on boot` y solo remonta
+   cuando `vendor.ramoops.decrypted=true` (tras CE unlock + `ramoops -D`).
+2. Binario `/vendor/bin/ramoops` usa paths sysfs pre-`platform/` → size=-1;
+   con binario parcheado a class paths, CE locked → sin `priv.pem`.
+3. Writes de pstore van al **primary**; el carveout que sobrevive/lee userspace
+   tras decrypt es el **alt** cifrado (`/dev/access-ramoops`).
+4. `ramoops_init_prz` hace `persistent_ram_zap(primary)` tras `save_old` en
+   console/pmsg — el pipeline asume encrypt-on-shutdown a alt.
+
+Canal de evidencia (sin CE / sin AES): patch diag
+`ramoops_axp_plaintext_alt` — en DMESG oops/panic escribe magic `AXPDIAG1` +
+cuerpo en claro al **alt** (ioremap). Verificación LAB:
+
+```text
+dd if=/dev/access-ramoops bs=1M count=4 | strings | grep -E 'AXPDIAG1|Kernel panic'
+```
+
+Build canal (sin FORTIFY): `scripts/009-bisect-ksync-pstore-alt-plain.sh`
+(`PSTORE_ALT_PLAIN=1`). Probar SysRq → magic legible **antes** de otro flash
+FORTIFY.
+
+### Iteración 2 (ioremap en panic)
+
+- Alt carveout **sí** persiste: write userspace `AXPUSER1` → reboot → sigue ahí.
+- Build `20260927T001522Z` con mirror vía `ioremap_wc` **en** `ramoops_pstore_write`
+  (contexto panic/atomic): SysRq → `bootreason=kernel_panic` pero **sin** `AXPDIAG1`
+  (ioremap no es safe ahí; write silencioso no-op).
+- Fix: pre-map en `ramoops_probe` (`axp_alt_va`) + solo `memcpy_toio`/`wmb` en panic.
+  Rebuild: job `009-bisect-ksync-pstore-alt-plain2`.
+- plain2: map OK + SysRq `kernel_panic`, sin `AXPDIAG1` (aliasing WC vs `ioremap`).
+- plain3: `AXPDIAG0-probe` legible tras boot (kernel→alt OK). Tras SysRq solo
+  `AXPDIAG0` — el hook DMESG pstore no corre en este panic path.
+- plain4: `panic_notifier` + `AXPDIAG1-panic-notifier`, pero el boot siguiente
+  reescribía `AXPDIAG0` encima. Fix: no clobber si head=`AXPDIAG1`.
+  Rebuild: `pstore-alt-plain5`.
+
+### Canal VERIFICADO (plain7, `20260927T024949Z`)
+
+| Prueba | Resultado |
+|--------|-----------|
+| `echo x > /proc/sysrq-trigger` (sin panic) | `AXPDIAG1-sysrq-fixed` en `/dev/access-ramoops` |
+| sysrq-x + `adb reboot` | `AXP alt keeps prior AXPDIAG1 capture` |
+| sysrq-x + sysrq-c → `bootreason=kernel_panic` | magic `AXPDIAG1` sobrevive (cuerpo a veces truncado por reset) |
+| Metadata `/dev/access-metadata` tras panic | reescrita (claves AES); no usar |
+
+Lectura post-fallo (root, no hace falta unlock CE):
+
+```text
+adb root
+dd if=/dev/access-ramoops bs=1M count=4 | strings | grep AXPDIAG
+dmesg | grep AXP
+```
+
+## v4 canal (post review v3 2026-09-27)
+
+Ver `docs/009-fortify-diag-v3-review-20260927.md`. v3 obsoleto: `ioremap`
+tras `paging_init` (antes de slab/vmalloc) puede tumbar el control sin
+FORTIFY; attrs early cached vs IO; milestones compartían slots con el fallo.
+
+`apply_fortify_diag.py` **v4**:
+
+- Early: `early_ioremap` (FIXMAP_PAGE_IO) antes de `parse_early_param`; se
+  mantiene hasta después de `mm_init`. Permanente: `ioremap` **solo** tras
+  `mm_init`. Handler nunca mapea.
+- Layout página 0: fallo @0 (+ mirrors); milestones @2048 (zonas separadas).
+- Adoptar fallo previo solo si registro **completo** (header + `\\n` + mirror).
+- Ciego residual: pre-`early_map`; ventana breve al cambiar early→perm si el
+  VA se publica mal (v4 publica permanente antes de retirar early).
+
+Validación control (sin FORTIFY) — media/tardía; no prueba pre-`early_map`:
+
+0. Wipe zona fallo: `dd if=/dev/zero of=/dev/access-ramoops bs=4K count=1`
+1. Flash `pstore-alt-plain` v4, boot, `adb root`.
+2. Milestones: `strings | grep AXPDIAG0` → `...,early_map` / `perm_map` /
+   `mm_init` (offset distinto; pueden coexistir con un AXPDIAG1).
+3. **Solo** SysRq-c (sin `x`).
+4. Recover combo4 → `AXPDIAG1,C,<attempt>,0x...,sysrq-c` completo.
+5. Solo entonces fortify-diag v4.
+
+### Review resultados v4
+
+Ver `docs/009-fortify-v4-capture-results-review-20260927.md`,
+`docs/009-fortify-v4-clean-tests-verification-20260927.md`, y artefactos:
+
+- `.local-artifacts/009-v4-clean-c-20260927T190738Z/`
+- `.local-artifacts/009-v4-x-persist-20260927T191143Z/`
+- `.local-artifacts/009-v4-twophase-x-then-c-20260927T191809Z/` (adb
+  readback then panic: pre-verified X lost by P3)
+
+### LAB 2026-09-27 (plain-v4 `20260927T084531Z`) — hechos vs hipótesis
+
+**Demostrado**
+
+- Writer de first-failure en vivo: SysRq-x →
+  `AXPDIAG1,X,20260927T084531Z,0x...,sysrq-x` @0 (+ mirrors).
+- Milestone slot @2048 recibe `AXPDIAG0,M,...,panic_reg` (último stage;
+  sobrescribe stages previos en el mismo offset).
+- Tras SysRq-c (arranque sin `x` previo) + recover combo4: **no** hay
+  `AXPDIAG1` en ninguno de los 8 slots de fallo; @0 es opaco.
+
+**No demostrado / correcciones**
+
+- **No** hay, en el código revisado, una rutina de *cifrado del alt al
+  entrar en panic*. Sí hay camino de descifrado del alt. «Desactivar
+  encrypt en el kernel» no apunta aún a una función identificada; no usar
+  eso como siguiente paso.
+- Que `panic_reg` aparezca @2048 tras combo4 **no** prueba zona segura ni
+  supervivencia al panic: combo4 no escribe `AXPDIAG*`, pero un arranque
+  intermedio de **v4** regenera el mismo `panic_reg` con el mismo attempt
+  id. Hace falta attempt id distinto por boot, o wipe + leer sin otro boot
+  v4, antes de atribuir persistencia.
+- El latch `axp_first_latch` es **solo RAM**: un wipe del dump no lo
+  resetea. Si en el mismo arranque se hace SysRq-x y luego SysRq-c, `c`
+  no escribe. Las pruebas `c`-only válidas requieren wipe **y reboot**
+  (o imagen nueva) sin `x` previo en ese boot.
+- Causa de @0 opaco tras `c` (sobrescritura, fallo de escritura, otro
+  productor): **abierta**.