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.
Activating LUKS2 device with OPAL support is multistep process.
1) read LR state
2) unlock LR
3) activate dm device
4) in case step 3) failed lock the device
if in step 1) the device was locked.
Otherwise, in case parallel activation happened on one device
the process that failed to map dm device (device already active)
could relock the LR afterwards and effectively break already active
device.
To avoid that we do steps 1) through 4) protected by exclusive
opal lock unique per data block device configured for use with
LUKS2 OPAL support.
It affects only HW OPAL locking range KEK.
After unlocking opal locking range we cache the key in kernel
so that we do not have to pass the key again for locking the
range later (the OPAL std requires key for lock command).
Unfortunately the key remains cached in kernel even after we
lock the range on purpose during crypt_deactivate* or crypt_suspend.
This had 2 side effects:
1) key remained in system memory even though the LUKS device was
inactive (and all keys should be erased from memory).
2) when system gets suspended the locking range got automatically
unlocked later after system resume because the key caching is used
primarly to automatically unlock locking ranges that got locked
after system suspend (due to power cut off on storage device).
Since kernel does not directly support dropping cached keys we achieve
that by overwritting the original key structure with empty one.
The read in kernel crypto backend is part of user crypto API
encryption call, we have to trust it here.
JSON fix is just one place where return code was not checked
for this particular function.
It can be used to override system library where
libcryptsetup looks for external token handlers (plugins).
The parameter is required to be absolute path and it is set
per process context.
Fixes: #846.
