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).
This patch extends available options for LUKS2 reencryption
initialization.
When no specific keyslot is selected by --key-slot option, all active
keyslots needs to be refreshed. With current patch user does not
have to provide passphrase via interactive prompt when token is
available and can unlock assigned keyslot. Only keyslots not assigned
to tokens (and unlocked by tokens) must be provided with passphrase.
Furthermore user may directly narrow down selection of keyslots
suitable for reencryption by specifying either --token-id, --token-type
or --token-only option. In that case only keyslots associated to the
specific token (--token-id) or specific type (--token-type) or any token
specified in LUKS2 metadata (--token-only) will be used for
reencryption and refreshed with new volume key. All other keyslots will
not be refreshed and will be erased after reencryption is finished. The token
association will be carried over to refreshed keyslots.
The third new method available in this patch is support for reencryption
by passing volume keys directly. The LUKS2 device may be reencrypted
by passing volume keys by --volume-key-file, --new-volume-key-file,
--volume-key-keyring or --new-volume-key-keyring options. With this
options user may reencrypt device with no active keyslots. If there's
any active keyslot and volume keys are passed directly user may enforce
volume key based reencryption by passing --force-no-keyslots option.
If --force-no-keyslots option is passed all active keyslots will be
erased after reencryption operation is finished and the device may be
unlocked only by passing new volume key directly.
Fixes: #774, #780.
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.
Someone decided to remove fips-mode-setup instead
of providing backward compatibility (and just set fips=1).
Upstream is not a RH testbed, remove this job.
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.
