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.
The HCTR2 encryption was added to Linux kernel for fscrypt,
but as it is length-preserving mode (with sector tweak) it
can be easily used for disk encryption too.
As it need larger IV of size 32 bytes, we need to add exception
for aes-hctr2[-plain64] to be accepted in cryptsetup commands.
Fixes: #883
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.
Some Opal devices contain a bug that device reports different logical
size for block device and Opal SED layer.
This can happen for NVMe after reformatting with different LBAF (512/4096).
We will not support such configuration as Opal then calculates sizes
differently for locking range (that could lead to data corruption or
a partially unecrypted area).
String.h and stdbool.h are already included in main backend header,
no need to include them again.
Stdio.h is missing for OpenSSL and NSS backed (for sprintf).
Strings.h is missing for cipher_generic, gcrypt and OpoenSSL (strcasecmp).
Fixes: #885
Zoned device cannot be written with direct-io
and cannot be used for LUKS header logic without
significant changes. Do not allow to use them for LUKS header
but allow it for data device, as dm-crypt supports it.
Fixes: #877
This function is used with block size, where 0 does
not make sense, so failing the check is the simple way
to avoid sividion by zero.
In reality, this should never happen, but it was seen
in (unreproducible) fuzzing input.
hw-opal segment does not receive volume key for data
encryption, unlike crypt segment or hw-opal-crypt segment.
It gets key encryption key that is passed to device fw which
later unlocks the locking range key sealed in the device.
The assert may be skipped while volume key is not set.
Fixes: #875.
While properly calculated data segment needed compensation due to
misaligned partition (locking range had to be truncated),
we passed wrong value (original partition size) to LUKS2 metadata.
It has to use calculated locking range length in bytes.
Fixes: #873.
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 keyring_to_link_vk parameter must be prefixed by
either "%:" or "%keyring:" substrings provided caller
opted for text description of the target keyring.
Use -ESRCH for similar error code as with
crypt_activate_by_keyslot_context. Here it's not
confliciting with previous use for the very code but
let's make it easier and use same code for similar case.
While trying to activate device in LUKS2 reencryption
we originally used -ENOKEY error code for case
where one or more volume keys could not be unlocked or
were not provided direclty by (CRYPT_KC_TYPE_KEY or
CRYPT_KC_TYPE_VK_KEYRING) keyslot contexts.
We missed the fact the error code was already previously
used for signaling case when dm subsystem could not load
device table due to key in kernel keyring could not be
read from kernel. It's propagated by libdevmapper.
For it we replace -ENOKEY with -ESRCH for signaling the missing
keyslot context or volume key for devices in LUKS2 reencryption.
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.
If sysconf is lying, then anything can happen.
But check for overflow anyway.
Device/partition offset overflow for IV can only cause
bad decryption (expected).
For Argon2 native code (gcrypt, OpenSSL) a flag in debug output is printed.
If libargon is used, then [cryptsetup libargon2] is printed
(embedded code) or [external libargon2] for dynamic external library.
# Crypto backend (OpenSSL 3.0.11 19 Sep 2023 [default][legacy] [external libargon2])
or
# Crypto backend (OpenSSL 3.0.11 19 Sep 2023 [default][legacy] [cryptsetup libargon2])
Fixes: #851
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.
Currently we suspend top-level device only.
With OPAL, the underlying device will start to return errors
once OPAL LR is locked.
If the dm-integrity device is not suspended, regular journal
flush corrupts the device (journal write failure),
corrupting data above it.
Suspending the whole stack should fix the issue.
This can affect status command, but later also device
stack with authenticated encryption (*_dif device).
Ignoring direct-io should not be problem here.
The logic shoudl be simplified in future anyway...
