LUKS2 specification allows various size of LUKS2 metadata.
The single metadata instance is composed of LUKS2 binary header
(4096 bytes) and immediately following json area. The resulting
assembled metadata size have to be one of following values,
all in KiB:
16, 32, 64, 128, 256, 512, 1024, 2048 or 4096
All previous version of cryptsetup wiped only first 4k for LUKS1
and both JSON areas for LUKS2 (first 32k) and the allocated
keyslot area (as it contained the generated key).
Remaining areas (unused keyslots, padding, and alignment) were
not wiped and could contain some previous data.
Since this commit, the whole area up to the data offset is zeroed,
and subsequently, all keyslots areas are wiped with random data.
Only exceptions are
- padding/alignment areas for detached header
if the data offset is set to 0
- bogus LUKS1 keyslot areas (upstream code never
created such keyslots but someone could use that).
This operation could slow down luksFormat on some devices, but
it guarantees that after this operation LUKS header does not
contain any foreign data.
crypt segment data offset has nothing to do with encryption sector
size. The device may hint alignment offset which is completely
unrelated and LUKS2 validation blocks it.
When LUKS2 crypt_format() is called with detached header and custom data
alignment is requested, keyslots area is miscalculated. This mistake
is correctly detected by LUKS2 validation code but it's feature
regression with regard to LUKSv1 format.
Also rename all 'length' variable to 'size' since json
field is named size.
Make segment validation two step process. First
validate general segment object is valid and later
validate specific segment type has all necessary fields.
Without this patch older libraries won't be able to print out
(luksDump) basic information about devices created with newer
libraries.
If any segment has missing 'offset' field keyslots validation
routine could trigger segfault due to misuse of function that
expects valid 'segments' object.
Fix it by reordering validation routines.
auto-recovery triggers any time when only single correct LUKS2
header instance was found. That may be dangerous.
We should suppress auto-recovery in case blkid decided the
device is no longer LUKS device. For example if secondary (intact)
LUKS2 header was left behind and blkid declares the device is LVM2
member.
Moreover if at least one header instance is corrupted and blkid
declares device non-empty and non-LUKS in the same time, header load
operation will be aborted with error.
The code scan for the second header only if primary is corrrupted.
Let's set the possible offsets more clear.
This patch also removes 8kB header offset (that was not supported anyway).
If last write in move area failed, the keyslot is in fact destroyed.
We need to at least ensure that the whole area is there
(so write fails only for hard errors).
- do not run general LUKS2 format validation from inside the specific one
- validate luks2 json object only
- temporary move digests count restrictions, going to be fixed in next
commit
