AXP-Resurection/docs/009-fortify-v4-capture-results-review-20260927.md

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

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).