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-v3-review-20260927.md

@@ -0,0 +1,68 @@
+# Diagnostic v3 review — 2026-09-27
+
+Checked the local generator and remote generated kernel/axp_diag_capture.c,
+attempt 20260927T084106Z, while plain-v3 was building. No build cancellation,
+source modification on the server, or device operations were performed.
+
+## Corrected
+
+- Failure handler no longer maps memory.
+- Event claim uses atomic_cmpxchg before composing the record.
+- Event path checks a previous persistent AXPDIAG1 header.
+- Milestone prefix length excludes the terminating NUL.
+- Explicit byte I/O replaces memcpy on the MMIO writer path.
+- Early mapping now precedes parse_early_param in ARM64 setup_arch.
+
+## Blocking issue: permanent mapping before allocators exist
+
+The new setup.c hook at lines 398–402 calls axp_diag_map_permanent immediately
+after paging_init. This is still inside setup_arch, before start_kernel calls
+mm_init. It even precedes bootmem_init in setup_arch.
+
+axp_diag_map_permanent releases the early map and calls ordinary ioremap.
+In this tree, arch/arm64/mm/ioremap.c calls get_vm_area_caller, which reaches
+mm/vmalloc.c:1405 __get_vm_area_node and kzalloc_node at line 1421, followed by
+alloc_vmap_area. The allocator initialization (mem_init, kmem_cache_init,
+vmalloc_init) occurs later in init/main.c:mm_init.
+
+Thus paging_init is NOT the readiness gate for ordinary ioremap. This diagnostic
+can introduce its own boot failure in the no-FORTIFY control. Do not use a
+failure of this control to draw conclusions about FORTIFY.
+
+The transition needs a deliberate lifetime plan: ordinary mapping only after
+its allocators are ready, and safe retirement of the early mapping respecting
+early_ioremap_reset. Simply relocating one call without checking that lifetime
+is insufficient. If a temporary uncovered interval is chosen, document it and
+ensure failure writers cannot dereference a stale early mapping.
+
+## Mapping attributes and persistence
+
+early_memremap uses FIXMAP_PAGE_NORMAL, whereas the permanent ioremap and
+access-ramoops use PROT_DEVICE_nGnRE. This changes memory attributes. The writer
+only uses wmb and a readback; it has no explicit cache maintenance for a cached
+early mapping. These operations alone do not establish that early cached writes
+reach reset-surviving memory. Review compatible early I/O mapping attributes
+(early_ioremap uses FIXMAP_PAGE_IO in this tree) and verify on hardware.
+
+## Remaining first-record limitations
+
+- Milestones check the latch but do not participate in its atomic claim. A
+  milestone interrupted by a failure writer can resume and overwrite the same
+  slots. Separate milestone storage from first-failure storage, or use a
+  protocol that also covers milestones and reentrancy.
+- A bare eight-byte header is treated as a complete prior failure. An interrupted
+  write that persisted only that header can suppress later captures. Validate a
+  complete record/commit indication and inspect mirrors.
+- The identifier remains per build, not per boot; archive/clear old captures
+  under an explicit test procedure before repeating the same image.
+
+The improvements are real, but v3 is not yet ready to be described as a
+validated early-capture channel. These findings concern instrumentation, not an
+identified cause of the original FORTIFY boot failure.
+
+## Status
+
+Local generator updated to **v4**: no `ioremap` until after `mm_init`; early
+map uses `early_ioremap` (IO attrs) and is kept until then; failure @0 vs
+milestones @2048; adopt only complete records. plain-v3 must not be flashed —
+rebuild control as plain-v4.