Functions related to uploading/unlinking volume keys in user
requested kernel keyrings are named as follows:
crypt_single_volume_key_load_in_custom_keyring
crypt_volume_key_load_in_custom_keyring
crypt_unlink_key_from_custom_keyring
helpers for unlinking LUKS2 volume keys from thread keyring:
crypt_unlink_key_from_thread_keyring
crypt_unlink_key_by_description_from_thread_keyring
The volume key structure may often be in configuration
where 'key' member does not contain real data. Some
examples:
- volume key acquired by querring device-mapper where key
was originaly passed by kernel keyring reference.
- volume key allocated by crypt_alloc_volume_key(size, NULL)
With this patch access to internal 'uninitialized' data result
in failed assert().
For use cases where key data are not needed (keyring reference wrapper,
key length info only) we do not have to allocate and lock the safe
buffer in memory.
Further improvements might to completely hide the volume key internals
and access only via setter and getter functions.
Switch current code to use following volume key helpers
for accessing internal properties:
crypt_volume_key_length(), crypt_volume_key_get_key(),
crypt_volume_key_description() and crypt_volume_key_kernel_key_type()
Remaining direct access to volume key internals will be dealt with in
later commits since it requires some further changes.
This patch add support for setting of integrity key size
for LUKS2 devices.
It adds new (optional) JSON "key_size" attribute in segment.integrity JSON object.
If not set, the code use hash length size (backward compatible).
For LUKS2, we do not allow smaller keys than 128 bits.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch implement support for setting specific integrity key size
option in dm-crypt, available since dm-crypt version 1.28.0.
This can be used for setting non-standard HMAC key length.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This is only preparation for an extension later, however, the volume
keys should not be unloaded unconditionally from keyring.
Note that all other places dropping keys already check that keys
were uploaded through key ID setting.
(And for suspend unconditional unlink make sense too.)
The key_decripion always contains only a key name,
keyring then contains type of keyring as defned un keyring utils.
For now, only LOGON type is used in commands, it will be extended later.
The luks2_internal.h contains specific JSON implementations while
luks2.h is generic. Code outside of luks2/ dir should not use internals.
Also luks2.h includes functions prototypes that are used from setup.c.
The function did not work properly if keyslot parameter
was set to CRYPT_ANY_SLOT and returned always error.
But it will be used later when we need to find if there's
at least one keyslot asigned to a specific segment.
During the initialization phase future moved data segments
were incorrectly assigned (hardcoded) to digest with id 0.
When the default segment was assigned to a different value,
the initialization failed and was aborted.
This patch fixes the issue by assigning intermediary segments
to corect digest id.
Reported-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
Hard abort is justified here. The online reencryption on
data devices that do not support O_DIRECT io flag is
dangerous and leads to data corruption. This should be
impossible to hit due to a patch that handles it
in initialization phase. Better safe than sorry.
Verify the data device supports O_DIRECT io flag in
the initialization phase. Online reencryption is not
safe unless we can read and write the data in direct
mode.
For LUKS2 headers with non zero data offset LUKS2_wipe_header_areas
will always erase the smallest from following:
- metadata device size
- data offset value
- maximal LUKS2 metadata size (twice 2 MiBs json area including 128 MiB for
binary keyslot areas) even with detached header.
For zero value data offset (LUKS2 header can not be restored back to
data device), we erase up to smallest from the following values:
- metadata device size
- maximal LUKS2 metadata size (twice 2 MiBs json area including 128 MiB for
If an unbound keyslot is present (e.g.. slot 0 usual slot, slot 1 unbound),
the query loop could return ENOENT (keyslot not valid for segment) and this
will stop epxected retry for slot quewry (--tries option).
If any previous slot rerutned EPERM (no valid passphrase), prefer
this return code.
This patch switches code to SPDX one-line license identifiers according to
https://spdx.dev/learn/handling-license-info/
and replacing long license text headers.
I used C++ format on the first line in style
// SPDX-License-Identifier: <id>
except exported libcryptsetup.h, when only C comments are used.
The only additional changes are:
- switch backend utf8.c from LGPL2+ to LGPL2.1+ (as in systemd)
- add some additional formatting lines.
The opal_range_check_attributes_fd function expected both
offset and length parameters of a LR to be passed in sectors (512B).
During format we passed it wrongly in OPAL blocks which caused
bogus check provided OPAL block size was not 512B.
Fixes: #871.
The key might be needed in activation of ordinary LUKS2 device
provided the recovery took place in before device activation
and actually finished LUKS2 device reencryption.
Fixes: #863.
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.
