The new flag is supposed to refresh (reload) active dm-crypt
mapping with new set of activation flags. CRYPT_ACTIVATE_READONLY
can not be switched for already active device.
The flag is silently ignored for tcrypt, verity and integrity
devices. LUKS2 with authenticated encryption support is added in
later commit.
auto-recovery triggers any time when only single correct LUKS2
header instance was found. That may be dangerous.
We should suppress auto-recovery in case blkid decided the
device is no longer LUKS device. For example if secondary (intact)
LUKS2 header was left behind and blkid declares the device is LVM2
member.
Moreover if at least one header instance is corrupted and blkid
declares device non-empty and non-LUKS in the same time, header load
operation will be aborted with error.
The code scan for the second header only if primary is corrrupted.
Let's set the possible offsets more clear.
This patch also removes 8kB header offset (that was not supported anyway).
This change makes the declaration of logger() match its definition,
it also avoids the use of the "class" C++ keyword. This is useful for
importing cryptsetup into Bazel/Blaze.
Move all keyring functions to one place and separate LUKS2 specific
code to generic handling.
Also fix possible mismatch if volume key is in keyring but it is not native
LUKS2 device (libarary cannot process such a device properly).
When loading first dm-crypt table (or action that triggers dm-crypt
module load) we do not know dm-crypt version yet. Let's assume all
kernels before 4.15.0 are flawed and reject VK load via kernel keyring
service.
When dm-crypt is already in kernel, check for correct target version
instead (v1.18.1 or later).
On some systems the requested amount of memory causes OOM killer
to kill the process (instead of returning ENOMEM).
For now, we never try to use more than half of available
physical memory.
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.
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).
Prepare API for PBKDF that can set three costs
- time (similar to iterations in PBKDF2)
- memory (required memory for memory-hard function)
- threads (required number of threads/CPUs).
This patch also removes wrongly designed API call
crypt_benchmark_kdf and replaces it with the new call
crypt_benchmark_pbkdf.
Two functions for PBKDF per context setting
are introduced: crypt_set_pbkdf_type and crypt_get_pbkdf_type.
The patch should be backward compatible when using
crypt_set_iteration_time function (works only for PBKDF2).
Signed-off-by: Milan Broz <gmazyland@gmail.com>
In some specific situation we do not want to read the devices
before initialization.
Here it is integrity checking that will produce warning, because
the device is not yet initialized.
Used only in wipe function (here we must use direct-io anyway)
and expect the device is capable of direct-io.
It is possible to overflow integers during memory allocation with
insanely large "key bytes" specified in a LUKS header.
Although it could be argued to properly validate LUKS headers while
parsing them, it's still a good idea to fix any form of possible
overflow attacks against cryptsetup in these allocation functions.
