We zero data parts of the test images to make them as small as
possible and for the latest startup key image I deleted bigger
portion of the NTFS header by accident which caused older blkid
on CentOS/RHEL 6 to not identify the NTFS filesystem on the
cleartext device.
These performance options, introduced in kernel 5.9, configures
dm-crypt to bypass read or write workqueues and run encryption
synchronously.
Also support persistent storage of these flags for LUKS2.
The issue can be reproduced very easily by starting 2 veritysetup processes
at the same time:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814021
device-mapper: create ioctl on img CRYPT-VERITY-cea03b7bc5b94e088e5754ff33be71d6-img failed: Device or resource busy
Verity device detected corruption after activation.
Command successful.
Command failed with code -1 (wrong or missing parameters).
Note how veritysetup open is reporting -EINVAL as the return code.
After the fix:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814649
Verity device detected corruption after activation.
Command successful.
Device img already exists.
Command failed with code -5 (device already exists or device is busy).
Introducing new version of crypt_reencrypt symbol including
previously missing usrptr parameter. This change should be
backward compatible for existing libcryptsetup users
until next recompilation where it needs to be fixed.
If users want to use blake2b/blake2s, the kernel algorithm name
includes dash - like "blake2s-256".
Because we use dash as a separator, this patch adds an exception
for this case.
Fixes: #581.
When creating LUKS2 header with specified --offset much larger
then LUKS2 header size we needlessly also wipe (allocate up to
--offset) much larger file than needed.
The iv_large_sector option is supported in dm-crypt since introduction
of larger sectors encryption.
It counts Initialization Vector (IV) in larger sector size (if set) instead
of 512 bytes sectors.
This option does not have any performance or security impact, but it can be
used for accessing incompatible existing disk images from other systems.
(It is used internally in BitLocker compatibily code).
This patch allows it to be used for plain type device, so users
can manually map foreign disk images.
Only open action with plain device and sector size > 512 bytes is supported.
We need to use the iv_large_sectors flag and correct sector size
for the crypt segments for these devices. Used sector size is
read from the device header. This commit also adds two new test
images with 4k sectors.
Fixes: #557
Adds option to dump content of LUKS2 unbound keyslot
in to a file:
'cryptsetup luksDump --unbound --master-key-file /file -S 12 /dev/luks2'
or to terminal:
'cryptsetup luksDump --unbound -S 12 /dev/luks2'
Parameters -S (specific keyslot) is mandatory with --unbound.
Fixes: #549
Threre asre some situatiuoins when randomized image is nor repairable
by FEC data. Let's use completely deterministic image creation (fixed salt and uuid).
FIXME: The FEC Reed-Solomon code is doing something strange here, this
kind of erasure should be always repairable.
Previous fix for longer passhphrases increased maximal
passphrase length even if it was not needed, for example
if used with SHA256 hash in combination with keyfiles.
This patch tries to fix the problem, so some older volumes
can be opened again.
Also some test images are added for regression testing.
Fixes: #542.
If LUKS1 payload offset (data offset) is not aligned to
4KiB we create unaligned keyslots area in LUKS2 metadata
during upconversion. Unaligned keyslots area is not valid
from LUKS2 perspective. Fix it by properly aligning future
keyslots area and also check if LUKS1 keyslots area fit
in the new one.
Fixes: #534.
With LUKS1 we returned pbkdf values even for inactive keyslot.
Only iterations count was wrong. Remaining values are not
specific keyslot bound with LUKS1.
Fixes: #528.
Other APIs use the root hash in place of keys when using verity
devices, so do the same for crypt_volume_key_get to allow users
to retrieve the root hash of an active verity device.
Use it in veritysetup status to print the root hash.
[Patch slightly modified by Milan Broz]
When integritysetup formats a device with hash or HMAC integrity checksums,
it requires explicitly tag size entry from a user (or default value).
This leads to confusion and shortened tags.
This patch calculates tag size according to real hash output, and
if tag size is specified, it warns if these values differ.
Fixes: #492.
