Files
AXP-Resurection/docs/009-fortify-diag-v2-review-20260927.md
T
sunfish-adminandCursor 2d145c2878 009: Polish bacon fixes, OTA host scripts, and migration docs.
Restore disable_configstore, EuiccDisabler and thermal CDEV guards, branding
and rebuild/sync helpers; document device roles, laptop migration, and Gitea.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-16 21:06:45 +02:00

3.4 KiB
Raw Blame History

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

Diagnostic v2 review — 2026-09-27

Reviewed local apply_fortify_diag.py and generated remote kernel/axp_diag_capture.c with attempt 20260927T083401Z, while the plain-v2 control build was running. No live sources or build jobs were changed.

The direction is useful: record before printing, include event/caller/build identifier, and validate SysRq-c without first writing SysRq-x. However, this implementation is not yet a validated early-boot recorder.

Required corrections

  1. Do not map from the failure handler. axp_diag_mark_event calls axp_diag_map, which calls ordinary ioremap if no mapping exists. This reintroduces mapping in panic/early context. In this tree ARM64 ioremap uses get_vm_area_caller and ioremap_page_range; mm_init initializes the slab allocator and vmalloc. Mapping after successful mm_init is a reasonable later-stage control, but the failure handler must not try to compensate for an earlier failure with that same ordinary mapping path.

  2. The previously identified early interval is still uncovered. Remote init/main.c calls setup_arch at 565 and parse_early_param at 579; mm_init and the new hook are at 600–604. A successful late SysRq test does not validate a failure in either earlier function or inside mm_init itself.

  3. First-failure retention is not guaranteed. axp_first_done is a plain integer tested before recording and set only after the writes. Concurrent CPUs or recursion can both pass the test. The event writer does not inspect an existing persistent record, despite the stated promise to preserve one; only the milestone writer does. Use a deliberate atomic/reentrancy protocol and an explicit policy for records from previous boots. A build timestamp distinguishes builds, not repeated attempts with the same image.

  4. Milestone format contains an embedded NUL. The literal AXPDIAG0,M, is 10 characters, but memcpy copies 11 and advances by 11. This copies the string terminator before the attempt identifier. Consequently strings | grep AXPDIAG0 loses the attempt/stage from the same line. Use the literal's length excluding its terminator (for example sizeof(literal)-1).

Validation scope

A complete new C record surviving the actual combo4 recovery sequence would be useful evidence for late panic capture. It would not establish early-boot coverage. Require the exact expected identifier and complete record; define how previous records are archived/cleared before repeating the same image. Keep the first failure separate from milestones and subsequent notifier events.

The capture implementation still includes linux/string.h and memcpy calls; verify the final ARM64/LTO generated writer does not depend on the FORTIFY failure path under test. no_sanitize("cfi") alone does not disable FORTIFY.

Do not interpret an empty capture from this v2 as proof against fortify_panic.

Status

Local apply_fortify_diag.py updated to v3 addressing items 1–4 (no map-from-handler; early+perm maps in setup_arch; atomic latch + durable head check; milestone sizeof(lit)-1). Residual pre-early_map blind spot remains documented in the capture plan. plain-v2 build is obsolete — rebuild control as plain-v3 before flash.