AXP-Resurection/docs/009-fortify-diag-v3-review-20260927.md

Status: historical. Do not use as execution order. Resume: 009-handoff-20261008.md.

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.