sunfish-admin
deaaf42caa
Release-keys/AVB, CVE clean+hi batches, Yama/slabrand, Pro branding, bundled apps, and AXP-class product surface docs/scripts.
51 lines
2.7 KiB
Markdown
51 lines
2.7 KiB
Markdown
# Verification of clean C and X experiments — 2026-09-27
|
|
|
|
Independently parsed the binary dumps and recorded kernel/boot properties in:
|
|
|
|
- `.local-artifacts/009-v4-clean-c-20260927T190738Z/`
|
|
- `.local-artifacts/009-v4-x-persist-20260927T191143Z/`
|
|
|
|
The clean C test removes the earlier X/latch confounder: T2 has a zero failure
|
|
zone and a fresh v4 #29 boot; T3 reports kernel_panic on an intermediate v4 boot;
|
|
T4 is combo4 #16. No complete failure record is present after C. The intermediate
|
|
boot prevents localization of loss to the panic itself versus later boot stages.
|
|
|
|
The X test demonstrates that all eight complete 55-byte X records survive the
|
|
normal recovery to combo4 unchanged. It does not include the panic transition
|
|
of the C test, so it is a recovery control rather than the same full sequence.
|
|
|
|
Precision correction: T3 and T4 are NOT identical binary dumps. Their first 128
|
|
bytes match, but 7,213 bytes differ across 4 MiB, including six bytes in the first
|
|
1 KiB. Likewise X2 and X3 have 79 differing bytes, despite their complete X
|
|
records surviving intact. These differences do not negate X persistence, but
|
|
avoid describing entire zones or dumps as identical. Their cause is not yet
|
|
established.
|
|
|
|
Next diagnostic should check a full C record (primary and mirrors, expected
|
|
event/id/caller/terminator) immediately after its writer and before panic.
|
|
The success/failure result must be observable independently of the storage
|
|
whose survival is under test. A print to a console that cannot be retrieved, or
|
|
another flag only in the same alt region, would repeat the observability problem.
|
|
A control-only two-phase arm/readback/trigger protocol can expose the record
|
|
and status through adb before deliberately entering panic; document the changed
|
|
timing and validate the actual immediate path subsequently. Keep normal FORTIFY
|
|
failure behavior intact.
|
|
|
|
This establishes a narrower investigation: the writer plus normal recovery can
|
|
work; a clean panic experiment still loses or fails to produce the record.
|
|
Selective AES overwrite and a safe alternative offset remain unproven.
|
|
|
|
## Follow-up: two-phase arm/readback/panic (same evening)
|
|
|
|
Artifact:
|
|
`.local-artifacts/009-v4-twophase-x-then-c-20260927T191809Z/`
|
|
|
|
Using existing v4 (no rebuild): SysRq-x → **adb dump confirms** eight
|
|
complete `AXPDIAG1,X` records → SysRq-c (latch no-ops C write; panic runs)
|
|
→ intermediate v4 (`kernel_panic`) → combo4.
|
|
|
|
Result: pre-verified X is **absent at P3 and P4**. Independent channel was
|
|
adb, not alt-only flags. Timing caveat: adb RTT between arm and panic; type
|
|
X not C. Narrow reading: fail-zone content verified before panic does not
|
|
survive this panic/reboot path; soft recover without panic still preserves X.
|