The test was wrongly expecting results based on a mistake
in keyring utilities. The internal function extracting
volume key from kernel keyring was by mistake returning
-ENOENT (error code internaly used to signal the keyslot
context can not be used for unlocking key) even though
the kernel key was in fact unreachable and therefor
the volume key could not be read.
In short never expect device activation will pass
when one of passed keyslot contexts is invalid. The fact
that sometimes only one keyslot context is needed and
the invalid second context should not be needed is not
good practice.
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.
This patch adds keyslot randomness analysis to cryptsetup repair command
to check for a detectable corruption of binary area.
It uses Chi2 analysis. This check basically replaces external keyslot
checker program.
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).
