block.quick_zero not always sufficient to remove luks headers

Bug #1997920 reported by Michael Hudson-Doyle
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
curtin
Fix Committed
Undecided
Unassigned

Bug Description

When you set up luks on a volume, the header gets written at the start of the device and a backup copy gets written at one of these offsets:

{ 0x04000, 0x008000, 0x010000, 0x020000, 0x40000, 0x080000, 0x100000, 0x200000, 0x400000 }

(which one gets used depends on how much JSON data is included when setting up the volume I think).

Looking at this list of offsets reveals that wiping the first megabyte of the device will not touch the backup header if one of the last three offsets is chosen.

(Even more astonishingly, if you wipe just the primary header, _something_ (and I have not yet found what) notices this and repairs it, presumably by copying the secondary header over it).

Not sure what to do about this TBH. We could default to wiping just over 4MiB ...

Related branches

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Actually I think quick_zero should probably call wipefs -a before writing 1MiB of zeroes at the beginning and end.

Revision history for this message
Server Team CI bot (server-team-bot) wrote :

This bug is fixed with commit b8766b47 to curtin on branch master.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=b8766b47

Changed in curtin:
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.