With removal of cryptsetup-reencrypt there was
a bug introduced that broke resuming interrupted
LUKS1 decryption operation. LUKS2 code was not
affected.
We already support activation of a device using a volume key in keyring.
However, in case of multi-key devices (i.e. device with reencryption
running) we need to supply two volume keys.
If the device is in reencryption, it has two active volume keys. Linking
the VK to keyring is not supported for such devices, because the API
only counts with one key. This commit modifies the API
crypt_set_keyring_to_link to allow passing multiple keyring key names.
Also by using --test-passphrase option this patch allows
cryptsetup to check if specific token (--token-id) is
able to unlock specific keyslot (--key-slot/-S).
It uses recently added crypt_activate_by_keyslot_context
API.
Fixes: #784.
When adding new keyslot we check if provided existing
passphrase is correct first.
Since user may now select specific existing keyslot
(to extract volume key) it's no use to check any
matching keyslot. Test passphrase only for user
specified keyslot.
Unlike LUKS, plain mode uses no metadata where configured.
As we need to upgrade algorithms form time to time because of security
reasons, warn user to specify these options explicitly.
Related #758.
While resuming LUKS2 reencryption operation for
device identified by active mapping (--active-name) the
prompt about ongoing operation did not use correct
variable to get device name in the message.
Fix a path with default kernel key type assumed.
It did not check correctly for return value from
asprintf and would leak the allocated memory
instead.
We can not link internal VK kernel key in custom user
keyring. There are two reasons for it:
The internal VK kernel key description can not be
acquired via API and it may change over time
(LUKS2 reencryption).
With recent SED OPAL support volume key becomes a 'blob'
containing up to two keys (dm-crypt key for SWE and key
for unlocking SED OPAL locking range). The internal
kernel key contains only dm-crypt (if required) but
custom user keyring needs to be provided with whole
volume key (blob).
Added user specified key description for the linked key
in custom user keyring. The linked key can be reached by
the specified description after successful activation (resume).
If old util-linux is used, blkid scan can fail because disk
is already locked for OPAL.
Do the same for other internal blkid issue.
Also add some debug messages to be clear what's going on.
Add --volume-key-keyring option, which takes a name of a key in keyring,
which will be used as a VK during device activation. The key can be
specified in keyctl-compatible syntax "%<key_type>:<key_name>".
When using the --link-vk-to-keyring option, allow specifying the keyring
using the same syntax as keyctl (see "man keyctl"). E.g. "@u" for user
keyring and "%:testring" for a user-created keyring.
Add a new API crypt_set_keyring_to_link nad CLI option
--link-vk-to-keyring. This allows the user to specify ID of the keyring
where the VK should be linked.
Wipe and disable the segment. Also support the factory reset ioctl for
a complete wipe of the entire drive with a specific argument.
Signed-off-by: Luca Boccassi <bluca@debian.org>
