sunfish-admin
deaaf42caa
Release-keys/AVB, CVE clean+hi batches, Yama/slabrand, Pro branding, bundled apps, and AXP-class product surface docs/scripts.
69 lines
3.4 KiB
Markdown
69 lines
3.4 KiB
Markdown
# 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.
|