790666ff (Add support for allow_discrads for dm-integrity., 2020-04-09)
added TRIM support for standalone dm-integrity volumes.
This change is now reflected in the cryptsetup(8) man page.
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...
