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-v4-capture-results-review-20260927.md

@@ -0,0 +1,99 @@
+# v4 capture results review — 2026-09-27
+
+## Result
+
+The capture channel still has no validated panic-survival result. Do not infer
+that AES selectively overwrites offset 0 while sparing offset 2048, and do not
+choose a high offset as a safe region without establishing its ownership and
+observed persistence. No FORTIFY-specific failure has been captured yet.
+
+Reviewed Cursor's recorded experiment summaries, v4 generated source, the kernel
+ramoops implementation, sunfish DT and init.ramoops.sh. Read the current LAB alt
+region while LAB was running combo4 #16; no device writes, flashes or reboots.
+
+Current 4 MiB capture SHA-256:
+`24bbccbf4ed1271bc0950167f4a7921e2a79c534ad735d506ebb504a0353f310`.
+It contains `AXPDIAG0,M,20260927T084531Z,panic_reg` at 2048, and no AXPDIAG
+marker at the eight expected failure offsets 0,128,256,384,512,640,768,896.
+
+## Unsupported steps in the current explanation
+
+1. Random-looking bytes are not proof that the current test caused encryption.
+   Without a before/after snapshot from the same attempt, they can be old data,
+   overwritten data or ciphertext. The stored old captures are from different
+   experiments and cannot establish this particular transition.
+2. The milestone is written again on every v4 boot, with a build-time identifier
+   shared by every boot of that image. Cursor reports that the first SysRq-c
+   returned with kernel_panic, followed by further live v4 tests. A regenerated
+   milestone is therefore an alternative to survival across panic. Final
+   recovery to combo4 does not resolve its age across the preceding boots.
+3. The v4 latch is in ordinary kernel RAM. SysRq-x sets it. Clearing the alt
+   region with dd does not clear the latch in the running kernel. A subsequent
+   SysRq-c in that same boot will skip recording, even if the region looks
+   empty. Cursor's summary says a clean retry occurred but does not establish
+   the full clear/reboot/no-X sequence; this remains a confounder, not a proven
+   mistake in the executed sequence.
+4. Current fs/pstore/ram.c exposes ramoops_decrypt_alt: it reads cxt->size,
+   decrypts with crypto_aead_decrypt, and copies the whole buffer back only on
+   success. This is not a panic-time encrypt routine. The inspected sunfish
+   init script invokes ramoops -D and then ramoops -g -l -c. No kernel panic
+   encrypt implementation was identified by these searches. Firmware ownership
+   remains possible, but unproven. Disabling kernel decryption would not by
+   itself demonstrate that an external encryption path was disabled.
+5. The DT declares a 4 MiB alt ramoops reservation, not a separately reserved
+   diagnostic high-offset region. No offset within it is currently shown safe.
+
+## Next useful test: preserve attribution before another rebuild
+
+Use the existing no-FORTIFY control to establish a documented timeline. Keep
+SysRq-x and SysRq-c experiments in separate boots, and archive full dumps,
+kernel identity, and boot reason at each available observation point.
+
+- Archive and clear the diagnostic region BEFORE booting the control; then
+  verify the region contains no complete old failure record. Do not clear only
+  the persistent bytes after X and assume the in-memory latch has reset.
+- Run a fresh boot with no X. Archive the pre-C contents; execute only C.
+  Recover directly to combo4 when possible, recording any intermediate v4
+  boot or forced hardware reset. A forced reset is a separate experimental
+  condition from the automatic panic reboot.
+- Compare the full before/after bytes, including mirrors and milestone area.
+  Do not use the same-build milestone alone as evidence of survival.
+- Independently test X persistence through the SAME recovery sequence. This
+  distinguishes a writer that works in a live kernel from storage that survives
+  the recovery path. It does not replace the fresh-C test.
+
+If fresh C still leaves no attributable record, a control-only diagnostic can
+read back/validate the exact committed C record immediately before panic and
+report or expose that result while observable. This separates failure to write
+from later loss. It must remain a diagnostic experiment, not a swallowed panic
+or a production hardening change.
+
+Only after identifying which transition loses a verified record should the
+next patch change its storage or intercept an identified writer. A separately
+reserved region needs a board/firmware-compatible design; an arbitrary high
+offset is not a substitute for that evidence.
+
+## Remaining source limitation
+
+v4 composes up to 128 bytes but caps persistence at 120; long tokens can lose
+the terminating newline required by adoption. This does not explain the short
+sysrq-c/sysrq-x records, but must be fixed for general panic messages.
+
+The original FORTIFY cause remains open. Diagnostics v2/v3 had concrete
+implementation defects; v4 fixes those major defects and boots, but its test
+results still do not establish a working early-panic channel.
+
+## Follow-up LAB (same evening, documented)
+
+Clean C-only:
+`.local-artifacts/009-v4-clean-c-20260927T190738Z/` — clear → v4 boot (no X)
+→ C → **intermediate auto v4 reboot** (`kernel_panic`) → combo4. No
+`AXPDIAG1` at T3 or T4. Fail zone 0:1024 went from all-zero (T2) to opaque
+non-`AXPDIAG1` bytes (T3=T4). Latch/X confounder ruled out for this run.
+
+X persistence (no panic):
+`.local-artifacts/009-v4-x-persist-20260927T191143Z/` — `AXPDIAG1,X,...`
+survives combo4 recover; fail[0:128] identical before/after.
+
+Next: distinguish “C never committed” vs “lost across panic” with a
+control-only pre-panic readback of the committed C record (see above).