This patch avoid warning in constant-time base64 function:
Error: CPPCHECK_WARNING (CWE-190): [#def2]
cryptsetup-main/lib/crypto_backend/argon2/encoding.c:86: error[integerOverflow]: Signed integer overflow for expression ''0'-52'.
The (x + ('0' - 52)) can be rewritten to (x - (52 - '0')) with the same effect.
Similar solution used in https://github.com/pornin/CTTK/blob/master/src/base64.c
After switching to reencryption by keyslot context,
the digest was not properly verified before crash recovery.
We need to reverify reencryption digest after metadata
reloads unconditionally.
In both pbkdf2 and argon2* benchmark key variable
is pointer to benchmark data and does not need to be erased
safely as regular key data would need to.
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>
