crypt_deactivate_* fail earlier without noisy dm retries
when other device holders detected. The early detection
works if:
a) other device-mapper device has a hold reference on the
device
- or -
b) mounted fs is detected on the device
Any deactivation flag CRYPT_DEACTIVATE_FORCE or
CRYPT_DEACTIVATE_DEFERRED will disable this detection
before this patch any LUKS2 requirement defined in header
would stop a restricted operation from proceeding further.
This patch adds ability to mask requirements (internal only).
This patch adds support for using keyring for volume key
and support for new integrity fields for dm-crypt.
Also helpers for searching disk by id.
To be used later.
This reverts commit 4e2deadba7.
There is too many cases with 4k unaligned images that this optimization
adds more problems than it solves. Revert it for now.
1) If the calculated costs were the same, it run forever.
2) If the calculation returned final values in the first step,
out costs were not updated and benchmark returned too low values.
If the keyfile size is explicitly given, then allocate a suitable sized
buffer right from the start instead of increasing it in 4k steps. This
speeds up reading larger keyfiles.
If reading a keyfile use bulk read operations instead of reading one
character at the time. This speeds up reading larger keyfiles.
If read should stop at a EOL, then fallback to reading one character at
the time to not read anything beyond the EOL character.
Also cache its value in active context, so we run benchmark
only once.
The patch also changes calculated value for LUKS1 key digest
to 125 miliseconds (it means that for full 8 used slots
the additional slow-down is circa 1 second).
Note that there is no need to have too high iteration count
for key digest; if it is too computationally expensive, attacker
will better decrypt of one sector with candidate key anyway.
(Check for a known signature.)
The reason to have some delay for key digest check was
to complicate brute-force search for volume key with LUKS header
only (and if RNG used to generate volumekey was flawed
allowing such a search i reasonable time).
When we have measured time smaller than target time, we are decreasing
the parameters. Thus, we should first try to decrease t_cost and only
if that is not possible should we try to decrease m_cost instead. The
original logic was only valid for the case where parameters are being
increased. Most notably this caused unusual parameter combinations for
iteration time < 250 ms.
In this commit we also factor out the now heavily nested parameter
update formula.
