This happens when concurrent creation of DM devices meets
in the very early state (no device node exists but creation fails).
Return -ENODEV here instead of -EINVAL.
(Should "fix" random verity concurrent test failure.)
If zeroing memory is implemented through libc call (like memset_bzero),
compiler should never remove such call. It is not needed to set O0
optimization flag explicitly.
Various checkers like annocheck causes problems with these flags,
just remove it where it makes no sense.
(Moreover, we use the same pattern without compiler magic
in crypt_backend_memzero() already.)
The hotzone segment offset has to be altered
accordingly no matter the segment type.
Note for testing: This feature is currently
blocked in cli but it should be tested via
API tests anyway.
Fully leverage openssl custom library context for various
providers (default, legacy). It can be used to properly
free all openssl resources used by libcryptsetup when
libcryptsetup is unloaded (and destructor is triggered).
This patch removes magic for backup load that quietly
run lowecase conversion and add this possibility to repair command.
Most of crypto backends allow uppercase though.
1) Crypsetup repair should try to call crypt_repair() even
if crypt_load is ok - it has no validate system unlike LUKS2
and some errors cannot be hard load errors.
2) Move ECB fix to repair code, do not try magic on load that
no longer works.
And do not use ECB :)
Fixes: #664
The external gettext library should be used on main libcryptsetup,
not later for programs (these do not call any translations).
(Also it was in the wrong order there failing compilation.)
The signature description should be allocated only if params field is used,
otherwise we can leak the string value.
(Moreover, the query path is currently used only for flag, not for the value.)
This reverts commit 367cb7a761
and retains original crypt_reencrypt() symbol marked as deprecated
in favour of new crypt_reencrypt_run(). This makes cryptsetup 2.4.0
release fully backward compatible.
crypt_activate_by_token functions did not respect LUKS2 keyslot
priorities. These calls were able to activate device via keyslot with
CRYPT_SLOT_PRIORITY_IGNORE even when token was set to
CRYPT_ANY_TOKEN. This commit changes the token based activation
so that keyslot with priority ignore is eligible for unlock only
when specific token is selected. Also when activating with token
set to CRYPT_ANY_TOKEN keyslots with higher priority take precedence
over keyslots with normal priority. Keyslot with priority ignore are
correctly ignored when token is CRYPT_ANY_TOKEN.
crypt_activate_by_token (and _pin variant) now returns -ENOANO
instead -EAGAIN in case token handler identifies specific token
requires PIN to sucessfully complete token based activation.
-EAGAIN is now used for special case when additional system
resources are missing (HW token, other device, system daemon,
etc).
The deadlock is hypothetical since libcryptsetup applications
usualy terminates after error. The deadlock could only emerge
in case where single process handles multiple crypt contexts.
The old API is still supported and because we support very old
OpenSSL, this is the best wrokaround for the warnings.
Once we switch to the new OpenSSL version requirement, we can rewrite
HMAC to new EVP_MAC API.
Reverts commit 96d83455ca partially. It is not necessary to
have specific crypt_activate_by_token_type call. Users
may use crypt_activate_by_token_pin with pin argument set to NULL
and achieve same goal as with crypt_activate_by_token_type.
Search for token handlers in %{libdir}/cryptsetup directory
by default. Distros may change default location via
--with-luks2-external-tokens-path parameter during configuration.
Argon2 draft defines suggested parameters for disk encryption use, but LUKS2
approach is slightly different. We need to provide platform independent
values. The values in draft expects 64bit systems (suggesting using 6 GiB
of RAM), while we need to provide compatibility with all 32bit systems,
so allocating more than 4GiB memory is not option for LUKS2.
The maximal limit in LUKS2 stays for 4 GiB, and by default LUKS2
PBKDF benchmarking sets maximum to 1 GIB, prefering increase of CPU cost.
But for the minimal memory cost we had a quite low limit 32 MiB.
This patch increases the bechmarking value to 64 MiB (as minimal
suggested values in Argon2 RFC). For compatibility reasons we still
allow older limit if set by a parameter.
