Repository navigation
Tags
Tags
v3.21.8-16: one btrfs across p20 + p21, metadata raid1, no md
Only p19/p20 were ever writable: the allowlist sat behind a filesyste… …m probe Second safety gap, found the same way as the first - by writing the test before the hardware session rather than during it. install-alpine promised in its own header that p1 and the A/B/GOLD slots are never modified. What it actually enforced was: p1 refused unconditionally, and a 19|20 allowlist that was reached ONLY when the target partition already contained an ext4 filesystem. So --root-part 9 against a GOLD firmware slot that did not happen to hold ext4 would have been formatted. The contract in the header and the contract in the code were different, and only the code ran. The allowlist now sits where the partition table is already known, right after the GPT detection, so the partition number is checked before anything is probed for a filesystem. The deeper copy was deleted rather than kept: two copies of one rule is how they drift apart, which is the same disease this project has been removing all session. The check is deliberately gated on the factory table. On a blank disk ROOT_DEV is forced to $DISK1 and the number is irrelevant, so --blank with any --root-part still works. tests/test_rescue_refusal.sh now covers 17 cases. The eight new ones drive the allowlist with a GPT-shaped disk: p19 and p20 write, and p1, p2, p9, p18, p22 and p24 are refused, plus p9 on a blank disk which correctly proceeds. Also confirmed against the extracted block rather than only through the test. Two safety gaps in the two most dangerous guards in the project, both found without a WDMCH, both of which would have been discovered by a user standing at a serial console trusting a property that did not exist.
PreviousNext