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...
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.
Unfortunately there is currently no way how
to make difference between device lacking SED OPAL support
state and kernel missing SED OPAL support via disabled interface
via configure option.
