The function did not work properly if keyslot parameter
was set to CRYPT_ANY_SLOT and returned always error.
But it will be used later when we need to find if there's
at least one keyslot asigned to a specific segment.
It's a good practice to mark public APIs as extern "C" so that
projects written in C++ can use our library.
[mbroz] It is not public API in cryptsetup, but we use this backend
in other projects, this aligns the code changes.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
During the initialization phase future moved data segments
were incorrectly assigned (hardcoded) to digest with id 0.
When the default segment was assigned to a different value,
the initialization failed and was aborted.
This patch fixes the issue by assigning intermediary segments
to corect digest id.
Reported-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
The check did not work properly for stacked dm_crypt over
hw opal devices.
Also it did not work at all for active dm mappings with
missing (or detached) LUKS2 metadata.
PBKDF2 has been implemented since 2.0.0 and a new API was introduced in 3.3.0
deprecating the old one. This implementation will use the new API if detected.
Block devices must support direct-io. This check causes more problems
than it solves - for Opal locked device it disables direct-io
and we can later possible read wrong data (if kernel does not flush
cache).
For device without a type code shoud not try to use
strcmp function.
This can happen for example if deferref flag is used
for device without proper DM-UUID where init_by_name
does not set know device type.
Thanks Clément Guérin for the report.
Fixes: #910
Duplicate all dynamically allocated memory passed
keyslot context during initialization and make it
self contained.
Before current patch all pointers passed in keyslot
context initialization routines have to remain valid
for the duration of the keyslot context. Otherwise
memory violation could occur.
This patch fixes the issue in backward compatible
way so that we do not have to change API for all
keyslot contexts. As of now all dynamically allocated
memory can be freed right after keyslot context
initialization.
For each 1 MiB of data en/decrypted, 'cryptsetup benchmark' is setting
up a new AF_ALG socket, which involves 4 system calls and is included in
the data en/decryption time. With high-speed ciphers (e.g. VAES
optimized AES-XTS) this can measure well over 10000 AF_ALG socket setups
per second. This is not representative of dm-crypt, which only
allocates a cipher when the dm-crypt device is created.
Therefore, allocate the AF_ALG socket once, before doing the benchmark.
On AMD Ryzen 9 9950X this increases the 'cryptsetup benchmark' result of
AES-256-XTS slightly, from 14000 MiB/s to 14600 MiB/s.
Note that an in-kernel benchmark of the crypto API with the same block
size (65536 bytes) gives 34100 MiB/s, so AF_ALG still takes more time
than the en/decryption itself -- this cannot easily be addressed though.
Signed-off-by: Eric Biggers <ebiggers@google.com>
We use common libcryptsetup-token.sym version script that contain
all symbols, but some of them are optional.
As clang linker treats missing symbols as errors, the linker
phase for ssh token fails as optional cryptsetup_token_buffer_free
is not defined.
(Most of distros has this option still disabled, though).
As the sym file is also example for token authors, removing symbols
there is not an option. For clang, we can use --undefined-version option,
but it is not supported by other linkers, so it requires non-trivial
checks for usable LDFLAGS (for both autoconf and meson).
Instead, fix it by simply defining the symbol in ssh token, which
duplicates the internal libcryptsetup functionality.
Fixes: #830
Hard abort is justified here. The online reencryption on
data devices that do not support O_DIRECT io flag is
dangerous and leads to data corruption. This should be
impossible to hit due to a patch that handles it
in initialization phase. Better safe than sorry.
Verify the data device supports O_DIRECT io flag in
the initialization phase. Online reencryption is not
safe unless we can read and write the data in direct
mode.
Currently, direct-io is disabled if underlying device is suspended.
This was an unfortunate change, as it is part of data corruption
problem in online reenryption.
Let's relax the test to assume that suspended device
(suspended => must be a device-mapper device) supports direct-io.
The read test is still needed as some network based devices
misbehaves if opened with direct-io flag.
The ssize_t must be defined in the range [-1, SSIZE_MAX].
The return value is overwritten to -EINVAL later anyway,
return -1 here to be on the safe side.
Fixes: #900
This patch allows dm_status_suspended() to report if device
is suspended or not also for unknown target types from
libcryptsetup perspective (e.g.: dm-cache).
Consider device is suspended only if dm_status_suspended return code
is true.
This function returned -EEXIST for dm devices with target types unknown
to libcryptsetup (for example dm-cache) and turned off O_DIRECT flag
for devices unexpectedly.
Turned out ignoring direct-io was a problem after all :).
Fixes: 0f51b5bacb (Do not run sector read check on suspended device.)
Parsing --debug output with quiet flag can produce SIGPIPE output
if running with valgrind wrapper, just workaround it with another
grep as used elsewhere.
