Create lower level TCRYPT device (underneath the toplevel one)
with CRYPT_SUBDEV prefix so that in later release we
can use general dependecies deactivation code.
The newly activated stacked TCRYPT devices will not correctly
deactivate with older pre 2.8.0 release.
When activating dm-integrity device underneath dm-crypt
with LUKS2 authenticated encryption mode, annotate the
device correctly with CRYPT_SUBDEV prefix. This will help
us to clearly identify dependent device underneath LUKS2 top
level device and we can unify the deactivation code in future
releases.
We have general code deactivating dependent devices already for
LUKS2 reencrytion.
Deactivating newly created devices with pre 2.8.0 cryptsetup
will issue warning about missing devices but the deactivation
will succeed.
This hack tries to workaround situation when small VMs without swap
causes OOM. This hack will be removed one day completely...
Also remove confusing warning about possible crash.
With OpenSSL Argon2 backend this behaves much better, but it still
can cause OOM instead od returning ENOMEM.
Anyway, the warning message causes more problems that it solves.
Fixes: #896
Unfortunatelly the benchmark function cannot return
corrected parallel cost, so it must fail.
Note that some backends (like OpenSSL) also limits maximal thread count,
so currently it was clapped at 4 for luksFormat and 8 for benchmark.
This patch set it all to PBKDF internal parallel limit.
Use dm_get_active_iname that should be used on all places.
This function return integrioty device name if it shoudl be
maintained by LUKS2 context directly.
Code must not touch other devices that it does not own.
The type cannot be converted to LUKS1 if there is an unbound keyslot.
It is already covered by digest count check, but in some specific
use cases the explicit check can catch a new problem.
While adding new unbound key there is a check whether the
passed key parameter matches current volume key or not. If it
matches the existing volume key we handle the LUKS2 keyslot
addition as an ordinary LUKS2 keyslot (not unbound).
If the check failed we continued with the operation of adding
LUKS2 unbound keyslot. But we did not check if the error
was not a more general issue for example with in-memory metadata.
Let's contine with the operation only if the return code is
expected -EPERM (not matching digest) or -ENOENT (not matching any
existing unbound key).
If there is no digest associated with segment,
for example during reencryption mode encrypt initialization,
return -ENOENT in LUKS2_digest_verify_by_segment.
With this commit reencryption can run without any active
keyslot containing current (or optional future) volume key.
In such case new volume key must be provided via CRYPT_KC_TYPE_KEY
keyslot context and by adding CRYPT_REENCRYPT_CREATE_NEW_DIGEST flag in
reencryption parameters during reencryption initialization in
crypt_reencrypt_init_by_keyslot_contexts.
The new flag can not be combined with CRYPT_REENCRYPT_RESUME_ONLY
flag.
It allows to get former (old) volume key size
from LUKS2 device in reencryption state when
there's at least one keyslot containing encrypted
volume key.
Let's check block device size required for Merkle tree and superblock.
If it is a file, allocate the size in advance with fallocate.
This should print better error message if hash device is too small.
Fixes: #808
crypt_activate_by_keyslot_context() returns -EPERM
when key was passed either by CRYPT_KC_TYPE_KEY or
CRYPT_KC_TYPE_VK_KEYRING and does not match the digest
stored in metadata.
Sometimes caller might want to verify if the passed
keyslot contexts matches the effective volume key
or not without the error message. It can be
printed from command line tools when needed.
PSID length is de-facto always 32 alphanumeric characters.
Limit the read of PSID from keyfile to this limit
(if not set by explicit size option).
This eliminates mistakes when the keyfile contains EOL characters.
Also, some OPAL drives accepts PSID with any suffix, this patch
unifies processing (it works everywhere the same).
This should fix a warning produced by scan-build-20
warning: The 4th argument to 'setsockopt' is NULL but should
not be NULL [unix.StdCLibraryFunctions]
The IOC_OPAL_ERASE_LR uses Erase method, that is defined only
in Single user mode (SUM) and works only on SUM-enabled LRs.
As we do not use SUM yet, this always fails.
Moreover, Erase has many side effects - it resets user password to ""
and disables locking for LR.
We already use fallback to IOC_OPAL_SECURE_ERASE_LR, which is GenKey
method (defined in Core spec) that must be always available.
It effectively regenerates the LR encryption key.
LUKS2 supports several jsom area length configurations. With
the largest size supported in megabytes we do not want to write full
metadata area unconditionaly (current code) with every metadata
update. This might generate noticeble overhead with LUKS2
reencryption.
With this patch we write only the real used json area
length plus necessary padding to overwrite remaining previous
metadata stored on the disk.
During LUKS2 format and LUKS2 autorecovery we always overwrite
whole json metadata area no matter the used size.
Add a single function to use when generating
json format string representation for on disk
storage purposes so that it can be easily
reused when needed.
We do not need to used crypt_unlink_key_by_description_from_thread_keyring
since it also sets some additional parameters unrelated to dm-verity
signatures.
Also it's useless to search kernel key by description when
we have the key id.
We do not have to query device-mapper subsystem
twice in order to get volume key description in kernel keyring.
Also there was a bug that wrongly used kernel key type set by function
supposed to set custom user key type used only when linking volume key
in arbitrary kernel keyring on caller demand.
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
