Wipe: pick the erase primitive from device class, fail loud when it doesn't run

[mastacontrola]

Fixes #125.

FOG's NVMe wipe has not erased anything since Feb 2023, and would report success either way. Both halves are fixed here, and the NVMe sanitize path is now validated on real hardware.

The no-op erase

fog.wipe ran nvme format $hd --force with no --ses. That field defaults to 0 — "no secure erase operation requested" — so the controller reformats namespace metadata and is under no obligation to erase user data. Many drives deallocate on format and a deallocated read commonly returns zeros, which is exactly why this looked right in testing. Every NVMe wipe FOG has performed through this path should be assumed non-erasing.

This is a regression of a fix, not a missing feature. #61 (closed 2023-02-28) had the reasoning right — NVMe isn't frozen by UEFI, so nvme-cli is the correct tool — and missed one flag. The pre-#61 behaviour was shred: slow and hard on the drive, but it erased. The 2023 change traded a real wipe for a fast one and the speed was mistaken for the improvement.

Nothing checked whether the wipe ran

No branch of the case inspected an exit status. A failed format, a shred that died on a bad sector, or an unknown wipemode matching no branch at all each fell through to echo "Wiping complete." and reported success to the server. Same class as ADR-0003, worse consequence: a mis-imaged disk is found when the machine won't boot; a disk wrongly believed wiped is found by whoever finds the data on it.

Compounding it, wipemode="nvme" was forced for NVMe targets before the case, so an operator choosing full — the strongest option — got the metadata-only format. The strongest choice silently became the weakest.

What changed

The primitive is selected from device class, not a name match, in wipeDisk(). fog.wipe is reduced to countdown, one call, and handleError on non-zero.

class	fast	normal	full
nvme	format --ses=2 (crypto) if FNA bit 2, else --ses=1	format --ses=1	sanitize --sanact=2 if SANICAP bit 1, else format --ses=1
ssd / unknown	dd zeros over metadata	shred -n 1 + warning	shred -n 3 -z + warning
hdd	dd zeros over metadata	shred -n 1	shred -n 3 -z

unknown is treated as possibly-flash, because the failure that matters is assuming flash is a platter, not the reverse. A bare nvme format with no --ses is never issued by any path.

Sanitize is preferred but never blindly

format --ses=1 is the floor everywhere: universally supported, synchronous, meaningful exit status, NIST SP 800-88r1 Purge. Sanitize is preferred for full because it covers over-provisioned and unmapped blocks no namespace-level op can reach — but it's optional, async, and cannot be canceled once started.

That last point drives a hard rule: once a sanitize starts, falling back to format is not allowed. The controller rejects format with 0x1d SANITIZE_IN_PROGRESS, so the fallback cannot succeed — attempting it converts a working wipe into a reported failure. nvmeSanitize() returns 0 (confirmed complete), 1 (nothing running, fallback legal), or 2 (started, unconfirmable). Only rc 1 falls back. rc 2 means the drive is unknown, not unwiped, so FOS claims neither outcome and points the operator at nvme sanitize-log. SSTAT 3 needs sanitize --sanact=1 Exit Failure Mode before format is legal at all, since 0x1c is defined as "no recovery action has been successfully completed".

Hardware validation

Tested on a real NVMe drive. Old build:

Starting disk wipe of /dev/nvme0n1 using nvme format …
Success formatting namespace:1
Wiping complete.

Seconds, no erase — the SES=0 no-op reproducing exactly. New build:

Erasing /dev/nvme0n1 with an NVMe sanitize block erase (sanact 2)
Sanitize cannot be canceled once started; it will resume after a power cycle.
Sanitizing /dev/nvme0n1 … 100%
Wiping complete.

An earlier hardware run caught a real bug this PR also fixes: the poll parsed .sstat expecting a flat {"sstat":2,...}, but nvme-cli nests under a device-name key, makes sstat an object, and renders status as a string. It bailed on poll 1, fell back to a format the controller rejected, and told the operator "This disk still holds its data" about a drive that was sanitizing correctly. The stub had encoded the same wrong assumption as the parser, so 24/24 tests passed against code that could never work on hardware. The stub is now transcribed from json_sanitize_log() in nvme-cli's nvme-print-json.c, and the harness requires real jq.

Verification

tests/checks/wipe.sh — 29 passed, 0 failed. Negative controls confirm each fix is load-bearing and independent: bare nvme format --force fails 6, swallowing format's exit status fails 2, swallowing shred's fails 1, moving mode validation behind the class dispatch fails 4, reverting the sanitize-log parse fails 5, allowing the post-sanitize fallback fails 3.

Validated: the NVMe full sanitize happy path, end to end on hardware.
Not exercised on hardware: the format fallback paths, SSTAT 3 recovery, rc 2, and the SATA/HDD paths. These are covered by stubs only.

Known gap: SATA SSD is disclosed, not fixed

shred on a SATA SSD is not a guaranteed erase, for the same wear-levelling reason the format wasn't. The right primitive is ATA SANITIZE, and it isn't here. #40 (2020) tried and found drives frozen despite advertising enhanced erase; #61 (2023) reached the sharper conclusion that the standard unfreeze is suspend-to-RAM and FOS has no suspend to offer — it's a login shell in an initramfs, not a system with a power-management stack. That's an open problem, not an unwritten function. So SATA SSD users now get a loud warning that the overwrite may leave data recoverable and that the drive's own secure erase is the remedy. Rotational disks deliberately don't get the warning: overwriting genuinely erases them, and a warning shown everywhere is one operators learn to ignore.

Consequences

• NVMe wipes now take real time. Minutes for format, potentially much longer for sanitize, where the old no-op returned in seconds. That speed was the bug.
• full on NVMe may be uncancelable once sanitize starts. The countdown is the cancel window.
• A failed wipe is now a failed task. Runs that previously reported success while erasing nothing will now handleError. These were always failures; they'll now look like new ones.
• Unknown/empty wipemode refuses rather than silently doing nothing. Deliberately not defaulted to normal — guessing a destructive action on malformed input is its own hazard. The legacy fastwipe alias still works.
• No FOG-server change needed. Mode values and the Post_Wipe.php contract are unchanged.

🤖 Generated with Claude Code