crypt_activate_by_keyslot_context never respected pbkdf serialation
flag (CRYPT_ACTIVATE_SERIALIZE_MEMORY_HARD_PBKDF).
In fact it worked only when device was activated via passphrase or via
passphrase file. It was never respected when device was activated
by a token for example.
When the internal code was fully switched to activation via keyslot
context the legacy code for passphrase based activation was dropped
and we lost track of serialization flag completely.
This fixes all of the issues so now the serialization flag will be
respected also with tokens (and all other activation methods unlocking
LUKS2 keyslot with memory hard pbkdf).
Fixes: 58385d68d8 (Allow activation via keyslot context)
Fixes: #968.
For compatibility reasons, cryptsetup uses key size in BITS
while integritysetup in BYTES.
The help is confusing here, this patch fixes it.
Thanks Daniel Tang for notification.
Also try to use crypto lib/kernel check where appropriate.
This can be useful for local testing (non-FIPS kernel) byt
should not break real FIPS systems.
While allocating internal data structure for a device
overlaying reencryption hotzone we accidentally read
tested the device in each reencryption step. This
was suboptimal so now the device is read only once
while initializing the reencryption device-mapper stack.
Make the PHMAC integrity algorithm know to libcryptsetup.
The size of a key for PHMAC is not known, because PHMAC gets an opaque
blob as key, who's physical size has nothing to do with the cryptographic
size. Thus, let INTEGRITY_key_size() and crypt_parse_integrity_mode()
return the required_key_size as key size for PHMAC, or -EINVAL if
required_key_size is zero, to indicate that the size is unknown.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Do not print sed-opal spefic debug messages with confusing
error codes if ioctl() call failed with -1. Usually that means
the kernel does not support sed-opal interface or the requested
ioctl number is not implemented.
ioctl syscall always returns -1 on error (see ioctl(2)).
On error the actual reason is reported via errno varible.
Let's store the original errno code in the variable
so that it can be printed out in debug mode.
Before this fix the debug message always reported "Operation not
permited" (the translation of errno EPERM (1)).
The lr member in opal_lr_act kernel structure is
ingnored unless the device is being activated in SUM
mode.
See kernel implementation of IOC_OPAL_ACTIVATE_LSP
in block/sed-opal.c
When formating device with --integrity-inline option
there's a check if underlying device properly advertise
integrity profile support. The check did not work
properly for partition device nodes. We have to read
integrity profile info from top level block device.
Fixes: #964.
The PSID reset erases the block device it's submitted to
succesfully.
By submitting the command to read-only fd previously
there were partition device nodes still visible in
the /dev directory because kernel does not trigger rescan
after OPAL2 PSID reset. Even though all the partition were
actually erased (including the partition table).
We workaround the issue by submitting the PSID reset
to R/W fd so that it triggers rescan event on close.
These LUKS2 labels are stored in the binary header area that has limited size.
While we have been silently truncating strings here, it is something that
is not expected, as the final label is then different than expected.
Let's fix the code to explicitly print and return error here.
Also remove the comment about duplicate check. It is incorrect optimization,
as some users will expect a real write on disk, we should no skip it.
Fixes: #958
The compiler may advertise function attribute support
with __has_attribute operator even though it does
not implement the feature on some architecture.
This fixes the issue with GCC 11 on ppc64le with
__attribute__((zero_call_used_regs("used"))).
Fixes: #959.
This commit implements FVE metadata block validation based on:
* CRC-32 (to detect random corruption);
* AES-CCM-encrypted SHA-256 (to detect malicious manipulations).
The hash-based validation requires us to decrypt the VMK first, so
it's only performed when obtaining the volume key.
This allows us to detect corrupted/altered FVE metadata blocks and
pick the valid one (before this commit: the first FVE metadata block
is always selected).
Fixes: #953
tests: add BitLocker image with corrupted headers
The image contains 2 manually corrupted metadata blocks (out of 3),
the library should use the third one to correctly load the volume.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
LUKS2 keyslot cannot be created with cipher_null using standard
tools, but activation of such a keyslot is allowed.
As this can be confusing and create a false sense of security,
let's apply the same restriction as in LUKS1 - such a keyslot
is used only with an empty passphrase.
This will reject activation with a real password, avoiding
possible activation of insecure LUKS containers.
Fixes: #954
This prevents gcc warnings:
warning: initializer-string for array of 'unsigned char' truncates
NUL terminator but destination lacks 'nonstring' attribute
While there is "nonstring" attribute, clang does not support it,
so this is the simplest solution.
For some reason, external token path and tmpfilesdir uses a macro
that generates entry in config.h, producing these #defines:
DEFAULT_LUKS2_EXTERNAL_TOKENS_PATH
DEFAULT_TMPFILESDIR
Neiter one is used in C code, moreover, definitions are wrong,
as variables are modified after entry is pushed to config.
Remove the macro call and use AC_ARG_WITH directly.
If cryptsetup is being installed to different directory using --prefix
configure switch, it tyries to use absolute system path (and fails).
Let's instruct pkgconfig to return proper prefixed tmpfiles variable.
The maximum parallel cost is set since the introduction of Argon2 to 4.
Do not silently decrease the value (if explicitly set by the option)
but fail instead.
When TCRYPT subdevices was moved to use SUBDEV dm uuid prefix
we did not correctly modified the TCRYPT_status_one routine
to correctly expect the SUBDEV uuid prefix.
Fixes: cf630f578dFixes: #952.
Move all notes and warnings to description text.
Refine some small clarification.
Do not use NOTE/WARNING unless there is a serious reason (data loss).
If run in Makefile.localtest there was unset CRYPTSETUP_TOKENS_PATH.
It's valid test case to run with systemd-tpm2 plugin installed on
the system (integration tests).
It that appears using the `source` builtin with process substitution
yields a race condition:
./tests$ ./bitlk-compat-test; echo RV=$?
HEADER CHECK
bitlk-images/bitlk-aes-cbc-128-4k.img [OK]
bitlk-images/bitlk-aes-cbc-128.img [OK]
bitlk-images/bitlk-aes-cbc-256.img [OK]
bitlk-images/bitlk-aes-cbc-elephant-128.img [OK]
bitlk-images/bitlk-aes-cbc-elephant-256.img [OK]
bitlk-images/bitlk-aes-xts-128-4k.img [OK]
bitlk-images/bitlk-aes-xts-128-eow.img./bitlk-compat-test: trap: line 2: unexpected EOF while looking for matching `)'
./bitlk-compat-test: command substitution: line 70: syntax error near unexpected token `)'
./bitlk-compat-test: command substitution: line 70: `echo "$dump" | grep "Volume size:" | cut -d: -f2 | tr -d "\t\n ")'
WARNING: You must be root to run activation part of test, test skipped.
RV=0
This is with bash 5.2.37 on a Debian sid system. It doesn't fail the
test, but affects coverage as subsequent images are not tested.
`eval`'ing the output of a pipe solves the race condition.
It's arguably not robust code, but load_vars() appears to make
assumption about images.conf's content and didn't account for edge cases
either.
The test was wrongly expecting results based on a mistake
in keyring utilities. The internal function extracting
volume key from kernel keyring was by mistake returning
-ENOENT (error code internaly used to signal the keyslot
context can not be used for unlocking key) even though
the kernel key was in fact unreachable and therefor
the volume key could not be read.
In short never expect device activation will pass
when one of passed keyslot contexts is invalid. The fact
that sometimes only one keyslot context is needed and
the invalid second context should not be needed is not
good practice.
Create lower level TCRYPT device (underneath the toplevel one)
with CRYPT_SUBDEV prefix so that in later release we
can use general dependecies deactivation code.
The newly activated stacked TCRYPT devices will not correctly
deactivate with older pre 2.8.0 release.
When activating dm-integrity device underneath dm-crypt
with LUKS2 authenticated encryption mode, annotate the
device correctly with CRYPT_SUBDEV prefix. This will help
us to clearly identify dependent device underneath LUKS2 top
level device and we can unify the deactivation code in future
releases.
We have general code deactivating dependent devices already for
LUKS2 reencrytion.
Deactivating newly created devices with pre 2.8.0 cryptsetup
will issue warning about missing devices but the deactivation
will succeed.
This hack tries to workaround situation when small VMs without swap
causes OOM. This hack will be removed one day completely...
Also remove confusing warning about possible crash.
With OpenSSL Argon2 backend this behaves much better, but it still
can cause OOM instead od returning ENOMEM.
Anyway, the warning message causes more problems that it solves.
Fixes: #896
Unfortunatelly the benchmark function cannot return
corrected parallel cost, so it must fail.
Note that some backends (like OpenSSL) also limits maximal thread count,
so currently it was clapped at 4 for luksFormat and 8 for benchmark.
This patch set it all to PBKDF internal parallel limit.
This patch adds keyslot randomness analysis to cryptsetup repair command
to check for a detectable corruption of binary area.
It uses Chi2 analysis. This check basically replaces external keyslot
checker program.
Use dm_get_active_iname that should be used on all places.
This function return integrioty device name if it shoudl be
maintained by LUKS2 context directly.
Code must not touch other devices that it does not own.
The type cannot be converted to LUKS1 if there is an unbound keyslot.
It is already covered by digest count check, but in some specific
use cases the explicit check can catch a new problem.
While adding new unbound key there is a check whether the
passed key parameter matches current volume key or not. If it
matches the existing volume key we handle the LUKS2 keyslot
addition as an ordinary LUKS2 keyslot (not unbound).
If the check failed we continued with the operation of adding
LUKS2 unbound keyslot. But we did not check if the error
was not a more general issue for example with in-memory metadata.
Let's contine with the operation only if the return code is
expected -EPERM (not matching digest) or -ENOENT (not matching any
existing unbound key).
This patch extends available options for LUKS2 reencryption
initialization.
When no specific keyslot is selected by --key-slot option, all active
keyslots needs to be refreshed. With current patch user does not
have to provide passphrase via interactive prompt when token is
available and can unlock assigned keyslot. Only keyslots not assigned
to tokens (and unlocked by tokens) must be provided with passphrase.
Furthermore user may directly narrow down selection of keyslots
suitable for reencryption by specifying either --token-id, --token-type
or --token-only option. In that case only keyslots associated to the
specific token (--token-id) or specific type (--token-type) or any token
specified in LUKS2 metadata (--token-only) will be used for
reencryption and refreshed with new volume key. All other keyslots will
not be refreshed and will be erased after reencryption is finished. The token
association will be carried over to refreshed keyslots.
The third new method available in this patch is support for reencryption
by passing volume keys directly. The LUKS2 device may be reencrypted
by passing volume keys by --volume-key-file, --new-volume-key-file,
--volume-key-keyring or --new-volume-key-keyring options. With this
options user may reencrypt device with no active keyslots. If there's
any active keyslot and volume keys are passed directly user may enforce
volume key based reencryption by passing --force-no-keyslots option.
If --force-no-keyslots option is passed all active keyslots will be
erased after reencryption operation is finished and the device may be
unlocked only by passing new volume key directly.
Fixes: #774, #780.
If there is no digest associated with segment,
for example during reencryption mode encrypt initialization,
return -ENOENT in LUKS2_digest_verify_by_segment.
With this commit reencryption can run without any active
keyslot containing current (or optional future) volume key.
In such case new volume key must be provided via CRYPT_KC_TYPE_KEY
keyslot context and by adding CRYPT_REENCRYPT_CREATE_NEW_DIGEST flag in
reencryption parameters during reencryption initialization in
crypt_reencrypt_init_by_keyslot_contexts.
The new flag can not be combined with CRYPT_REENCRYPT_RESUME_ONLY
flag.
It allows to get former (old) volume key size
from LUKS2 device in reencryption state when
there's at least one keyslot containing encrypted
volume key.
Let's check block device size required for Merkle tree and superblock.
If it is a file, allocate the size in advance with fallocate.
This should print better error message if hash device is too small.
Fixes: #808
crypt_activate_by_keyslot_context() returns -EPERM
when key was passed either by CRYPT_KC_TYPE_KEY or
CRYPT_KC_TYPE_VK_KEYRING and does not match the digest
stored in metadata.
Sometimes caller might want to verify if the passed
keyslot contexts matches the effective volume key
or not without the error message. It can be
printed from command line tools when needed.
Someone decided to remove fips-mode-setup instead
of providing backward compatibility (and just set fips=1).
Upstream is not a RH testbed, remove this job.
PSID length is de-facto always 32 alphanumeric characters.
Limit the read of PSID from keyfile to this limit
(if not set by explicit size option).
This eliminates mistakes when the keyfile contains EOL characters.
Also, some OPAL drives accepts PSID with any suffix, this patch
unifies processing (it works everywhere the same).
This should fix a warning produced by scan-build-20
warning: The 4th argument to 'setsockopt' is NULL but should
not be NULL [unix.StdCLibraryFunctions]
The IOC_OPAL_ERASE_LR uses Erase method, that is defined only
in Single user mode (SUM) and works only on SUM-enabled LRs.
As we do not use SUM yet, this always fails.
Moreover, Erase has many side effects - it resets user password to ""
and disables locking for LR.
We already use fallback to IOC_OPAL_SECURE_ERASE_LR, which is GenKey
method (defined in Core spec) that must be always available.
It effectively regenerates the LR encryption key.
It is possible to add multiple recovery passphrases to a BitLocker
device so we should make sure we check both key slots when trying
to activate the device.
The non compact json area may contiain whitespace characters
in between json object key and value (e.g.: {"key": "the_value"}).
For LUKS2 write optimization we need to check and do regression testing
for the case where LUKS2 metadata would contain valid LUKS2 json area in
non compact format. The test is meant to verify if the write optimization
does not leave invalid characters beyond valid and properly terminated
LUKS2 json area.
LUKS2 supports several jsom area length configurations. With
the largest size supported in megabytes we do not want to write full
metadata area unconditionaly (current code) with every metadata
update. This might generate noticeble overhead with LUKS2
reencryption.
With this patch we write only the real used json area
length plus necessary padding to overwrite remaining previous
metadata stored on the disk.
During LUKS2 format and LUKS2 autorecovery we always overwrite
whole json metadata area no matter the used size.
Add a single function to use when generating
json format string representation for on disk
storage purposes so that it can be easily
reused when needed.
We do not need to used crypt_unlink_key_by_description_from_thread_keyring
since it also sets some additional parameters unrelated to dm-verity
signatures.
Also it's useless to search kernel key by description when
we have the key id.
We do not have to query device-mapper subsystem
twice in order to get volume key description in kernel keyring.
Also there was a bug that wrongly used kernel key type set by function
supposed to set custom user key type used only when linking volume key
in arbitrary kernel keyring on caller demand.
Functions related to uploading/unlinking volume keys in user
requested kernel keyrings are named as follows:
crypt_single_volume_key_load_in_custom_keyring
crypt_volume_key_load_in_custom_keyring
crypt_unlink_key_from_custom_keyring
helpers for unlinking LUKS2 volume keys from thread keyring:
crypt_unlink_key_from_thread_keyring
crypt_unlink_key_by_description_from_thread_keyring
The kernel 6.14-rc3 introduced regretion with 1f47ed294a2bd577d5a
The commit changed how errors are propagated and with it OPAL2 devices
no longer returns -EIO on IO to locker region.
Revert this patch after the kernel gets fixed.
The test was supposed to check if invalid --luks2-keyslots-size
metadata value will trigger failure.
The 128MiB was valid value and the test failed only due to smaller
test device size.
(In case of OPAL2 device it spanned into locked region.)
It is really not a good idea to check minor version without
checking major version is not lower first.
Also try to prepare for situation when major target versions
increases.
The panic/restart_on_error options were introduces in kernel 6.12.
As it does not make sense to set these flags without
data corruption handling, only one option error-as-corruption
is implemented that must be used in combination with
panic/restart on corruption.
The volume key structure may often be in configuration
where 'key' member does not contain real data. Some
examples:
- volume key acquired by querring device-mapper where key
was originaly passed by kernel keyring reference.
- volume key allocated by crypt_alloc_volume_key(size, NULL)
With this patch access to internal 'uninitialized' data result
in failed assert().
For use cases where key data are not needed (keyring reference wrapper,
key length info only) we do not have to allocate and lock the safe
buffer in memory.
Further improvements might to completely hide the volume key internals
and access only via setter and getter functions.
Switch current code to use following volume key helpers
for accessing internal properties:
crypt_volume_key_length(), crypt_volume_key_get_key(),
crypt_volume_key_description() and crypt_volume_key_kernel_key_type()
Remaining direct access to volume key internals will be dealt with in
later commits since it requires some further changes.
crypt_volume_key_length() for key length
crypt_volume_key_get_key() to access key data (if initialized)
crypt_volume_key_description() for kernel key description
crypt_volume_key_kernel_key_type() for kernel keyring key type
There were two different use cases for weaker keys:
1) empty keys (zero filled buffer)
2) weak 'random' keys not sucking entropy while being generated
Those key types must not be used to encrypt real data. It's used either
to check cipher can be configured sucessfully on the system or as
a fake envelope during metadata repair.
The volume key uploaded attribute is respected only with
regard to volume keys uploaded in the thread keyring in logon key type.
Here the uploaded attribute was set for volume keys uploaded in
custom user keyrings in custome key descriptions.
The file is used to describe project compilation independent
of build system in use.
It can also help LSP servers to improve code suggestions since
it can see how the project is configured and respect, for example,
content of config.h file.
The dm-integrity table always contains number of feature arguments
(since introduction in kernel 4.12).
Moreover, the code already dereferences params field, so the test
make no sense.
Found by CodeQL check.
If bash test script uses a pattern that test that command should fail
command && fail
(IOW fail function is called only if command exited successfully),
it can mask potential segfault, as it return non-zero exit code.
Fix it by using trap for scripts that uses this pattern.
The same applies for SIGABRT (abort() call).
Reaching maximal keyfile size is already reported as error.
Note that interactive really means user entering password.
For all other us there is keyfile processing.
Related: #933
For 32bit platforms size_t is 32bit integer and unfortunately
our maximum hard limit overflows by 1.
Stop validation if this happens (it cannot be passed to malloc()
and similar functions anyway).
There should be no compatibility change, as such memory
is not allocatable on 32bit anyway.
Other platforms have 64bit size_t.
NOTE: This is possibly an incompatible change as it changes text output.
Since the support of --sector-size option, the description "sectors"
became ambiguous as it usually means 512-byte sectors (device-mapper unit).
Major confusion occurs when the sector size is 4096 bytes while units display
is in 512-bytes.
Unfortunately, there is no clear compatible way, so this patch adds
[512-byte units] marker and also additional byte size value.
All other fields that display units are changed to use the "[units]" format.
The integrity format is also unified with the common style with ':' as a separator.
Fixes: #884.
For now, we used zeroed key for dm-integrity format, as there was not
data area. In future, there can be wrapped key scheme, that will require
to setup real key even in this situation.
This patch modifies the integrity format flow that the real key is used
during format.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch add support for setting of integrity key size
for LUKS2 devices.
It adds new (optional) JSON "key_size" attribute in segment.integrity JSON object.
If not set, the code use hash length size (backward compatible).
For LUKS2, we do not allow smaller keys than 128 bits.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch implement support for setting specific integrity key size
option in dm-crypt, available since dm-crypt version 1.28.0.
This can be used for setting non-standard HMAC key length.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
There is no functional change in this patch except it avoids
strange confusion during some static tests.
The cd->type must be set in this function anyway.
This is only preparation for an extension later, however, the volume
keys should not be unloaded unconditionally from keyring.
Note that all other places dropping keys already check that keys
were uploaded through key ID setting.
(And for suspend unconditional unlink make sense too.)
The key_decripion always contains only a key name,
keyring then contains type of keyring as defned un keyring utils.
For now, only LOGON type is used in commands, it will be extended later.
The luks2_internal.h contains specific JSON implementations while
luks2.h is generic. Code outside of luks2/ dir should not use internals.
Also luks2.h includes functions prototypes that are used from setup.c.
There was a bug in both crypt_token_assign_keyslot and
crypt_token_unsassign_keyslot where CRYPT_ANY_TOKEN
special value could be passed in token parameter.
It would correctly assign/unassign all tokens to/from
the specified keyslot (or from any in case of CRYPT_ANY_SLOT),
but it returned -1 (CRYPT_ANY_TOKEN) which fited error return
values as per API documentation.
We fixed that by not supporting CRYPT_ANY_TOKEN since it does
not make much sense. It can be workarounded by iterating over
all available tokens and calling crypt_token_assign_keyslot or
crypt_token_unassign_keyslot accodingly.
Fixes: #914.
Thsi patch avoids this cppcheck warning:
Error: CPPCHECK_WARNING (CWE-457): [#def1]
cryptsetup-main/lib/crypto_backend/argon2/blake2/blake2b.c:369: warning[uninitvar]: Uninitialized variable: out_buffer
It is a false positive, but wiping buffer is cheap a and similar approach is used
in other Argon2 implementations (OpenSSL).
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>
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.
The option allows data device to be used in multiple
DM table mappings and exclusive access is not checked
anymore in-before device activation.
It also allows correct concurrent verity device activation.
With --shared option if multiple processes compete for same DM
verity name using same underlying data device we can now guarantee
one process succeeds and all other fails with -EEXIST.
CRYPT_ACTIVATE_SHARED flag was silently ignored
while activating dm-verity devices by libcryptsetup.
This was a bug.
DM verity shared activation is generaly safe (single mapped data device
in multiple DM verity tables) since all verity devices are
read only.
The CRYPT_ACTIVATE_SHARED flag also fixes a race condition
when multiple processes compete for the same DM device name
(all dm-verity) while using same backing data device.
The exclusive open check in-before verity activation could
fail DM table load for a process that otherwise successfully acquired
DM device name (succeed in creating the DM device). This could (in some
cases) result in all processes competening for the DM verity device
to fail and none would activate the DM verity device.
Exclusive flag is defined only when creating a file,
for opening existing file it is undefinded operation.
Remove it from crypt_loop_attach as it was wrong since
the initial commit.
Due to internal retry-overengineering in libdevmapper, some dm-ioctl
failures can disappear. One such case is when there is a device
creation race and DM device is created but reload fails.
this can heppen because some block device used in table mapping is
already claimed (it needs exclusive access for bdev_open in kernel).
The kernel ioctl properly returns EBUSY, this errno is lost
in libdevmapper (dm_task_get_errno returns 0).
While this should be solved by libdevampper, we need some reliable
way on older systems to properly report "busy" error instead of
overloaded "invalid" error.
With modified reproducer (see check_concurrent in very compat test),
this situation can happen quite often.
This patch modifies dm_create_device to return ENODEV only if
dm-ioctl also reports no device (ENXIO); following dm status reports ENODEV
and also some referenced device is no longer accesible through stat().
In all other cases we return EBUSY. Command line translates EBUSY and EEXIST
to the same return vaules, for API users it now returns EBUSY instead
of generic EINVAL.
IOW, if device activation returns EEXIST or EBUSY, device-mapper
cannot create the device because it already exits (EEXIST) or some referenced
device is claimed by other subystem (EBUSY) and mapping table cannot be created.
There is no need to unlock keyslot if the provided name
has wrong format. Let's check for length and '/' in name early.
Note that other commands could accept path to the device
as libdevmapper translate it to the name (status /dev/mapper/xxx).
Add early check only to activate commands.
It still can fail later because of mangled characters.
Fixes: #893
Mbed-TLS is a tiny TLS implementation designed for embedded environment which
can greatly reduce the disk space requirement compared to OpenSSL. While we
already have crypto_kernel for this purpose and Mbed-TLS lacking hash/cipher
support can cause reduced functionality, there're situations where AF_ALG is
not available but we're fine with limited scenarios like LUKS2 only.
Use read/write buffer functions to avoid partial operation.
This also fixed leaked fd warning. Also fix error path
for context failure - if initialize_context() fails,
rc->log_fd is closed in context destructor, no need to close
it in open_log/parse_log.
Another fixed bug is in parse_log, where immediatelly after
creation we have to seek to the beginning of the file first.
TrueCrypt/VeraCrypt supports full system encryption (only a partition
table is not encrypted) or system partition encryption
(only a system partition is encrypted).
The metadata header then contains the offset and size of the encrypted area.
Cryptsetup needs to know the specific partition offset to calculate encryption parameters.
To properly map a partition, you must specify a real partition device so cryptsetup can calculate this offset.
As user can specify various combination, we need to determine the proper
IV and data offsets.
The logic for CRYPT_TCRYPT_SYSTEM_HEADER flag should be (in this order):
- if data device is a real partition, calculate offset from it.
- if --header is a real partition , calculate offset from it.
- if device is a real disk, try to search for partition using decrypted offset and size
(works only for system partition-only encryption).
- if data and metadata (header) device is the same, map whole encrypted area
(this is the ost confusing for user)
- if data and metadata (header) divice differs, expect data image contains
only partition (setting offset to 0, but using IV offset from header).
There are still situation that can end with wrong mapping, but user now has the option
to setup it properly.
Also this patch fixes use of stored encryption size in header,
so we do not map larger area.
Fixes:#889
Print also volume sizes (if present) and flags.
This inforamtion is useful mainly for setting systemd encryption
where size determines encrypted region.
For LUKS2 headers with non zero data offset LUKS2_wipe_header_areas
will always erase the smallest from following:
- metadata device size
- data offset value
- maximal LUKS2 metadata size (twice 2 MiBs json area including 128 MiB for
binary keyslot areas) even with detached header.
For zero value data offset (LUKS2 header can not be restored back to
data device), we erase up to smallest from the following values:
- metadata device size
- maximal LUKS2 metadata size (twice 2 MiBs json area including 128 MiB for
If an unbound keyslot is present (e.g.. slot 0 usual slot, slot 1 unbound),
the query loop could return ENOENT (keyslot not valid for segment) and this
will stop epxected retry for slot quewry (--tries option).
If any previous slot rerutned EPERM (no valid passphrase), prefer
this return code.
The HCTR2 encryption was added to Linux kernel for fscrypt,
but as it is length-preserving mode (with sector tweak) it
can be easily used for disk encryption too.
As it need larger IV of size 32 bytes, we need to add exception
for aes-hctr2[-plain64] to be accepted in cryptsetup commands.
Fixes: #883
This patch adds README.licensing describing used licenses.
The license text files are now in dosc/licenses.
The main COPYING document in root is the default license,
this also forces GitHub to properly identify default license.
This patch switches code to SPDX one-line license identifiers according to
https://spdx.dev/learn/handling-license-info/
and replacing long license text headers.
I used C++ format on the first line in style
// SPDX-License-Identifier: <id>
except exported libcryptsetup.h, when only C comments are used.
The only additional changes are:
- switch backend utf8.c from LGPL2+ to LGPL2.1+ (as in systemd)
- add some additional formatting lines.
Some Opal devices contain a bug that device reports different logical
size for block device and Opal SED layer.
This can happen for NVMe after reformatting with different LBAF (512/4096).
We will not support such configuration as Opal then calculates sizes
differently for locking range (that could lead to data corruption or
a partially unecrypted area).
String.h and stdbool.h are already included in main backend header,
no need to include them again.
Stdio.h is missing for OpenSSL and NSS backed (for sprintf).
Strings.h is missing for cipher_generic, gcrypt and OpoenSSL (strcasecmp).
Fixes: #885
Zoned block device support can be disabled (as in RHEL8),
skip particular test if scsi_Debug does not create device.
(Modprobe does not return any error code, just kernel message
as parameter is actually supported, but block layer lack
support for zoned device.)
Once OPAL tests run, the whole pipeline gets marked as uninterruptible
(because of the uninterruptible OPAL job). Therefore a duplicate
pipeline gets started on e.g. MR change. Move OPAL jobs to test-opal
stage which runs at the end.
Zoned device cannot be written with direct-io
and cannot be used for LUKS header logic without
significant changes. Do not allow to use them for LUKS header
but allow it for data device, as dm-crypt supports it.
Fixes: #877
This function is used with block size, where 0 does
not make sense, so failing the check is the simple way
to avoid sividion by zero.
In reality, this should never happen, but it was seen
in (unreproducible) fuzzing input.
With email approval from Arno Wagner dated March 29, 2024:
From: Arno Wagner
To: Milan Broz
Subject: Re: cryuptsetup FAQ license
Hi Milan,
fine for me. You can change it directly.
Arno
On Wed, Mar 27, 2024 at 13:38:36 CET, Milan Broz wrote:
> Hi Arno,
>
> the FAQ in cryptsetup is licensed under CC-BY-SA-3.0 that is no longer a recent version - https://creativecommons.org/licenses/by-sa/3.0/
>
> I use CC-BY-SA-4.0 (https://creativecommons.org/licenses/by-sa/4.0/deed.en) for LUKS2 docs and think it is the best option for docs.
>
> Do you agree with updating the license to CC-BY-SA-4.0 for the FAQ.md file? (I, as coauthor, obviously agree :-)
>
> Thanks,
> Milan
hw-opal segment does not receive volume key for data
encryption, unlike crypt segment or hw-opal-crypt segment.
It gets key encryption key that is passed to device fw which
later unlocks the locking range key sealed in the device.
The assert may be skipped while volume key is not set.
Fixes: #875.
While properly calculated data segment needed compensation due to
misaligned partition (locking range had to be truncated),
we passed wrong value (original partition size) to LUKS2 metadata.
It has to use calculated locking range length in bytes.
Fixes: #873.
The opal_range_check_attributes_fd function expected both
offset and length parameters of a LR to be passed in sectors (512B).
During format we passed it wrongly in OPAL blocks which caused
bogus check provided OPAL block size was not 512B.
Fixes: #871.
With removal of cryptsetup-reencrypt there was
a bug introduced that broke resuming interrupted
LUKS1 decryption operation. LUKS2 code was not
affected.
This fixes a regression introduced somewhere on the way to 2.7.0.
A specific set of options led to complete lack of Argon2
regardless of --enable-libargon2 option.
The `variables` section is repeated for 32-bit Debian job. Therefore the
`DISTRO` environment variable is ignored and 64-bit distro name is
inherited from the `.debian-prep` job.
The kernel log is uploaded automatically by the custom executor, no need
to upload it from inside the VM (and /mnt/artifacts is not mounted in
the new CI scripts).
The keyring_to_link_vk parameter must be prefixed by
either "%:" or "%keyring:" substrings provided caller
opted for text description of the target keyring.
Use -ESRCH for similar error code as with
crypt_activate_by_keyslot_context. Here it's not
confliciting with previous use for the very code but
let's make it easier and use same code for similar case.
While trying to activate device in LUKS2 reencryption
we originally used -ENOKEY error code for case
where one or more volume keys could not be unlocked or
were not provided direclty by (CRYPT_KC_TYPE_KEY or
CRYPT_KC_TYPE_VK_KEYRING) keyslot contexts.
We missed the fact the error code was already previously
used for signaling case when dm subsystem could not load
device table due to key in kernel keyring could not be
read from kernel. It's propagated by libdevmapper.
For it we replace -ENOKEY with -ESRCH for signaling the missing
keyslot context or volume key for devices in LUKS2 reencryption.
The key might be needed in activation of ordinary LUKS2 device
provided the recovery took place in before device activation
and actually finished LUKS2 device reencryption.
Fixes: #863.
We already support activation of a device using a volume key in keyring.
However, in case of multi-key devices (i.e. device with reencryption
running) we need to supply two volume keys.
If the device is in reencryption, it has two active volume keys. Linking
the VK to keyring is not supported for such devices, because the API
only counts with one key. This commit modifies the API
crypt_set_keyring_to_link to allow passing multiple keyring key names.
If sysconf is lying, then anything can happen.
But check for overflow anyway.
Device/partition offset overflow for IV can only cause
bad decryption (expected).
790666ff (Add support for allow_discrads for dm-integrity., 2020-04-09)
added TRIM support for standalone dm-integrity volumes.
This change is now reflected in the cryptsetup(8) man page.
For Argon2 native code (gcrypt, OpenSSL) a flag in debug output is printed.
If libargon is used, then [cryptsetup libargon2] is printed
(embedded code) or [external libargon2] for dynamic external library.
# Crypto backend (OpenSSL 3.0.11 19 Sep 2023 [default][legacy] [external libargon2])
or
# Crypto backend (OpenSSL 3.0.11 19 Sep 2023 [default][legacy] [cryptsetup libargon2])
Fixes: #851
Activating LUKS2 device with OPAL support is multistep process.
1) read LR state
2) unlock LR
3) activate dm device
4) in case step 3) failed lock the device
if in step 1) the device was locked.
Otherwise, in case parallel activation happened on one device
the process that failed to map dm device (device already active)
could relock the LR afterwards and effectively break already active
device.
To avoid that we do steps 1) through 4) protected by exclusive
opal lock unique per data block device configured for use with
LUKS2 OPAL support.
It affects only HW OPAL locking range KEK.
After unlocking opal locking range we cache the key in kernel
so that we do not have to pass the key again for locking the
range later (the OPAL std requires key for lock command).
Unfortunately the key remains cached in kernel even after we
lock the range on purpose during crypt_deactivate* or crypt_suspend.
This had 2 side effects:
1) key remained in system memory even though the LUKS device was
inactive (and all keys should be erased from memory).
2) when system gets suspended the locking range got automatically
unlocked later after system resume because the key caching is used
primarly to automatically unlock locking ranges that got locked
after system suspend (due to power cut off on storage device).
Since kernel does not directly support dropping cached keys we achieve
that by overwritting the original key structure with empty one.
The read in kernel crypto backend is part of user crypto API
encryption call, we have to trust it here.
JSON fix is just one place where return code was not checked
for this particular function.
Currently we suspend top-level device only.
With OPAL, the underlying device will start to return errors
once OPAL LR is locked.
If the dm-integrity device is not suspended, regular journal
flush corrupts the device (journal write failure),
corrupting data above it.
Suspending the whole stack should fix the issue.
This can affect status command, but later also device
stack with authenticated encryption (*_dif device).
Ignoring direct-io should not be problem here.
The logic shoudl be simplified in future anyway...
It can be used to override system library where
libcryptsetup looks for external token handlers (plugins).
The parameter is required to be absolute path and it is set
per process context.
Fixes: #846.
The AC_C_CONST test program fails to compile under latest clang with
-Wall -Werror, which results in erroneously defining "const" keyword to
an empty string. The AC_C_CONST is considered obsolate.
An unknown -Dinternal-argon2=false flag was used, new meson version
fails when it gets unknown flag. Use the correct
-Dargon-implementation=internal flag instead.
Unfortunately there is currently no way how
to make difference between device lacking SED OPAL support
state and kernel missing SED OPAL support via disabled interface
via configure option.
The aim of the test is verify compatibility with
SW only LUKS2 devices for basic operations like
activation, deactivation, suspend, resume and
token based activation.
The crypt2_load_fuzz fuzzer needs to calculate LUKS2 header checksum
to speed up fuzzing. Currently we incorrectly touch const data input.
This patch
- calculates only primary LUKS2 header checksum (ignores secondary header)
- uses temporary struct for modified data
- keps fuzzer going even with original data if checksum calc fails.
Hopefully solves unknown write issue in fuzzer (not real utils) on oss-fuzz.
The crypto backend crypt_hash ans crypt_hmac structs usually
contain only pointers to internal crypto lib structures, no need
to wipe them explicitly as there are no sensitive data.
It is a crypto lib responsibility to remove sensitive data
in destructor.
Only nettle backend directly contains hash context, keep it there.
This should also fix mysterious crashes in fuzzer with misaligned memset.
In FIPS mode, if test passphrase is shorter
than 8 bytes, keyslot passphrase check routine
returns different error code (-EINVAL) than
expected (-EPERM).
Also by using --test-passphrase option this patch allows
cryptsetup to check if specific token (--token-id) is
able to unlock specific keyslot (--key-slot/-S).
It uses recently added crypt_activate_by_keyslot_context
API.
Fixes: #784.
Let's not make up synthetic errors if the kernel returns a useful error
to us, that tells us about key validity.
Specifically, if we try to activate a dm-verity device with a signed
root hash, it's import to know when we couldn't activate it due to the
signing key missing in the kernel keyring. The kernel reports a nice
error code in that case (ENOKEY), let's make sure this is propagated
back to clients.
To be on the safe side, this allowlists only the three key management
related error codes ENOKEY, EKEYREVOKED, EKEYEXPIRED and returns ENOKEY
for all of them. The kernel's DM stack traditionally wasn't very good
with returning useful error codes, hence the conservative approach.
This patch is not sufficient to fix this properly. There's a patch
needed to fix errno propagation also in libdevmapper:
https://gitlab.com/lvmteam/lvm2/-/merge_requests/3
With both patches applied we get correct error code reporting.
Fixes: #841
When adding new keyslot we check if provided existing
passphrase is correct first.
Since user may now select specific existing keyslot
(to extract volume key) it's no use to check any
matching keyslot. Test passphrase only for user
specified keyslot.
These are configurable in build time, to force default backward compatibility use
--with-plain-hash=ripemd160 --with-plain-cipher=aes --with-plain-mode=cbc-essiv:sha256
configure options.
Fixes#758.
Unlike LUKS, plain mode uses no metadata where configured.
As we need to upgrade algorithms form time to time because of security
reasons, warn user to specify these options explicitly.
Related #758.
While resuming LUKS2 reencryption operation for
device identified by active mapping (--active-name) the
prompt about ongoing operation did not use correct
variable to get device name in the message.
Add tests for device activation by volume
key uploaded in kernel keyring where user
only pass key description with no key type
description. In this case we add 'user' type
by default and it was not tested properly.
Fix a path with default kernel key type assumed.
It did not check correctly for return value from
asprintf and would leak the allocated memory
instead.
If LUKS2 keyslot area has to be overwritten (due to lack of free space),
do not wipe the affected area first. It will get overwritten anyway.
Originaly, in between the keyslot wipe and new key material write, pbkdf
calculation took place. The pbkdf calculation takes ~2 seconds by default
and it put the user in unnecesary risk of loosing the keysot data in case
of a crash.
With LUKS2 crypt_keyslot_change_by_passphrase() call
does not have to overwrite binary keyslot
area in-place when user asked for specific keyslot id.
If there's enough free space in keyslot binary area
we can write new keyslot material in the the free area
(identified temporarily by new keyslot id) and switch
pointers (json metadata) to point to the new keyslot area after
the keyslot area write is complete. The old keyslot
area gets deleted after the new area write is finished.
Otherwise we needlesly risk to lose the existing keyslot
if the operation gets interupted.
With this patch LUKS2 crypt_keyslot_change_by_passphrase()
overwrites existing keyslot (including keyslot area)
only if there's no free space and therefore in-place update
is necessary.
Fixes: #839.
Add more context to possibly failing kernel keyring routines
in log debug output.
Mostly split debug output for errors while trying to search the kernel
key by description and errors while trying to read/unlink the key
by its id.
Libcryptsetup should not set such permissions. All
the issues it aims to solve can be workaround by
caller linking the key in appropriate keyring
first and moving it in final destination later.
We can not link internal VK kernel key in custom user
keyring. There are two reasons for it:
The internal VK kernel key description can not be
acquired via API and it may change over time
(LUKS2 reencryption).
With recent SED OPAL support volume key becomes a 'blob'
containing up to two keys (dm-crypt key for SWE and key
for unlocking SED OPAL locking range). The internal
kernel key contains only dm-crypt (if required) but
custom user keyring needs to be provided with whole
volume key (blob).
Added user specified key description for the linked key
in custom user keyring. The linked key can be reached by
the specified description after successful activation (resume).
keyring_link_key_to_keyring_key_type could accidentaly
mask an unreachable key and make it look that key was
succesfully linked in custome keyring when it was not.
Resize operation (crypt_resize) changes only size, so it is safe to
not flush IO (and freeze fs with lockfs) during suspend/resume cycle.
For dm-integrity there can be two suspend/resume cycles as the subsequesnt
call sets recalculating flag.
Based on patch from Yury Vostrikov <mon@unformed.ru>
Resolves: #832
If old util-linux is used, blkid scan can fail because disk
is already locked for OPAL.
Do the same for other internal blkid issue.
Also add some debug messages to be clear what's going on.
Some chipsets will set write-protection for the *full* drive
even if only small locking range is used.
As LUKS header expect to be writable ehen Opal LR is locked,
this is incompatible with LUKS.
Moreover, device need to be PSID reset and reconnected to clear
the flag. (And kernel lies about write protection so we cannot
get BLROGET ioctl to detect it.)
At least print some warning when LUKS2 header cannot be
written after Opal LR setup.
This applies for all USB adapters/firmware with RTL9210 chipset.
(Need experimental patch to enable Opal through USB.)
It makes key verification easier and also allows digest
verification for keys not assigned to device segment
(unbound keys) for more keyslot context types (tokens).
Add --volume-key-keyring option, which takes a name of a key in keyring,
which will be used as a VK during device activation. The key can be
specified in keyctl-compatible syntax "%<key_type>:<key_name>".
Test various combinations of arguments for the options
--link-vk-to-keyring and --volume-key-type. Add API tests for the
crypt_set_keyring_to_link and crypt_set_vk_keyring_type functions.
When using the --link-vk-to-keyring option, allow specifying the keyring
using the same syntax as keyctl (see "man keyctl"). E.g. "@u" for user
keyring and "%:testring" for a user-created keyring.
Add a new API crypt_set_keyring_to_link nad CLI option
--link-vk-to-keyring. This allows the user to specify ID of the keyring
where the VK should be linked.
Just unlink it from thread keyring where it is linked. The key should
get destroyed automatically once the reference count goes to zero, so
the revoke is redundant (unless there's a bug in the kernel keyring).
Note: the explicit revoke would destroy the key even when it is linked
to a user specified keyring.
Extends code so that later API may support LUKS2 device
activation via token with specified keyslot.
Also allows testing if specific token is able to unlock specific
keyslot.
When formating LUKS2 device with no keyslots area (it's valid
LUKS2 header) there's a bug in wipe routine that is supposed
to wipe LUKS2 keyslots area. When the keyslots area size is of
zero length it causes wipe function to erase whole data device
starting at defined data offset.
When no header is available but LUSK2_OPAL dm uuid
prefix is detected try to lock opal locking range
upon LUKS2 device deactivation (best effort only as
in crypt_suspend).
LUKS2 devices with configured HW OPAL encryption (any configuration)
get activated with private dm uuid prefix LUKS2-OPAL so that we
can properly detect devices with HW OPAL encryption even with
missing LUKS2 header (detached header). Internally LUKS2-OPAL
prefix matches LUKS2 device type.
Wipe and disable the segment. Also support the factory reset ioctl for
a complete wipe of the entire drive with a specific argument.
Signed-off-by: Luca Boccassi <bluca@debian.org>
While activation of internal cipher algorithms (like aes-generic)
is disallowed, some old LUKS2 images can still use it.
Check the cipher in activate call, but allow to load LUKS2 metadata.
This can allow to add repair code easily and also allow luksDump.
Also fix segfault in reencrypt code for such a header.
Fixes: #820
This enables creating dm-integrity devices that
does not use all available space but only initial
part of the device.
This will be used with future hw-opal-crypt segment
where partion may be not aligned to locking range
alignment and needs to be reduced.
We dont't want to span dm-integrity device into
area not included in opal locking range.
This allows to specify --hash sha or --hash blake2 to limit
KDF without need to specify full algorithm name
(similar to cipher where we already use substring match).
Deactivation code should deactivate dm-crypt device even if it is unknown
for libcryptsetup. Previous fix for cipher specification was too strict.
Let's allow initialization as null context, that allow status and
deactivate to be usable again.
Code verifying encryption parameters needs to be reusable
for new code that will be added later.
Also due to previous changes to data offset and metadata size
calculations, encryption parameters can now be verified at
single place without need to split it over crypt_format_luks2
routine.
Let's make LUKS2_generate_hdr as clean as possible. Cipher
specification string can be constructed in upper layers.
This will make future LUKS2_generate_hdr extension easier.
The integrity is optional parameter of dm-crypt segment definition.
Move the low level json code in appropriate json helper.
It will make adding new segment easier. The future hw-opal-crypt
segment will inherit all crypt fields.
Move all metadata size and data offset calculations
logic away from LUKS2_generate_hdr. The function
was meant to generate solely LUKS2 header on disk json
format.
The aim is to have all logic related data offset and metadata
size in one place available to be calculated in advance so
that we can easily extend the code.
The same problem fixed in commit 438cf1d1b3
is present in libdevmapper wrapper when parsing active device table.
The whole point of conversion was that non-authenticated modes
can be always represented in the old cipher-mode-iv format.
As the internal names contains dash, these are unsupported.
That said, the libdevmapper backend now correctly returns
full cipher specification including capi prefix for this case.
Init_by_name call now fails with incomplatible cipher definition error.
The common way to specify cipher mode in cryptsetup
is to use cipher-mode-iv notation (like aes-xts-plain64).
With introduction of authenticated ciphers we also allow "capi:<spec>"
notation that is directly used by dm-crypt (e.g. capi:xts(aes)-plain64).
CAPI specification was never intended to be used with internal
kernel crypto api names (with dash in algorithm name), actually the
whole parsing routine wrongly parses mode here now.
The code not checks if parsing wrongly separated the full cipher
string and effectively allowing only proper cipher names
(example of no longer supported string is capi:xts(ecb(aes-generic))-plain64).
Thanks to Jan Wichelmann, Luca Wilke and Thomas Eisenbarth from
University of Lübeck for noticing the problems with this code.
Fixes: #809
Aria cipher is similar to AES and is supported
in Linux kernel crypto API in recent releases.
This patch just add support for internal info table.
(This will cause that it is used also for keyslot
encryption if specified as a cipher argument.)
If a user explicitly specifies PBKDF parameters (like iterations,
used memory of threads), do not limit them, even if it can cause
resource exhaustion.
The only limits are hard limits per the PBKDF algorithm.
The force options were mostly used for decreasing parameters,
but it should work even opposite - despite the fact it can mean
shooting yourself in the foot (OOM).
Fixes: #812
Another example of FIPS theatre is that some vendors
implements hard limits for PBKDF attributes
(minimal password length, salt, etc).
This should be set by policy on another layer,
unfortunately someone apparently thinks it is a good idea
to harcode it to low-level crypto library directly.
This of course breaks some older test vectors
that use shorter attributes.
Just mark these and ignore possible API error in FIPS mode.
As tests shows, limiting used Argon2 memory to free memory on
systems without swap is still not enough.
Use just half of it, this should bring needed margin while
still use Argon2.
Note, for very-low memory constrained systems user should
avoid memory-hard PBKDF (IOW manually select PBKDF2), we
do not do this automatically.
Seems someone clever had an idea to return hash output
through API size even the hash is actually not available
in FIPS mode.
Just check also hash init in this case (as we already
do elsewhere).
If a partition is resized after format, activation could
fail when the device is not multiple of a sector size.
Print at least warning here as the message is only in syslog.
Related to Issue #807
Function is similar to json_object_object_add_by_uint but
it unsets *jobj_val_ref pointer if the function ends with
success.
It helps to create cleaner error patch and avoids eventual
double free corruption if **jobj_val_ref object changed
ownership.
It seems that autogen.sh is not called in some situations
(merge request updating configure scripts).
Let's move this directly before configure.
Also print disable-<feature> options to CI output.
This warning is displayed only if maximum memory was adjusted:
no swap, not enough memory, but is not printed if user set keyslot
memory cost above default limit intentionally.
In the latter case we have to check all available memory and guess
if swap is enough - this is not job af cryptsetup and also
it should not excessively parse any /sys files during keyslot open.
Benchmark for memory-hard KDF is tricky, seems that relying
on maximum half of physical memory is not enough.
Let's allow only free physical available space if there is no swap.
This should not cause changes on normal systems, at least.
Initialization by name for dm-crypt with integrity is always
underlying device for dm-integrity target, not dm-integrity
device itself.
This fixes various problems like refresh command or
device printed in status command.
Fixes: #801
The scrip for building dependencies statically still builds popt as a
shared library. The libdevmapper library is installed manually, but
incorrectly (libdevmapper.pc is installed, but it should be
devmapper.pc).
For OpenSSL2, we use PKCS5_PBKDF2_HMAC() function.
Unfortunately, the iteration count is defined as signed integer
(unlike unsigned in OpenSSL3 PARAMS KDF API).
This can lead to overflow and decreasing of actual iterations count.
In reality this can happen only if pbkdf-force-iterations is used.
This patch add check to INT_MAX if linked to older OpenSSL and
disallows such setting.
Note, this is misconception in OpenSSL2 API, cryptsetup internally
use uint32_t for iterations count.
Reported by wangzhiqiang <wangzhiqiang95@huawei.com> in cryptsetup list.
Patch libprotobuf-mutator to unpoison buffers obtained from libfuzzer
via LLVMFuzzerMutate. This is required as libfuzzer is usually not
compiled with memory sanitizer support (not even in OSS-Fuzz project,
see https://github.com/google/oss-fuzz/issues/864). Therefore, we
manually mark the buffer as initialized using __msan_unpoison.
Fixes OSS-fuzz bug 52541, 52543 and 52533.
When compiled with enforced ISO C (e.g. -std=c11) 'asm' inline
does not compile (it's GNU extension). Use __asm__ inline assembly
with GCC and clang compliers instead.
Fixes: #786.
For broken metadata BITLK format parsing can cause crash or out of memory
on several places.
Add better size checks to avoid parsing such a metadata.
Also be aware that entry_size can be smalle (so minus operation can underflow).
Also fix memory leak if FVEK entry is more than once in metadata
(just use the first entry and ignore others).
For broken metadata BITLK format parsing can cause crash or out of memory
on several places.
Add better size checks to avoid parsing such a metadata.
Fixes OSS-fuzz bug 54548,54553,54559.
AC_SYS_LARGEFILE autoconf macro is in use in configure script which will
add needed feature macros on commandline to enable 64bit off_t.
Also replace lseek64 with lseek, since it will be same when
_FILE_OFFSET_BITS=64 is defined on relevant platforms via AC_SYS_LARGEFILE
This fixes build with latest musl, where LFS64 interfaces are moved out
of _GNU_SOURCE feature test macros namespace [1]
[1] https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* added fuzz target 'crypt2_load_ondisk_fuzz' that tries to load fuzz input as LUKS1, FileVault2, BitLocker in that order.
* added dictionary for this fuzz target
* added fuzz target to relevant files
If format load fails in some intermediate step, the internal
params struct can contain already set values.
While context is set still to none type, it can cause segfault
in releasing active_name.
(Found by fuzzing target processing crypt_load.)
Skip tests that can not satisfy minimal test passphrase length:
- empty passphrase
- LUKS1 cipher_null tests (empty passphrase is mandatory)
- LUKS1 encryption
The device_check is done in header write functions,
but these are not recached in normal format path as wipe call
is called earlier.
Call the device check also from wipe function to get better error
description.
This situation happens for example when a block device is too small
(regular file can be enlarged by falloc(); block device cannot).
Activation with header only fails too late (in device-mapper
call) while it is clear from the beginning that it cannot succeed.
Just add an early and better worded error.
Ignore this situation for block device (we have to call ioctl to get size).
The most common case is a file container here anyway.
For block devices it fails during activation later.
Header write can call falloc() to increase image size, so we should
check data offset after header is written.
Also change wording to be less cryptic and describe what is the real problem.
Note that the code can be used this way to crate detached header (without
space for data), so it is not an error.
Also fix Makefile to include source in make dist.
Note: we must not use CFLAGS there because possible sanitizers
use will make the loaded library unusable in LD_PRELOAD.
Extends avaiable methods for retrieving device volume key.
The volume key now may be extracted using passphrase, keyfile
(passphrase in a file) or token (LUKS2 only).
For LUKS devices, it returns generated volume key after
sucessfull crypt_format where new volume key got generated.
Fixes: #777.
First, there was a bug where passphrase based
keyslot contextets did not cache volume keys
properly and caused leaks.
Second, it causes problems when keyslot context
is used twice with different keyslot id, e.g.:
CRYPT_ANY_SLOT vs specific id, unbound key vs
volume key, etc.
The function is supposed to check if manipulated
active dm-crypt device matches the on-disk metadata.
Unfortunately it did not take into account differences
between normal cipher specification (aes-xts-plain64)
and capi format specification (capi:xts(aes)-plain64).
The internal query function always converted capi format
in normal format and therefor failed if capi format was
used in metadata.
Fixes: #759.
- Do not require any libraries installed, download everything
from upstream git, statically compile (use include, libs and pkg-config
from local directory under tests/fuzz).
Script should work both from OSS-Fuzz and locally.
- Do not require local protobuf (only staticallly compiled, see above).
- Add README.md (TBD, still not finished).
- Fix make dist and distcheck.
- Remove common.[ch] as we can use internal function.
This makes fuzzers also C++ only (remove CFLAGS from Makefile).
In LUKS1 there is only one hash algorithm specification,
it cannot happen, that AF hash algorithm is not
available, as it is used immediately before in PBKDF2.
In LUKS2 this can be completely different algorithm, so
it make sense to print a visible warning for user.
For example, Whirlpool and RIPEMD160 is now in OpenSSL legacy
provider which can be unavailable, see #773.)
This patch adds a message only, the code already fails with -EINVAL.
In practice luksAddKey action does two operations. It unlocks existing
device volume key and stores unlocked volume key in a new keyslot.
Previously the options were limited to key files and passphrases.
With this patch user may combine freely following options:
To unlock keyslot with volume key user may:
- provide existing passphrase via interactive prompt (default method)
- use --key-file option to provide file with a valid passphrase to existing keyslot
- provide volume key directly via --volume-key-file
- unlock keyslot via all available LUKS2 tokens by --token-only
- unlock keyslot via specific token with --token-id
- unlock keyslot via specific token type by --token-type
To provide the passphrase for a new keyslot user may:
- provide existing passphrase via interactive prompt (default method)
- use --new-keyfile parameter or positional parameter to read the
passphrase from file.
- use --new-token-id to select specific LUKS2 token to get passphrase
for new keyslot. New keyslot is assigned to selected token id if
operation is succesfull.
Fixes: #725.
The crypt_keyslot_add_by_keyslot_context & associated
helper functions allow more options when adding new
keyslot. For example there was no simple way of
adding new LUKS2 keyslot when the only active keyslot
could be unlocked by passphrase (KEK) provided by LUKS2 token
(plugin). Now all available options for unlocking keyslots
may also be used when creating new keyslot and it combine
as called needs.
The available methods (keyslot contexts) are:
passphrase, keyfile, key (binary representation) and LUSK2 token.
json-c parser transforms NULL pointer into special '(null)' string.
While being technically correct it hides the fact user passed NULL
pointer in crypt_token_params_luks2_keyring structure. This bug
could be trigerred by calling crypt_token_luks2_keyring_set().
Following API calls trigerred LUKS2 metadata reload
from storage in case of failure:
crypt_convert
crypt_keyslot_add_by_key
crypt_keyslot_add_by_keyfile_device_offset
crypt_keyslot_add_by_passphrase
crypt_keyslot_change_by_passphrase
crypt_reencrypt_init_by_keyring
crypt_reencrypt_init_by_passphrase
This patch replaces LUKS2 metadata reload with
backup LUKS2 metadata copy kept in memory that is updated on
each sucessfull metadata write and rolled back to it whenever
needed in any of those calls listed above.
The content of LUKS header is not a key material, no need
to lock memory for possibly big header and big memory area locks.
Just ensure we wipe buffer before release of memory.
This patch locks all memory ranges in safe allocations.
While crypto backend can have some secure memory calls,
it is usually limited by intitial config.
For our use is enough to keep keys in memory and prevent
swapping it out.
If the lock fails (because of limits) we quietly
stay with plain malloc.
System FIPS mode check is no longer dependent on /etc/system-fips
file. The change should be compatible with older distributions since
we now depend on crypto backend internal routine.
This commit affects only FIPS enabled systems (with FIPS enabled
builds). In case this causes any regression in current distributions
feel free to drop the patch.
For reference see https://bugzilla.redhat.com/show_bug.cgi?id=2080516
The Debian tooling sets ‘LDFLAGS = -Wl,-z,relro -Wl,-z,now’ and
complains when anything is built without hardened compiler/linker flags.
Granted this is a non-issue here since fake_token_path.so isn't included
in any binary package, but muting the false positive is arguably no
better fix than honoring $(LDFLAGS) during the build.
When reencrypting image files cryptsetup is unable to
detect reliably if image file is in use or not.
User must decide it explictly. Add error message that
references --force-offline-reencrypt to solve the issue
in non interactive mode.
(It will be replaced with early detection in before 2.5.0 final
release).
Do not invalidate LUKS2 format when future online-reencrypt
requirement flag is encountered (by older releases).
But it must stop device from being activated, reencrypted
or modified.
Empty context or any non-LUKS types now returns
CRYPT_REENCRYPT_INVALID value.
For LUKS1 devices return CRYPT_REENCRYPT_NONE
(since any LUKS1 device in legacy reencryption
does not have valid LUKS1 header/metadata).
If keyslots are not sorted according to binary area offset,
the calculation of area size is wrong and can overflow
(LUKS1 does not store area size, only offset).
Let's just use function that calculates size from volume key size.
Images where keyslot areas are not aligned to 4k offset
are not supported anyway.
Fixes: #753
By not testing repeatedly that 'wipe' test utility actually
wipes the device. This test is supposed to test reencryption
code.
I have left untouched already existing first time checks
for each data digest.
Invalid values that overflows in interval check were silently ignored.
Fix this by explictily adding check for interval overflow in keyslots
and segment validation.
Fixes: #748
Adds support for LUKS2 decryption of devices with a
header put in the head of data device. During the initialization
header is exported to a file and first data segment
is moved to head of data device in place of original header.
The feature introduces several new resilience modes (combination
of existing modes datashift and "checksum" or "journal").
Where datashift resilience mode is applied for data moved towards
the first segment and first segment is decrypted in-place.
The mode is not backward compatible with prior LUKS2 reencryption
and therefor interrupted operation in progress can not be resumed
using older cryptsetup releases.
Fixes: #669.
Upper layers always expected 0 on error.
Due to this bug this function could cause
sector_size overflow when segment definition
did not contain 'sector_size' field ('linear').
If some kdf are not available, we incuidentally returned EINVAL
error code instead od EPERM.
This caused that error message is not correctly printed and also
retry count is not applied.
Fixes: #745.
Refresh (and therefore suspend hotzone) reencryption dm
segments in-before actual hotzone reencryption takes place.
This commit shortens time window during which hotzone is
suspended. Also it avoids eventual deadlock if reencryption process
triggers page miss during storage wrapper reinitialization and required
data is stored in (previously) suspended hotzone (corner case).
Checksum hash parameter obtained via API call can not be used directly.
It gets lost during subsequent call to crypt_reencrypt_init_by_* API
when library reloads crypt context.
There are some historic incompatibilities that are ignored
for LUKS1 but do not work for LUKS2.
Check the cipher before conversion through crypto backend.
Also it switches LUKS2_check_cipher to use userspace backend only
(this should be ok for the reencryption code that uses it too).
Fixes: #641
Due to commit 0113ac2d88
we recalculate reencryption digest whenever LUKS2 reencryption
keyslot gets updated. Until now we perform reencryption digest
refresh every time we call LUKS2_keyslot_reencrypt_update even
when no metadata was updated.
This improves on it and should speed up reencryption resume
process.
The LUKS2 reencrypt keyslot update process should
not be performed in crypt_reencrypt_run() loop where
data reencryption takes place.
The proper location is reencryption process initialization
when we validate reencryption metadata and decide if
new user provided resilience metadata are valid.
Prior to commit 0113ac2d88 it did
not matter what resilince metadata we stored during initialization.
So we stored 'none' type unless 'datashift' operation was initialized.
After the commit, it triggered reencryption metadata digest refresh
almost each time (except 'datashift') which was suboptimal.
By storing proper resilience type during reencryption initialization
we will avoid the needless reencryption digest refresh later (after
update optimization).
The structure is supposed to store all data necessary to perform
reencryption crash recovery. The data block size stored
in LUKS2 metadata was missing and stored in reencryption top level handle
instead.
Ths will allow automatic scan of known formats.
Errors are printed only if something is wrong with already detected metadata.
This change means that it is responsibility of the caller to print an error
message if needed.
Also fix some places without a message.
Fixes: #642
If cryptsetup/integritysetup tool is too old, it can happen that
kernel dm-integrity uses more recent version of dm-integrity metadata.
Print (and also traslate) better error in this case.
Fixes: #667
If LUKS2 is used with integrity protection, there is always a dm-integrity
device underneath.
We should deactivate the device if DM status return tag size (it means,
that dm-crypt uses dm-integrity DIF).
This allows "cryptsetup close <name>" peroperly remove both stacked devices
even if LUKS2 header is no longer available (like in detached header activation).
While the metadata device is detached header here, integrity
superblock is located on the data device.
For standalone integrity device it is diffferent
- data device contains only data and possible metadata device
contains integrity superblock and tag areas.
Fix it by checking metadata format.
Fixes: #609,#730
Fast xxhash64 algoritm can be used for integrity protection.
Add implicit tag size (so user do not need to use --tag-size),
mention it in man page and add a test.
Fixes: #632
If existing data device is used, user must specify --no-wipe option
otherwise data device is wiped.
(Tags then can be recalculated on activation with --integrity-recalculate option).
Fixes: #679
INTEGRITY_key_size returns -EINVAL for algorithms without a key
and because crypt_params_integrity.integrity_key_size is an
unsigned integer we get key size 4294967274 instead of more
appropriate 0 for these algorithms.
Calculating device sizes for verity devices is a little bit tricky,
Data, hash and FEC can share devices or it can be a separate devices.
This patch prints used device sizes in veritysetup dump command,
but it requires that user specifies all values that are not stored
in superblock (like a FEC device and FEC roots).
Replace check for argp_usage by argp_parse as argp_usage is not used by
cryptsetup. Moreover, this will fix the following build failure raised
with argp-standalone in version 1.4.0 and
e7ff8d9787:
/home/autobuild/autobuild/instance-10/output-1/host/lib/gcc/i686-buildroot-linux-musl/10.3.0/../../../../i686-buildroot-linux-musl/bin/ld: tokens/ssh/cryptsetup_ssh-cryptsetup-ssh.o: in function `parse_opt':
cryptsetup-ssh.c:(.text+0x14c): undefined reference to `argp_state_help'
/home/autobuild/autobuild/instance-10/output-1/host/lib/gcc/i686-buildroot-linux-musl/10.3.0/../../../../i686-buildroot-linux-musl/bin/ld: tokens/ssh/cryptsetup_ssh-cryptsetup-ssh.o: in function `main':
cryptsetup-ssh.c:(.text+0x7db): undefined reference to `argp_parse'
Fixes:
- http://autobuild.buildroot.org/results/cb3fdae4e0da603f304501f65127800346cb3915
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
The function wrongly expected segment objects being
ordered (ascending order) in segments container.
The LUKS2 format never guaranteed that and it could
lead to wrong LUKS2 device size calculation in case
last segment (by key) was stored before any other segment
with fixed size.
The eventual logical block size increase on dm-crypt device above
filesystem block size may lead making fs unusable. Do not allow
offline reencryption when sector size increase is requested.
If users really want to perform it make them use existing
--force-offline-reencrypt option.
The journal crypt is in wrong format (this never worked! :),
here it takes kernel syntax.
Also use CBC a CTR mode could be missing here.
Fox typo in key length caclulation.
Clear temporary dm devices after test, loop devices are reused.
If the first device format is ok, all subsequent cals should
be treated as an error.
By changing encryption sector size during reencryption we may
increase effective logical block size for dm-crypt active device.
For example if hosted filesystem on encrypted data device
has block size set to 512 bytes and we increase dm-crypt logical
size durign reencryption to 4096 bytes it breaks the filesystem.
Do not allow encryption sector size to be increased over value
provided by fs superblock in BLOCK_SIZE property.
The check is applied while initialising LUKS2 device encryption
(reencrypt --encrypt/--new) or when initialising LUKS2 reencryption
on active dm-crypt device.
Note that this check cannot be applied on offline device (data device
is encrypted).
We should abort LUKS device in-place encryption
when target data device or metadata device
contain broken LUKS metadata (any version).
Filed crypt_load() call was not good enough check
because the call fails also when a device contains
LUKS metadata overlapping with other superblock
(e.g. LVM2 PV signature).
Let blkid decide if device contains broken LUKS
metadata or not.
Fixes: #723.
Do not resume reencryption operation with conflicting parameters.
For example if operation was initialized as --encrypt do not
allow resume with oposing parameter --decrypt and vice versa.
Also checks for conflicting --resilience parameters (datashift cannot
be changed after initialization).
Previously, conflicting reencryption parameters were silently ignored.
So, for example operation initialized with mode --encrypt and resumed
with mode --decrypt simply finished --encrypt operation and did not
report any error. This could lead to impresion different type of
operation was perfomed instead.
Fixes: #570.
If auto-detection fails for other reason just return the
error. Users may now bypass active device auto-detection
with --force-offline-reencrypt option.
It can be used to enforce offline reencryption
in batch mode when data_device is regular file
and therefore cryptsetup cannot detect properly
active device dm name.
Also it may be useful when active device
auto-detection fails for some reason and user
has no other choice but inspect device holders
manually.
To allow resizing integrity devices with detached metadata device, the
check has to be moved from _compare_integrity_devices to
_reload_device_with_integrity.
If the provided key is NULL, we load it from the active device. This is
always available, since keyring keys are not supported in kernel for
integrity devices.
Try to avoid accidental nested encryption via
cryptsetup reencrypt --new/--encrypt command.
If detached header or data device is already reported
as LUKS1 or LUKS2 device operation gets aborted.
Fixes: #713.
Bitlocker compatible mode uses dm-zero to mask metadata area,
device cannot be activated if dm-zero is not available.
Just add zero target check to device-mapper backend and
if activation fails, print a better error message here.
Fixes: #722
When user provides --token-type or specific --token-id
prefer token PIN query over passphrase query (if token
handler responds with 'PIN needed').
Fixes: #670.
The progress routine is now fully translated and
prints out progress in following manner (examples):
Progress: 25,5%, ETA 00m31s, 7 GiB written, speed 838,6 MiB/s
Progress: 25,5%, ETA 20h11m31s, 7 GiB written, speed 24 KiB/s
Progress: 25,5%, ETA 06 days, 12 MiB written, speed 4 KiB/s
Also got rid of -lm dependency due to floor().
Fixes: #671.
If passphrase is read from a real terminal, there is maximum
interactive input length applied. This means that passphrase
can be trimmed in this case.
This patch adds debug log warning, if read does not detect
end of input (EOL or EOF) and the maximal input read is achieved.
We cannot say for sure if the next character is EOL without
actually reading it, debug warning should be enough in this case.
Fixes: #699
Commit 0113ac2d broke test passphrase mode when
device was in LUKS2 reencryption.
Previously --test-passphrase parameter automatically raised
CRYPT_ACTIVATE_ALLOW_UNBOUND_KEY flag. It did not make sense
when users mostly want to test whether device can be activated by
provided passphrase or not. Raise the aforementioned flag only
if user requested it either by --unbound parameter or when
specific keyslot was selected.
Reported in: https://bugzilla.redhat.com/show_bug.cgi?id=2056439Fixes: #716.
Move code setting data device during format so that
we can properly detect optimal encryption sector size
for data device instead of metadata device (header).
Fixes: #708.
We should avoid silently skipping the test if there is something
wrong with the test itself. If we have all dependencies, the test
should be able to run.
ssh-copy-id requires password authentication that might be disabled
on some cloud images. We can simply copy the key manually, because
everything runs on localhost anyway.
Fixes: #701
Abort action luksResume early if device is not suspended.
We would needlesly ask for passphrase or load cryptsetup
plugins only to fail later in crypt_resume_by_* API.
If configured with --disable-cryptsetup (e.g. if only veritysetup is
required), these tests won't be able to run cryptsetup, so they need
to be skipped.
It breaks compile time check for __attribute__((__symver__))
and it does not make sense either. Quoting gcc man page:
-Wno-attributes
Do not warn if an unexpected "__attribute__" is used, such as
unrecognized attributes, function attributes applied to variables,
etc. This does not stop errors for incorrect use of supported attributes.
Well, we do want to check for unsupported __attributes__ un our code,
right?
Attribute unused is useless and makes code imcomprehensible
when decorates internal functions not exposed via API.
Let's cleanup internal funtion prototypes whenever possible.
Returning from the thread creation function is documented to be a valid
way of exiting a thread on both Windows and pthread systems. Removing
the explicit call avoids the need to install libgcc_s.so in initramfs
for glibc systems, and slightly reduces code size.
Upstream: https://github.com/P-H-C/phc-winner-argon2/pull/331
This should silence similar warnings like
warning: cast from 'char *' to 'struct xyz *' increases required alignment from 1 to X
when we try to calclulate byte pointer offsets in a buffer.
Apparently FIPS mode enforces somewhere minimal key size.
As 64bit key is no longer useful anyway, just remove it.
Apparently cipher_null is now more safer with the longer key,
isn't? :-)
OpenSSL with FIPS provider now doesn't not support SHA1.
Kernel still does, but some operations fail anyway (we get
hash size from crypto backend).
Let's remove most of the SHA1 use in tests, SHA1 removal
will happen anyway.
The LUKS1 compatimage is regenerated with the same parameters,
just hash is switched to sha256 so we do not need to fix tests.
OpenSSL now enforces minimal parameters for PBKDF2 according to SP 800-132
key length (112 bits), minimal salt length (128 bits) and minimal number
of iterations (1000).
Our benchmark violates this, causeing cryptsetup misbehave for luksFormat.
Just inrease tet salt to 16 bytes here, it will little bit influence benchmark,
but there is no way back.
It is almost impossible for contributors to replicate our warnings
if filtered. Let's make it simpler.
Also run clang with extended warnings (some fixes needed).
`make -f Makefile.localtest tests CRYPTSETUP_PATH=/sbin TESTSUITE_NOSKIP=y`
exits with status 77 upon the first skipped test. This can be useful
when a full test coverage is desired.
As before the test suite exits (with status 1) as soon as a failed (or
skipped when the TESTSUITE_NOSKIP environment variable is defined to
non-empty string) test is encountered.
AFAIK older versions of the POSIX Standard didn't specify a way to
locate commands. Many operating systems and distributions added a
which(1) utility for that purpose, unfortunately without consistent
behavior across the board.
OTOH POSIX.1-2008 (or was it older? POSIX.1-2001 mentions it too, but
with a restriction: “On systems supporting the User Portability Utilities
option”) specifies that `command -v` can be used for that purpose:
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/command.html
Moreover the standard adds that if the argument is neither a valid
utility, builtin, shell function nor alias then “no output shall be
written and the exit status shall reflect that the name was not found”.
It's therefore no longer needed to void the error output (spewing error
messages was one of the inconsistent behavior of the different which(1)
utilities).
The upcoming Debian 12 (codename Bookworm) appears to have deprecated
its which(1) utility (as a first step for its removal from the base
system):
$ which foo
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
In most places the deprecation notice isn't visible when running the
test suite because most `which` calls run with the error output
redirected to /dev/null, however this is not the case everywhere:
https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.4.3/tests/integrity-compat-test#L333https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.4.3/tests/reencryption-compat-test2#L232
This commit replaces all `which` calls from tests/* with `command -v`,
and removes the error output redirection.
crypt_reencrypt_status() returns this flag if old
online-reencrypt requirement is detected and reencryption
keyslot digest is missing.
crypt_reencrypt_init_by_passphrase() with same flag applied
repairs (upgrade) reencryption metadata so that
automatic reencryption recovery during activation
is again possible and reencryption operation can be resumed
post CVE-2021-4122 fix.
The function never writes on-disk. Also removed validation
function call-in since it will be called later before
writing on-disk and metadata does not have to be complete
at the moment of LUKS2_keyslot_reencrypt_allocate call.
The option --disable-luks2-reencryption completely disable
LUKS2 reencryption code.
When used, the libcryptsetup library can read metadata with
reencryption code, but all reencryption API calls and cryptsetup
reencrypt commands are disabled.
Devices with online reencryption in progress cannot be activated.
This option can cause some incompatibilities. Please use with care.
Fix possible attacks against data confidentiality through LUKS2 online
reencryption extension crash recovery.
An attacker can modify on-disk metadata to simulate decryption in
progress with crashed (unfinished) reencryption step and persistently
decrypt part of the LUKS device.
This attack requires repeated physical access to the LUKS device but
no knowledge of user passphrases.
The decryption step is performed after a valid user activates
the device with a correct passphrase and modified metadata.
There are no visible warnings for the user that such recovery happened
(except using the luksDump command). The attack can also be reversed
afterward (simulating crashed encryption from a plaintext) with
possible modification of revealed plaintext.
The problem was caused by reusing a mechanism designed for actual
reencryption operation without reassessing the security impact for new
encryption and decryption operations. While the reencryption requires
calculating and verifying both key digests, no digest was needed to
initiate decryption recovery if the destination is plaintext (no
encryption key). Also, some metadata (like encryption cipher) is not
protected, and an attacker could change it. Note that LUKS2 protects
visible metadata only when a random change occurs. It does not protect
against intentional modification but such modification must not cause
a violation of data confidentiality.
The fix introduces additional digest protection of reencryption
metadata. The digest is calculated from known keys and critical
reencryption metadata. Now an attacker cannot create correct metadata
digest without knowledge of a passphrase for used keyslots.
For more details, see LUKS2 On-Disk Format Specification version 1.1.0.
Windows 11 now includes the BitLocker volume GUID in the BEK file
metadata entries. This was previously not included so cryptsetup
refused to open the file because there was an unknown metadata
entry in the startup key.
Fixes: #690
LUKS2 encryption with data shift required remaining
data size (size remaining after substracting --reduce-data-size value)
to be at least --reduce-data-size. This was wrong. Remaining
data size restriction should be correctly at least single sector
(whatever sector size is selected or auto-detected).
Currently, token import and token add actions will fail if you use the
--token-id option to specify a token ID that is already in use, but there
are scenarios where you might genuinely want to replace an existing token
in a single atomic operation.
A use case for this might be for a keyslot that is protected by a
TPM, where you store the TPM sealed key and associated metadata as a
token and you want to update the PCR policy associated with the sealed
object or make other changes to it. Currently this requires importing a
new token and then removing the old token.
Instead, add a --token-replace option to allow token import and token
add to replace an existing token if you try to add or import one with an
ID that is already in use.
On some "broken" systems, udev directory (where we try to check
if device is active) is present, but the symlink is missing.
Let's fallback in this case on sysfs scanning also, otherwise
possible conversion of an active device can cause data corruption.
LUKS2 code read the whole header to buffer to verify checksum,
so malloc is called on unvalidated input size parameter.
This can cause out of memory or unintentional device reads.
(Header validation will fail later anyway - the size is unsupported.)
Just do not allow too small and too big allocations here and fail quickly.
Fixes: #683.
These tools do not read passphrases, no need to link to these libraries.
Just move the helper code that introduced this dependence as a side-effect.
Fixes: #677
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).
Currently LUKS2 decryption cannot perform data decryption
with data shift. Even though we can decrypt devices with
data offset > 0 in LUKS2 metadata it does not make much
sense. Such devices cannot be easily mounted after decryption
is finished due to said data offset (fs superblock is moved
typicaly by 16MiBs).
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
While adding or importing new token and assigning immediately to
keyslot it would be useful to provide specific error message
directly from cryptsetup utility when keyslot does not exist.
If distro does not use udev/blkid, there is no IO event after activation.
Kernel does not mark the device corrupted then (it happens on the
first IO). Just add a simple read to trigger it.
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.)
If crypto backend does not provide configured hash,
fail crypto backend tests.
(User has to use configure option if backend does not provide seclected algorithm.)
Seen recently with RIPEMD160.
Note: NSS does not provide RIPEMD, use --with-plain-hash etc.
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.)
Allow to pass the root hash via a file, rather than verbatim on
the command line, for the open/verify/format actions.
It is much more convenient when using veritysetup in scripts.
[some modifications by mbroz:]
- Add additional syntax and option description to man page.
- Fix a segfault with non-existing path.
- Do not read full file.
- Small refactor for argc handling and option processing.
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.
Currently the "add" action adds the token to all keyslots, this
changes the behaviour to make sure the token is added to the first
keyslot that can be unlocked using the provided passphrase.
Test needs to work also in build environment
before installation takes place. For it we overload
crypt_token_external_path symbol from libcryptsetup
so that it can look for plugins in build environment.
[simplified by mbroz]
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.
Cryptsetup LUKS2 was using Argon2 while there were two versions -
data independt (Argon2i) suitable for the KDF use case andm Argon2d
(data dependent), that is in princile unsuitable for LUKS2.
Later a new version Argon2id was introduced and this is now default
(and mandatory) algorithm as RFC Argon2 draft defines.
While Argon2id basically combines both approaches from Argon2i
and Argon2d (to provide bette side-channel resistence) it seems
reasonable to switch to Argon2id as default.
Fixes: #555
While TrueCrypt is no longer developed and supported since 2014,
VeraCrypt devices (as a successor of TrueCrypt) are much more
used today.
This patch switch default to scan for VeraCrypt signature, making
--veracrypt option obsolete (ignored by default as it is default).
If you need to disable VeraCrypt support, use new option
--disable-veracrypt.
This patch fixes several problems:
- some optional features for dm-verity can be larger than pre-allocated buffer
- device paths and other strings can be allocated dynamically
- featured options with keys in dm-integrity are not wiped on stack
- get rid of strncat()
- always check return code of snprintf
Related #648
Due to nature of recent change in GCC10 that silently
broken symbol versioning, let's be a bit pedantic
and test all symbols are available in all versions that
meant to be exported to users.
Starting with GCC10 and LTO enabled, current symbols
versioning hack does not work anymore. This patch
reflects on that and should be compatible with older
compilers that does not support __attribute__((symver))
yet.
Inspired by following code:
https://github.com/linux-rdma/rdma-core/blob/master/util/symver.h
The new dm-integrity option in kernel 5.13 can restart
recalculation from the beginning of the device.
It can be used to change the integrity checksum function.
This patch adds support to libcryptsetup for this flag
and adds --integrity-recalculate-rest option to integritysetup.
Fixes: #631.
In ideal system nothing should touch test devices, but to make tests
more robust, we should expect that something is still scanning devices
after activation. So replace all checks for CRYPT_ACTIVE to allow
also CRYPT_BUSY.
(Fixes some problems seen in #633)
We support most recent crypto algorithms, so this
is only addition of the Blake hash family.
Kernel and gcrypt crypto backend supports all variants,
OpenSSL only Blake2b-512 and Blake2s-256.
There is no useable support for NSS and Nettle yet.
Crypto backend supports kernel notation e.g. "blake2b-512"
that is translated to the library backend names.
Starting with version 2.0.0, libpasswdqc can use memory allocation
when loading configuration that contains new optional parameters.
It's therefore recommended to free all memory allocated by
passwdqc_params_load using new passwdqc_params_free function
introduced in the same version of libpasswdqc.
[slightly modified by mbroz]
Some stable kernels started to return buffer from terminal
in partial buffers of maximal size 64 bytes.
This breaks all passphrases longer than 64 characters entered
through interactive input (for all crypto formats).
(The problem is probably fixed in more recent kernels, but
the read() call can always return a partial read here.)
This patch also fixes wrong password limit, the last character
of passphrase of maximal size was never handled.
Now the maximal passphrase length is really 512 characters.
Fixes: #627.
Most of these functions already works even with device=NULL.
There can be some rare situations when this call could happen,
so be safe always.
(Like initialization for a device that disappears during init.)
Also see
https://bugzilla.redhat.com/show_bug.cgi?id=1932946
The error correction can fix even problem with root hash.
For now, always return fail if initial check of root hash failed.
FIXME: The FEC verify code need to be rewritten to repair only
blocks where hash is wrong and the re-check hash after recovery,
inclkuding root hash.
Now we do not check hash after FEC recovery. The Reed-Solomon
decoder can then "repair" code wrongly if parity is too damaged.
For now, the information about FEC repaired errors is only
advisory, it does not mean device is fully repaireable.
Do not write more than needed header if hash area is not used later.
All space in hash area is then used in FEC calculation, so it makes
no sense to add unused area.
Reencryption did not take into account adjusted xts
key size configuration option. This patch fix the
issue by using same logic as in luksFormat with xts
mode selected for data encryption.
By default when reencrypting LUKS2 device we regenerate only
the volume key. But if the device was 'encrypted' by cipher_null
this change did not make sense. The key was always empty.
Change the behaviour so that unless user specifies --cipher
parameter on command line, we change data encryption cipher
to default when old segment cipher was cipher_null.
By mistake LUKS2 allowed keyslots 'not-so-encrypted' by
cipher_null (only explicitly requested by --cipher or
--keyslot-cipher parameters). If we encounter
such old key during reencryption let's replace the cipher
for new keyslot with default LUKS2 keyslot cipher.
It does not make sense to upload volume keys in
kernel keyring if segment cipher is cipher_null.
The real volume_key is thrown away and replaced
with empty key anyway.
This bug enabled to create LUKS2 keyslots encrypted by
cipher_null when explicitely requested by user. LUKS2
was never meant to allow keyslot encryption with
cipher_null. cipher_null is meant for debug purposes
only as a segment cipher.
FEC (Forward Error Correction) data should cover the whole data area,
hashes (Merkle tree) and optionally additional metadata (located after hash area).
Unfortunately, if FEC data is stored in the same file as hash, the calculation
wrongly used the whole file size thus overlaps with FEC area itself.
This produces unusable and too large FEC data.
(There is not a problem if FEC image is a separate image.)
This patch fixes the problem, introducing FEC blocks calculation as:
-If hash device is in a separate image, metadata covers the whole rest of the image after hash area.
(Unchanged behaviour.)
-If hash and FEC device is in the image, metadata ends on the FEC area offset.
This should probably fix several issues reported with FEC wrong calculations.
Fixes: #554
If FEC was enabled, the error for bad root hash was replaced
by error correction (datga were ok, only root hash was wrong).
Do not run recovery test if root hash is incorrect.
To avoid confusion, use just one lib include and specify sub-directories
for format inclusions.
This should also help some analysis tools to find proper includes.
It is called from kernel crypt backend unconditionally with
the proper define in config.h but some static parrsers are not so clever.
Compilation will fail in linker phase anyway if wrongly used.
The routine was originaly used in code for resetting default
argument values. It was used in cli plugins related code
where we needed to parse command line arguments twice.
This fixes multiple issues found by coverity in the startup key
code and also makes the parsing less complicated -- we don't need
to loop through all metadata entries in the BEK file if we are
expecting only one metadata entry of a specific type.
These are false positives and gcc internal detection of this
pattern seems to be broken again.
In this path we must avoid memcpy the whole buffer, it can contain
some bytes after null char, so use MIN/strlen here.
Provides example of loadable token handler for activation
json validation and metadata dump.
For creating new ssh example token use special cryptsetup-ssh
binary.
Add API call that can directly print JSON metadata area from LUKS2 device.
For commandline it also adds --dump-json-metadata option for luksDump action.
Note that the binary metadata (UUID, version etc) is not part of this output.
(We reserve flags parameter to be able to add this later.)
Fixes: #511
The code expects that change key is done in-place if there is not
a free space in keyslot area for safe key swap.
This patch makes the code behaves the same as in LUKS1,
luksChangeKey now works the same.
With JSON, we can actually retain the slot number in all cases
(except user intentionally set new slot #).
This patch changes the crypt_keyslot_change_by_passphrase() API
call to retain keyslot number for LUKS2.
Fixes: #464
We cannot trust possibly broken keyslots metadata here through LUKS_keyslots_offset().
Expect first keyslot is aligned, if not, then manual repair is neccessary.
(This situation happen if partition table signarture overwrites slot 4 area).
Also, if keyslot order is different, current repair code does not work properly
(this can happen only with downconverting LUKS2 device).
This patch adds support for Linux kernel (since version 5.11) dm-integrity
fixes that disables integrity recalculation if keyed algorithms (HMAC) is used.
Original dm-integrity superblock version <=4 is recalculation offset
field not protected by HMAC. An attacker can move this pointer and force
the kernel to recalculate the data area, ignoring original HMAC tags.
N.B. dm-integrity was not intended to protect against intentional changes.
Better use authenticated encryption (AEAD) in combination with dm-crypt.
It is designed to protect against random data corruption caused by hardware
or storage medium faults.
Despite that, we try to keep the system secure if keyed algorithms are used.
There are two possible keyed algorithms in dm-integrity - algorithm used
to protect journal and superblock (--journal-integrity) and algorithms
for protecting data (--integrity).
The dm-integrity superblock is guarded by --journal-integrity, so if you want
to protect data with HMAC, you should always also use HMAC for --journal-integrity.
The keys are independent. If HMAC is used for data but not for the journal,
recalculation is disabled by default.
For new kernel dm-integrity, the HMAC option also uses salt in superblock
to avoid an easy way to distinguish that the HMAC key is the same for two devices
(if data are the same).
The new HMAC and superblock are enabled automatically if the kernel supports it
(you can see superblock version 5 and fix_hmac flag in dump command).
If you need to use (insecure) backward compatibility, then two new integritysetup
options are introduced:
Use --integrity-legacy-recalc (instead of --integrity-recalc) to allow recalculation
on legacy devices.
Use --integrity-legacy-hmac in format action to force old insecure version
format (with HMAC).
Libcryptsetup API also introduces flags
CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and
CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC
to set these through crypt_set_compatibility() call.
The crypt_activate_by_pin_token may be used only from new
dynamicly loadable token plugins.
Also refactors code for dynamically loadable plugins so
that it does not use crypt_token_handler structure anymore.
Old structure remains used only in crypt_token_register call.
This reverts mostly these commits:
42692418c2a985c12659
The library was ment to export common functions shared by
all cryptsetup tools and planned LUKS2 tokens plugins.
It is no longer needed.
THis fixes a problem for TCRYPT and reencryption in scripts
where "Nothing to read on input." is displayed because
cryptsetup retries password query even in stdin mode.
LUKS2 decryption is currently not supported for devices
with LUKS2 metadata placed in head of data devices. The decryption
still works correctly, but resulting plaintext device has data on
unexpected (original) offset. For example at offset of 16MiB in case
of default LUKS2 header.
Fixes: #614.
crypt_header_is_detached checks if initialized LUKS context uses detached header
(LUKS header located on a different device than data.)
This is a runtime attribute, it does not say if a LUKS device requires detached header.
If user knows which particular PBKDF2 hash or cipher is used for
True/VeraCrypt container, using --hash of --cipher option in tcryptDump
and tcryptOpen can scan only these variants.
Note for the cipher it means substring (all cipher chains containing
the cipher are tried).
For example, you can use
cryptsetup tcryptDump --hash sha512 <container>
Note: for speed up, usually the hash option matters, cipher variants
are scanned very quickly.
Use witch care, in a script it can reveal some sensitive attribute
of the container.
Fixes#608.
Writing into allocated memory right before calling free can be optimized
away by smart compilers. To prevent this, a volatile access must be
performed. This happens already in crypt_safe_memzero.
It was difficult to provoke GCC to remove the assignment, but I was able
to find a way to prove the theory:
* Build cryptsetup with: CFLAGS="-flto -O3 -g" ./configure --enable-static
* Create main.c:
#include <libcryptsetup.h>
int
main(void) {
char *x = crypt_safe_alloc(64);
crypt_safe_free(x);
return 0;
}
* Build the program with: gcc -O3 -flto -static -o main main.c -lcryptsetup
* Disassemble: objdump -d main
My output on an amd64 system is:
0000000000401670 <main>:
401670: 41 54 push %r12
401672: bf f0 03 00 00 mov $0x3f0,%edi
401677: 55 push %rbp
401678: 48 83 ec 08 sub $0x8,%rsp
40167c: e8 ff 4d 01 00 callq 416480 <__libc_malloc>
401681: 48 85 c0 test %rax,%rax
401684: 74 2f je 4016b5 <main+0x45>
401686: 48 c7 00 e8 03 00 00 movq $0x3e8,(%rax)
40168d: 4c 8d 60 08 lea 0x8(%rax),%r12
401691: 48 89 c5 mov %rax,%rbp
401694: be e8 03 00 00 mov $0x3e8,%esi
401699: 4c 89 e7 mov %r12,%rdi
40169c: e8 4f 76 01 00 callq 418cf0 <explicit_bzero>
4016a1: 48 8b 75 00 mov 0x0(%rbp),%rsi
4016a5: 4c 89 e7 mov %r12,%rdi
4016a8: e8 43 76 01 00 callq 418cf0 <explicit_bzero>
4016ad: 48 89 ef mov %rbp,%rdi
4016b0: e8 3b 54 01 00 callq 416af0 <__free>
4016b5: 48 83 c4 08 add $0x8,%rsp
4016b9: 31 c0 xor %eax,%eax
4016bb: 5d pop %rbp
4016bc: 41 5c pop %r12
4016be: c3 retq
4016bf: 90 nop
You can see that the memory allocation and explicit_bzero calls were not
optimized away. But the size assignment disappeared.
Compiling without -O3 or without -flto does not inline the calls and
keeps the assignment. Also the shared library shipped with my
distribution has the assignment.
It makes more sense to return "real" key sizes, e.g. 256 bit for
AES-XTS 128 and 256/512 bit for AES-CBC with Elephant which has
a separate key for the Elephant mode.
* Rename "BASIC COMMANDS" to "BASIC ACTIONS"
* Changed a sentence saying that luksFormat would work on unmapped luks containers, only.
* Insert 6 examples of using cryptsetup for luks containers
There is a memory leak when PBKDF2_temp > UINT32_MAX. Here,
we change return to goto out to free key.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The value of h may be NULL. Check it vefore visiting its
memeber to avoid segfault.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The value of vk may be NULL in _keyslot_repair. It will
be dereferenced in LUKS_generate_phdr. Check it to avoid
segfault.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The return value of malloc vmk and params->fvek is not
checked. Here we add checking.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
Both BitLocker version 1 and NTFS have the same bootcode eb 52 90
so when trying to open an NTFS device user will get error message
saying that BitLocker version 1 is not supported. This patch
switches to check the superblock first to inform user that the
device is not a BITLK device.
We zero data parts of the test images to make them as small as
possible and for the latest startup key image I deleted bigger
portion of the NTFS header by accident which caused older blkid
on CentOS/RHEL 6 to not identify the NTFS filesystem on the
cleartext device.
We can't easily distinguish between a passphrase and other
protectors like recovery passphrase or startup key during
activation so we can't stop when attempted passphrase activation
fails because a binary startup key can't be conveted to UTF-16
during KDF.
More data about the new IOCTL is here:
https://lwn.net/Articles/818870/
We see 200-500ms boot speed improvement on our platform.
Prefer to define IOCTL when kernel is older version. Also eliminate
duplication since as a result of introduced ifdef.
Signed-off-by: Sinan Kaya <sinan.kaya@microsoft.com>
Right now, cryptsetup makes an attempt to include the correct
definitions in all of its header files, allowing the headers to
compile regardless of the context in which they are included.
A few files were missed, this change fixes them by adding the minimal
set of #includes needed to get them to compile.
Signed-off-by: Joe Richey <joerichey@google.com>
TrueCrypt/VeraCrypt supports backup header, it seems to have
the same format as normal header.
Let's use --header option here, it can be used to unlock data partition
with header backup (open and dump commands).
Fixes: #587.
User have to install gettext package or manually disable translation
using --disable-nls.
Also remove links to GNU packages ftp, all of these should by provided
by native distro packaging systems.
Fixes: #591.
cipher[31] and cipher_mode[31] buffers were passed to
crypt_parse_name_and_mode() routine where sscanf(s, "%31[^-]-%31s",
cipher, cipher_mode) was called.
In corner case it could cause terminating 0 byte written beyond
respective arrays.
Keep it simple. If there's not enough memory we can't validate
segments. The LUKS2 specification does not recommend to continue
processing LUKS2 metadata if it can not be properly validated.
In case LUKS2 backup segment creates gap in between last regular
segment and backup segment report invalid metadata imediately. We stop
on first error so there's no need to allocate large memory on heap
(we may ran with mlock(MCL_FUTURE) set).
Example:
- total segments count is 3
- regular segments have keys "0" and "1"
- first backup segment has key "42"
Segments are validated in hdr_validate_segments. Gaps in segment keys
are detected when collecting offsets. But if an invalid segment is very
large, larger than count, it could happen that cryptsetup is unable to
allocate enough memory, not giving a clue about what actually is the
problem.
Therefore check for gaps even if not enough memory is available. This
gives much more information with debug output enabled.
Obviously cryptsetup still fails if segments are perfectly fine but not
enough RAM available. But at that stage, the user knows that it's the
fault of the system, not of an invalid segment.
These performance options, introduced in kernel 5.9, configures
dm-crypt to bypass read or write workqueues and run encryption
synchronously.
Also support persistent storage of these flags for LUKS2.
Introducing new library supposed to be used in
cryptsetup tools and future cryptsetup loadable plugins
TODO:
- distribution
- cleanup header files
- incorporate also plugin API?
The issue can be reproduced very easily by starting 2 veritysetup processes
at the same time:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814021
device-mapper: create ioctl on img CRYPT-VERITY-cea03b7bc5b94e088e5754ff33be71d6-img failed: Device or resource busy
Verity device detected corruption after activation.
Command successful.
Command failed with code -1 (wrong or missing parameters).
Note how veritysetup open is reporting -EINVAL as the return code.
After the fix:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814649
Verity device detected corruption after activation.
Command successful.
Device img already exists.
Command failed with code -5 (device already exists or device is busy).
- crypt_token_register must not be called from withing crypt_token_load
(see later commits)
- minor bug in dlvsym/dlerror handling
- check for overflow in LUKS2_token_handler_type
Introducing new version of crypt_reencrypt symbol including
previously missing usrptr parameter. This change should be
backward compatible for existing libcryptsetup users
until next recompilation where it needs to be fixed.
If users want to use blake2b/blake2s, the kernel algorithm name
includes dash - like "blake2s-256".
Because we use dash as a separator, this patch adds an exception
for this case.
Fixes: #581.
TrueCrypt/VeraCrypt always use 512-bytes sector for encryption,
but for devices with a larger native sector it stores this value in header.
This patch allows activating of such devices, basically ignoring
the mentioned sector size in header (it only must be multiple
of 512-bytes sector).
Fixes: #580.
When creating LUKS2 header with specified --offset much larger
then LUKS2 header size we needlessly also wipe (allocate up to
--offset) much larger file than needed.
We've assumed that first 4 bytes of the decrypted key data is the
size of the key + metadata. Looks like this isn't true and only
first two bytes contain the size and the other two bytes are
unknown data, possibly related to reencryption and/or passphrase
change.
Fixes: #575
All POPT_ARG_STRING pointers must be free'd manually
in calling application. This is unfortunately not documented
well behaviour of popt and we were having memory leaks due to
it.
This is part of effort to eliminate all memory leaks related
to options parsing in popt but for that to work we must avoid
passing constant strings to free().
The EBOIV initialization vector is intended to be used
internally with BitLocker devices (for CBC mode).
It can be used in some specific cases for other devices.
This patch adds userspace implementation duplicating
the same EBOIV as the dm-crypt kernel.
Fixes: #562
The iv_large_sector option is supported in dm-crypt since introduction
of larger sectors encryption.
It counts Initialization Vector (IV) in larger sector size (if set) instead
of 512 bytes sectors.
This option does not have any performance or security impact, but it can be
used for accessing incompatible existing disk images from other systems.
(It is used internally in BitLocker compatibily code).
This patch allows it to be used for plain type device, so users
can manually map foreign disk images.
Only open action with plain device and sector size > 512 bytes is supported.
We need to use the iv_large_sectors flag and correct sector size
for the crypt segments for these devices. Used sector size is
read from the device header. This commit also adds two new test
images with 4k sectors.
Fixes: #557
Adds option to dump content of LUKS2 unbound keyslot
in to a file:
'cryptsetup luksDump --unbound --master-key-file /file -S 12 /dev/luks2'
or to terminal:
'cryptsetup luksDump --unbound -S 12 /dev/luks2'
Parameters -S (specific keyslot) is mandatory with --unbound.
Fixes: #549
* TRUE/FALSE are not defined anymore. 1 and 0 are used instead.
* json_object_get_uint64() and json_object_new_uint64() are part
of the upstream API now.
Kernel 5.7 adds support for optional discard/TRIM operation
for dm-integrity (available only for internal hash, not for LUKS2
with integrity).
This patch adds support for the new option.
We should not use O_DIRECT, it does not work tin in-memory fs.
Also never use O_EXCL on regular files, it is undedfined according
to open() documentation.
Fixes: #529.
Threre asre some situatiuoins when randomized image is nor repairable
by FEC data. Let's use completely deterministic image creation (fixed salt and uuid).
FIXME: The FEC Reed-Solomon code is doing something strange here, this
kind of erasure should be always repairable.
Previous fix for longer passhphrases increased maximal
passphrase length even if it was not needed, for example
if used with SHA256 hash in combination with keyfiles.
This patch tries to fix the problem, so some older volumes
can be opened again.
Also some test images are added for regression testing.
Fixes: #542.
There might be a trailing newline added by the text editor when
the recovery passphrase was passed using the '--key-file' option
so we'll remove it before trying to use the passphrase.
Some kernels show invalid dm-integrity table if suberblock
contains "recalculate" bit.
We can workaround that by setting recalculate option in table
(kernel uses bits from superblock anyway), so the table displayed
is always correct.
Fixes: #538
If crypto backend is missing support for hash algorithms used
in PBKDF2 during slot derivatiom the fail was not visible.
Print at least error message to user in this case.
Fixes: #536
LUKS2_hdr_validate() returns positive integer on error. Replace returned
value with negative errno instead so that failed upconversion stops
sooner. It failed anyway but debug messages were misleading.
If LUKS1 payload offset (data offset) is not aligned to
4KiB we create unaligned keyslots area in LUKS2 metadata
during upconversion. Unaligned keyslots area is not valid
from LUKS2 perspective. Fix it by properly aligning future
keyslots area and also check if LUKS1 keyslots area fit
in the new one.
Fixes: #534.
During LUKS2 upconversion we moved binary keyslots area before
validating future LUKS2 header. If later LUKS2 validation failed
for some reason keyslots were already moved to new offsets and
LUKS1 offsets were therefore invalid. Following effort to unlock
such device failed because keyslots were efectively corrupted.
See issue #534.
VeraCrypt now allows passwords of maximal length 128 bytes
(compared to legacy TrueCrypt where it was limited by 64 bytes).
This patch implements support for such a passphrases for TCRYPT format.
The whole extension seems to be quite dubious, the original TCRYPT
passphrase limit was IMO because of internal block length in PBKDF2
(SHA1/SH256 block size is 64 bytes), this patch make sense for SHA512
where the block size is 128 bytes.
Another strange thing is enlarging keyfile pool according to real
entered password size.
Fixes: #532.
With LUKS1 we returned pbkdf values even for inactive keyslot.
Only iterations count was wrong. Remaining values are not
specific keyslot bound with LUKS1.
Fixes: #528.
According to Dislocker, two unknown numbers in the FVE metadata
indicate "state" of the BITLK device. We were able to identify
only one of the states and we shouldn't allow activating devices
in other states for now.
FVE metadata header contains size of the header itself + size of
the metadata entries so we need to take this value and substract
48 (length of the FVE metadata header).
This patch adds CRYPT_VERITY_ROOT_HASH_SIGNATURE flag to verity info.
Veritysetup status now display "with signature" if an active
device was activated with root hash signature.
For this 128 bit Elephant the key data is 512 bit (2 * 156 bit,
same as for 256 bit Elephant) so we need to adjust reading the
key to not include the empty "parts" of the key.
Optional parameter root hash signature is added that can be added to
veritysetup.
The signature file is opened and the signature is added to the keyring.
The kernel will use the signature to validate the roothash.
Usage: veritysetup open <data_device> name <hash_device> <root_hash> --root-hash-signature=<roothash_p7_sig_file>
Signed-off-by: Jaskaran Khurana <jaskarankhurana@linux.microsoft.com>
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
[Original patch rewritten by Milan Broz]
Other APIs use the root hash in place of keys when using verity
devices, so do the same for crypt_volume_key_get to allow users
to retrieve the root hash of an active verity device.
Use it in veritysetup status to print the root hash.
[Patch slightly modified by Milan Broz]
When integritysetup formats a device with hash or HMAC integrity checksums,
it requires explicitly tag size entry from a user (or default value).
This leads to confusion and shortened tags.
This patch calculates tag size according to real hash output, and
if tag size is specified, it warns if these values differ.
Fixes: #492.
VMKs (keyslots) protected with a smart card or TPM have some
additional metadata entries that are currently unkwnon. We can
safely ignore these because we don't support unlocking the device
using these VMKs so we should still be able to parse the metadata
and unlock the device using other VMKs like the recovery password.
It's probably not possible to create a BitLocker device with an
empty passphrase but we want to support it. And it's definitely
better to ask for the passphrase again instead of returning
ENOMEM.
It's now possible to open/activate the device using passphrase or
recovery passphrase. Support is limited to devices using encryption
modes supported in the DM crypt module (AES-XTS and AES-CBC).
Original messages could evoke reencryption is currently
in progress. That was inaccurate because code only
detected flag marking such device is in transition state
from metadata pov. We should not imply anything about
running processes. That's detected via reencryption locks.
We missed keyslot json validation when unlocking all keys necessary
for reencryption. Also assign appropriate verified digest id to
keys in volume key structure.
In fact we need only stored key size in examined keyslot. It's valid for
default segment volume keys and in case of non-default segment
keys it always returns -1 and fallbacks to stored key size query
instead.
The dump operation prints the fix_padding flag if set.
Also try to print warning if an old kernel is used and th edevice
cannot be activated because of missing fix padding support.
This patch adds support for fixed padding to cryptsetup.
* Cryptsetup will accept superblocks version 4.
* If the dm-integrity target version is greater than 1.4, cryptsetup will
add a flag "fix_padding" to the dm-integrity target arguments.
There is still one quirk: if we have an old libdm without
DM_DEVICE_GET_TARGET_VERSION and if dm-integrity module is not loaded,
cryptsetup will not detect that it can use the "fix_padding" option.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
If user has volume key available, LUKS device can be resumed
directly using provided volume key.
No keyslot derivation is needed, only key digest is checked.
Fixes: #502.
The progress function remained silent unless the speed was higher
than minimal delta for double type in MiB/s. That could confuse
users that progress got stucked, but it in fact it was only slow.
Now wipe and reencryption progess functions can report speeds
in B/s up to GiB/s.
When resuming reencryption operation (both LUKS2 and legacy offline
code) speeds were incorectly calculated from whole progress including
range already reencrypted in previous runs. Now we track speed only
for currently running session.
It also fixes minor regression where we return backing file
for partition on top of loop device when prompting for passphrase.
Partition on loop has different major number so it should not be
considered loop device at all.
Currently hard memory limit is 1 GiB. Soft limit is
1/4 of system memory.
Note that --hotzone-size cryptsetup parameter can only further
lower hard and soft memory limit on hotzone size and not bypass
it.
It may be useful to activate device right after LUKS2 encryption
is initialized:
device is ready to use immediately even if data encryption runs in
the background for a long time
It simplifies encryption initialization during reboot.
The check for enough space before moving keyslots data did not expect real
detached header size to be less than aligned LUKS1 header size.
Also if detached header is placed in regular file we can grow so that
moved keyslots area fit the file.
Fixes#445.
This regression was introduced in cryptsetup 2.0.0 release
with refactoring "Enter passphrase for (dev)" prompt.
With cryptsetup 1.7.5, "cryptsetup open /dev/loop0" printed
following prompt:
"Enter passphrase for /path/to/loop/backing_file:"
Whereas cryptsetup 2.0.0 and on printed following one:
"Enter passphrase for /dev/loop:"
Reported in https://bugzilla.redhat.com/show_bug.cgi?id=1726287
Fixes: 39698fa6b7 ("Remove terminal input from libcryptsetup API calls.")
Fixes: c80acbe4c8 ("Add back "Passphrase for (dev):" prompt.")
Fixes: 5171f65c05 ("tests only: Return back password retry support for luksOpen.")
If device properly exposes optimal io size, let's align
reencryption hotzone to it. Otherwise device-mapper driver
complaints about misaligned tables and reencryption performance
is not optimal.
All set_segment funcions must use uin64_t everywhere,
not size_t that is platform dependent.
The code later uses it correctly, it is just wrong function
prototype definitions.
Reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935702
(TODO: add a test for other segment types.)
command "man cryptsetup reencrypt" gets redirected to
cryptsetup-reencrypt man page. This may confuse users that LUKS2 online
reencryption is managed by offline utility.
If all keyslots are removed, LUKS2 has no longer information about
the volume key size (there is only key digest present).
If user wants to open or add new keyslot, it must get information
about key size externally.
We do not want to guess key size from the file size (it does not
work for block devices for example), so require explicit --keyfil
option in these cases.
Fixes#470.
Commit 4c73da31 exposed another bug in minimal device size check.
During reencryption initialization wrong data offset value was used
and adjusted as if device was already undergoing reencryption. The
bug fixed by commit 4c73da31 hid this bug.
This is hotfix only and following functions needs more review:
- LUKS2_reencrypt_data_offset
- LUKS2_get_data_offset
- luks2_check_device_size
- LUKS2_get_data_size
- Remove all 'LUKS2_' name prefixes from internal routines
- Make all internal routines prefixed with 'reencrypt_' instead
- Drop few static routines by refactoring
- Rename all variables and routines containing 'pre' prefix to
contain 'hot' prefix instead (when referring to segments
undergoing reencryption)
- Rename all variables and routines containing 'after' prefix to
contain 'post' prefix instead
- Rename all routines prefixed with '_' to 'reencrypt_' instead
If we initialized encryption with data shift and only single
segment the resulting metadata were missing
CRYPT_REENCRYPT_MOVE_FIRST_SEGMENT flag and also segments json section was
invalid.
Since release 2.1.0 mode test for LUKS2 is skipped due to small test image.
Enforce smaller LUKS2 metadata via --offset to reenable the test.
Also detect failure for open action if format pass earlier.
Unless user explicitly asks for keyslots areas size
(either via --luks2-keyslots-size or --offset) reduce keyslots
size so that it fits in metadata device.
If we format LUKS2 device with parameters unsuitable
for current metadata device size we usually fail during header areas
wipe. It was not clear what the reason actually was.
- make error messages propagated to users more comprehensible
- drop some error messages completely
- replace many error messages with debug logs only
Fixes#458.
LUKS2 and other device types allow stacking of dm devices
underneath public top level device.
The new type identifies clearly those private devices in respective
device stack so that they can be easily removed while removing
top level public device.
Switch LUKS2 reencryption device stack to use SUBDEV type immmediately
for hotzone and overlay devices. Other devices will follow in later
releases.
keyslot_cipher member leaked after existing LUKS2 context reload.
crypt_keyslot_set_encryption may access freed memory if
crypt_keyslot_get_encryption was previously called with
CRYPT_ANY_SLOT parameter.
It's possible to retain all keyslots (passphrases) when
performing LUKS2 reencryption provided there's enough
space in LUKS2 json metadata.
When specific keyslot is selected all other keyslots
bound to old volume key get deleted after reencryption
is finished.
Existing tokens are assigned to new keyslots.
- test repair commad for reencryption recovery.
- test close command is able to teardown leftover device stack after
crash.
- test open performs recovery by default (to be able to open root
volume).
LUKS2 should use keyring for dm-crypt volume keys by default
when possible. crypt_activate_by_token didn't load keys in
keyring by default. It was a bug.
Currently it's used only in LUKS2 reencryption code
for reencrypting initial part of data device only.
It may be used to encrypt/reencrypt only initial part
of data device if user is aware that rest of the device
is empty.
It's useful to reencrypt only initial device part only.
For example with golden image reencryption it may be useful
to reencrypt only first X bytes of device because we know
the rest of device is empty.
We can't avoid this race due to undefined behaviour if called with
O_EXCL flag on regular file.
Let's double-check fd with O_EXCL flag is actually open block device.
Coverity Analysis 2019.03 incorrectly marks the input argument
of base64_encode(), and conseuqnetly base64_encode_alloc(), as
tainted_data_sink because it sees byte-level operations on the input.
This one-line annotation makes Coverity suppress the following false
positives:
Error: TAINTED_SCALAR:
lib/luks2/luks2_digest_pbkdf2.c:117: tainted_data_argument: Calling function "crypt_random_get" taints argument "salt".
lib/luks2/luks2_digest_pbkdf2.c:157: tainted_data: Passing tainted variable "salt" to a tainted sink.
Error: TAINTED_SCALAR:
lib/luks2/luks2_keyslot_luks2.c:445: tainted_data_argument: Calling function "crypt_random_get" taints argument "salt".
lib/luks2/luks2_keyslot_luks2.c:448: tainted_data: Passing tainted variable "salt" to a tainted sink.
This is very ugly workaround for situation when multiple
devices are being activated in parallel (systemd crypttab)
and system instead of returning ENOMEM use OOM killer
to randomly kill processes.
This flag is intended to be used only in very specific situations.
crypt_drop_keyring_key function allow to drop all keys in keyring
assocatiated with passed volume key list.
crypt_drop_keyring_key_by_description is used to drop independent key.
Wait for already running threads if a thread creation failed.
Use explicit_bzero() on recent glibc versions.
(Without fixed logic, we have already macro definition through automake.)
Fixes#444.
If passed key matches any existing digest we will not create
new digest but assign the keyslot to already existing one.
Because reencryption should be able to create more than one
keyslot assigned to new key digest.
TODO: Tests for the new feature
rename sector_start -> iv_start (it's now a iv shift for subsequent
en/decrypt operations)
rename count -> length. We accept length in bytes now and perform sanity
checks at the crypt_storage_init and crypt_storage_decrypt (or encrypt)
respectively.
rename sector -> offset. It's in bytes as well. Sanity checks inside
crypt_storage functions.
Atomic operation requires to hold a lock for longer period than
single metadata I/O. Update locks so that we can:
- lock a device more than once (lock ref counting)
- reaquire read lock on already held write lock (write lock
is stronger than read lock)
When information about original keyslot size is missing (no active
keyslot assigned to default segment) we have to fallback to
default luks2 encryption parameters even though we know default
segment cipher and mode.
Fixes: #442.
Also fix LUKS1 keyslot function to proper return -ENOENT errno in this case.
This change means, that user can distinguish between bad passphrase and
no keyslot available. (But this information was avalilable with luksDump
even before the change.)
This change will allocate space if underlying device is smaller file
and fail if it is block device.
Previously smaller device was quietly ignored, leading to keyslot
access failure with older dm-crypt mapped keyslot encryption
(disabled kernel user crypto API).
In most cases we do not need to create large files for new headers.
crypt_format already allocates enough space for all keyslots in files
during internal header wipe.
Fixes#410.
Cryptsetup/libcryptsetup currently supports several cryptographic
library backends.
The fully supported are libgcrypt, OpenSSL and kernel crypto API.
FIPS mode extensions are maintained only for libgcrypt and OpenSSL.
(Nettle and NSS are usable only for some subset of algorithms and
cannot provide full backward compatibility.)
For years, OpenSSL provided better performance for PBKDF.
Since this commit, cryptsetup uses OpenSSL as the default backend.
You can always switch to other backend by using a configure switch,
for libgcrypt (compatibility for older distributions) use:
--with-crypto_backend=gcrypt
For now, the hash was set to sha256 (except for converted LUKS1 header).
This patch adds the same logic as in LUKS1 - hash aglorithms is
loaded from PBKDF setting.
Fixes#396.
The gcrypt does not use standard pkgconfig detection and requires
specific macro (part of gcrypt development fileS) to be present
during autoconfigure.
With other crypto backend, like OpenSSL, this makes no sense,
so make this part of autoconfigure optional.
The JSON structures should not be printed by default to debug log.
This flag introduces new debug level that prints JSON structures
and keeps default debug output separate.
This patch makes available LUKS2 per-keyslot encryption settings to user.
In LUKS2, keyslot can use different encryption that data.
We can use new crypt_keyslot_get_encryption and crypt_keyslot_set_encryption
API calls to set/get this encryption.
For cryptsetup new --keyslot-cipher and --keyslot-key-size options are added.
The default keyslot encryption algorithm (if cannot be derived from data encryption)
is now available as configure options (default is aes-xts-plain64 with 512-bits key).
NOTE: default was increased from 256-bits.
Support for multi-segment devices is requirement for online
reencryption to work. Introducing modififed dm backend that
splits data structures describing active device and individual
dm target (or segment).
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.
If any argument is null return false (with higher
priority than trivial identity check).
Also device_path can't return null if device struct gets
allocated succesfully.
Also print these area sizes in dump command.
NOTE: since now, the metadata area size in dump command contains
mandatory 4k binary section (to be aligned with API definition).
The crypt_set_data_offset sets the data offset for LUKS and LUKS2 devices
to specified value in 512-byte sectors.
This value should replace alignment calculation in LUKS param structures.
Since the kernel 4.18 there is a possibility to speficy external
data device for dm-integrity that stores all integrity tags.
The new option --data-device in integritysetup uses this feature.
Linux kernel since version 4.18 supports automatic background
recalculation of integrity tags for dm-integrity.
This patch adds new integritysetup --integrity-recalculate options
that uses this option.
Due to previous fix it's no longer needed to add
all keyslot area lengths and check if result sum
is lower than keyslots_size.
(We already check lower limit, upper limit and
overlapping areas)
This commit fixes two problems:
a) Replace hardcoded 16KiB metadata variant as lower limit
for keyslot area offset with current value set in config
section (already validated).
b) Replace segment offset (if not zero) as upper limit for
keyslot area offset + size with value calculated as
2 * metadata size + keyslots_size as acquired from
config section (also already validated)
Swap config and keyslot areas validation code order.
Also split original keyslots_size validation code in
between config and keyslot areas routines for furhter
changes in the code later. This commit has no funtional
impact.
Keyslot areas were validated from each keyslot
validation routine and later one more time
in general header validation routine. The call
from header validation routine is good enough.
Test archive contains images with all supported
LUKS2 metadata size configurations. There's
one active keyslot 0 in every image that can be
unlocked with following passphrase (ignore
quotation marks): "Qx3qn46vq0v"
Test both primary and secondary header validation tests
with non-default LUKS2 json area size.
Check validation rejects config.keyslots_size with zero value.
Check validation rejects mismatching values for metadata size
set in binary header and in config json section.
Kernel prevents activation of device that is not aligned
to requested sector size.
Add early check to plain and LUKS2 formats to disallow
creation of such a device.
(Activation will fail in kernel later anyway.)
Fixes#390.
LUKS2 specification allows various size of LUKS2 metadata.
The single metadata instance is composed of LUKS2 binary header
(4096 bytes) and immediately following json area. The resulting
assembled metadata size have to be one of following values,
all in KiB:
16, 32, 64, 128, 256, 512, 1024, 2048 or 4096
We used to preset compat cipher and cipher_mode values during
crypt_format() or crypt_load(). Since we can change 'default segment'
dynamically during reencryption (encryption, decryption included) we
need to parse those values from default segment json encryption field
each time crypt_get_cipher() or crypt_get_cipher_mode() is called.
All previous version of cryptsetup wiped only first 4k for LUKS1
and both JSON areas for LUKS2 (first 32k) and the allocated
keyslot area (as it contained the generated key).
Remaining areas (unused keyslots, padding, and alignment) were
not wiped and could contain some previous data.
Since this commit, the whole area up to the data offset is zeroed,
and subsequently, all keyslots areas are wiped with random data.
Only exceptions are
- padding/alignment areas for detached header
if the data offset is set to 0
- bogus LUKS1 keyslot areas (upstream code never
created such keyslots but someone could use that).
This operation could slow down luksFormat on some devices, but
it guarantees that after this operation LUKS header does not
contain any foreign data.
Add support for Camellia and Kuznyechik ciphers and Streebog hash functions,
introduced in recent Veracrypt.
Note, that Kuznyechik requires out-of-tree kernel module and Streebog
hash function is available only with gcrypt backend.
crypt segment data offset has nothing to do with encryption sector
size. The device may hint alignment offset which is completely
unrelated and LUKS2 validation blocks it.
This reverts commit 71dd149ca2.
Enforcing data alignment to be encryption sector size aligned
is completelly wrong. The underlying data device alignment
has nothing to do with dm-crypt internal encryption sector size.
The restriction is however valid for dm-crypt segment size.
device_topology_alignment routine already returns alignment offset
in bytes. There's no need to divide it by sector size, since LUKS2
format have all offsets and sizes stored in bytes.
For some reason the volume key file have to exists.
Let's change the logic to the same as for luksBackupHeader
(a file is created and operation fails if it already exists).
crypt_wipe_device was called incorrectly on metadata device even
though integrity header is always on data device from cryptsetup
pov. During LUKS2 crypt_format with detached header scenario we
would wiped first 8 sectors of metadata device instead of data
device.
Currently, AC_ARG_[ENABLE|WITH] are used in multiple different ways.
This change makes all their uses the same by following the style of
the GNU manual:
- AC_ARG_ENABLE(foo) should only define $enable_foo
- Use the 2 argument form with a --enable_foo flag
- Use the 4 argument form with a --disable_foo flag
- Format all uses the same way
- Always compare using: test "x$enable_foo" = "xyes"
This makes the easier to debug, more readable, and shorter.
This formatting fix also revealed a bug (fix submitted seperately).
Bzip2 is sometimesmissing and we use xz already.
Seems xz produces slightly larger archives (despite the best mode)
but it is not worth to keep bz2 here.
When LUKS2 crypt_format() is called with detached header and custom data
alignment is requested, keyslots area is miscalculated. This mistake
is correctly detected by LUKS2 validation code but it's feature
regression with regard to LUKSv1 format.
Also rename all 'length' variable to 'size' since json
field is named size.
Make segment validation two step process. First
validate general segment object is valid and later
validate specific segment type has all necessary fields.
Without this patch older libraries won't be able to print out
(luksDump) basic information about devices created with newer
libraries.
If any segment has missing 'offset' field keyslots validation
routine could trigger segfault due to misuse of function that
expects valid 'segments' object.
Fix it by reordering validation routines.
Stdout is not printed in initrd unless user invokes debug mode.
It's inconvenient to have users waiting for reencryption to
finish with no input at all.
Move all messages to cryptsetup tools and print these
verbose messages:
- Key slot X unlocked.
- Key slot X created.
- Key slot X removed.
and
- Token X created.
- Token X removed.
Also print error, if unknown token is tried to be removed.
This patch has no functional impact. It only renames misleading
parameter 'keyfile_size_max' to 'key_size' because that's
how it's actually interpreted since beginning. Also updated
API documentation accordingly.
a) checks crypt_load() fails when single LUKS2 header is corrupted and
blkid detect other device signature from LUKS or none.
b) check explicit crypt_repair is able to override blkid restriction
and fix corrupted primary header
c) check a) and b) with disabled locks
Also moves FIXME comment lower to LUKS2 code with note that currently it's
safe to do crypt_repair on LUKS2 format without paying attention to LUKS2
requirements.
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.
--disable-dev-random now disables reading from /dev/random instead of
incorrectly enabling it. This was found by reviewing all of flags
in configure.ac.
We call crypt_random_init in init_crypto, but never call
crypt_random_exit. This change just copies what the crypt_backend
functions do, and calls crypt_random_exit in the descructor.
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).
Note: it is always better to use external libargon2 library.
Unfortunately, until Argon2 is in generic crypto libraries,
we must sometimes use bundled version just for bureaucratic reasons.
Let's include optimized variant of reference implementation as well.
Note, this code will not add any SSE compiler switches.
If --enable-internal-sse-argon2 option is used, it checks if current
compilation flags support simple SSE progam and if so, it use
the optimized variant.
(Not tested for AVX optimizations; it expects that SSE is enabled as well.)
Almost all the headers in cryptsetup are self-suffienct (in that they
compile on their own). By including <stddef.h>, <stdint.h>, or
<sys/types.h>, all headers will now compile on their own.
This is useful for importing cryptsetup into Bazel/Blaze.
As poptGetOptArg() returns "const char *", assigning it to a
"const char *" varible triggers a warning on Clang:
"incompatible-pointer-types-discards-qualifiers".
see unit test write_blockwise(length=2097153, bsize=4096), on x86
with original test file size=2097152.
The test is trying to write_blockwise 1 more byte than actual file
size.
Note that both functions perform seek operations aligned to sector
boundary if possible before returning.
Unaligned input offset gets aligned on first preceding sector
boundary.
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.
If removed subcondition was true --keep-key parameter (alone)
would fail the command. But it is valid to request reencryption
of LUKS header and applying defaults to pbkdf parameters.
The PBKDF2 benchmark heavily depends on exported volume key length,
so we either have to remeber benchmarked length or just run test always.
For other KDFs the dependence on generated key length is negligible,
so we can cache benchmark.
RIPEMD160 is not even allowed any more as an option when creating an
encrypted file container using VeraCrypt. when encryption the system
partition/drive, it is below SHA256 in the list of options.
the order is like that since VeraCrypt version 1.0f (2014-12-30,
see https://www.veracrypt.fr/en/Release%20Notes.html).
the user provided PIM value was not forwarded to the respective
implementation dumping the VeraCrypt header information.
extends the tcrypt-compat-test such that tcryptDump is performed
on VeraCrypt containers as well.
If last write in move area failed, the keyslot is in fact destroyed.
We need to at least ensure that the whole area is there
(so write fails only for hard errors).
- do not run general LUKS2 format validation from inside the specific one
- validate luks2 json object only
- temporary move digests count restrictions, going to be fixed in next
commit
This patch fixes several problems:
- pbkdf benchmark should be run with keyslot encryption key length
instead volume key length
- run LUKS2 keyslot validation on final keyslot json object instead
temporary stub created in keyslot_alloc
- replace whole json kdf object during keyslot update. We left behind
old parameters from old pbkdf during transition to differnt type
A keyslot not bound to any segment can store any key for any purpose.
To easily check slot status, new enum value is introduced.
This status is valid only for LUKS2, so the functions are backward compatible
with LUKS1.
An unbound keyslot is slot not assigned to a segment;
such a keyslot cannot be used to activate LUKS device, but
can be used for an arbitrary key store.
This patch adds --unboud option for luksAddKey cryptsetup command.
We can't wipe (overwrite with random noise) wrapped key in
kernel. Such keys are usually structured and not only random
bytes.
Also it doesn't make sense to wipe these keys. They are supposed
to be protected (encrypted) by keys sealed in hardware.
TODO: tests: 1) with header, 2) without header (dm-crypt only),
3) arch with working paes cipher (at least).
Some ciphers and key sizes created on-disk metadata that cannot be used.
Use the same test for length-preserving cipher as LUKS1.
Also check if key for integrity algorithm is not too small.
Fixes#373.
In commits 9bcc97bc5e and
5536b3a58d new features were
added, which used bash-specific features in a POSIX sh script. This
caused configure to completely fail with syntax errors on systems where
/bin/sh was not symlinked to GNU bash.
`==` is a bash-specific alias for `=` and should never, ever, ever be
used since it offers no additional utility for bash but merely serves
to confuse people writing POSIX.
substring parameter expansion, e.g. `${with_tmpfilesdir:0:1}` is not
POSIX but can be trivially replaced by case wildcards.
The kernel 4.17 will include a new dm-verity flag that
instructs kernel to verify data blocks only once.
This patch adds support for it to libcryptsetup and veritysetup.
This flag can be dangerous; if you can control underlying device
(you can change its content after it was verified) it will no longer
prevent reading tampered data and also it does not prevent to silent
data corrruptions that appears after the block was once read.
It there is an input on stdin (pipe), we cannot retry for password,
a retry applies only for the real terminal.
Also the retry lost EPERM (wrong passphrase) return code in this case,
replacing it with tty read error.
Fixes#321.
This patch allows encryption/decryption of the whole device,
IOW add encryption later with detached header.
This operation can be dangerous, there is no fixed bindings between
the specific LUKS header and data device (encrypted data device
contains no magic signatures).
Allow symbolic links in the initial part of locking path.
If /run/x/y/crypsetup is locking path, starting with
'run' anything may be symbolic link up to (including) 'y'.
cpu --perf-* options do not trigger error when
not supported by current kernel.
Also be more carefull about --sector-size when not supported by
dm-crypt. Test is made more pedantic now.
With --persistent option, write only flags actually
used during activation. In other words we will not
store anymore flags not supported by running kernel.
various bugfixes:
- erase flags variable if no flags are stored
- do not print false debug warning
- during activation do not overwrite activation flags
with persistent flags
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).
Kernel could reject HMAC without a key during format, we must set a key here as well.
Because there is no data area (device size is 8 sectors), it is actually never used,
so we can use zeroed key here.
The real HMAC key is used later during device activation with the real size.
- add --pbkdf* option descriptions
- few clarifications wrt LUKS2 format
- alter note about limited support for LUKS2. It's 1:1
with LUKS1 format currently, but tokens are not yet
transfered to new LUKS2 header for reencrypted device.
- few minor corrections
The code must not set global table with KDF variants but
it shuld calculate local iterations count.
Also PIM is not used for old Trucrypt modes, do not use it there.
Also fix leak of PIM iteration count to debug log.
Fixes issue #366 and issue #367.
Recent kernel changes disallows to use keyed-hash algorithms
without settting the key.
Unfortunately, dm-integrity fails too late (during IO, not on init).
For now fix just the test.
- adapt tests to new features (luks2 keyslot change, pbkdf params)
- add tests for fixes (max keyslot)
- speed up tests significantly by add minimal forced values everywhere.
The change in keyfile processing caused that special loopAES
keyfiles are no longer read from stdin if key-file argument is "-".
Fix it by using /dev/stdin in cryptsetup if "-" is detected.
(The libcryptsetup API no longer parses spacial meaning of "-" internally).
Fixes#364.
This fixes crypt_keyslot_add_by_key where we were unable to store
keyslot (unbound to segment) with different key_size.
The code used (new) volume key size implicitly which could be wrong
if new size was not compatible with cipher parameter for keyslot area.
Add yet another flawed dm-crypt test (keyring)
and test crypt_get_volume_key_size works
as expected after LUKS2 crypt_format (before
adding first keyslot).
For now, crypto API quietly used cipher witout IV if a cipher
algorithm wihtou IV specificaton was used (e.g. aes-xts).
This caused fail later during activation.
This patch allows only two specific backed use without specified IV
(ECB mode and NULL cipher).
Also check cipher string early during parsing of CLI options.
cryptsetup now requires dm-crypt v1.18.1 or higher
to use kernel keyring service for passing VKs.
Also, relevant API functions fail if CRYPT_ACTIVATE_KEYRING_KEY
is set, but library is not allowed to use kernel keyring for
VK.
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).
Upstream dm-crypt v1.15.0 through v1.18.0 contains
serious bug in kernel key processing that may cause
data corruption for ciphers using essiv, tcw and lmk IVs.
Patch adds patch number processing to DM version checks.
The keyfile interface was designed, well, for keyfiles.
Unfortunately, a keyfile can be placed on a device and the size_t offset
can overflow.
We have to introduce new set of fucntions that allows 64bit offsets even on 32bit systems:
- crypt_resume_by_keyfile_device_offset
- crypt_keyslot_add_by_keyfile_device_offset
- crypt_activate_by_keyfile_device_offset
- crypt_keyfile_device_read
The new functions have added _device_ in name.
Old functions are just internall wrappers around these.
Also cryptsetup --keyfile-offset and --new-keyfile-offset must now
process 64bit offsets.
For more info see issue 359.
There are problems with sharing /run/lock with lockdev and also in early boot
we cannot create the whole subir chain.
It is safe to switch to separate locking dir.
This can be changed with --with-luks2-lock-path and --with-luks2-lock-dir-perms
configure switches.
See Issue#361 and issue#362.
Reduce bloated code in low level keyring utilities code.
Move log messages higher the library code.
Also return -ENOTSUP when code was compiled out by configure
option.
Remove code for handling multiple digests per single keyslot.
Same would apply to segments with the only exception of segment
in-reencryption. We need that exception so that we will not lose
old key digests too early.
with json-c until 0.12.x json_object_array_length returned signed
integer. json-c 0.13.x and later changed return type to unsigned
size_t.
Consider return values less or equal to zero as empty array, otherwise
array is non-empty.
Originally the key description for VK was derived
from segment id. This could lead to ambiguity when
keyslot key is verified and loaded in kernel keyring
using activation functions with CRYPT_ACTIVATE_KEYRING_KEY
flag raised.
PBKDF2 has nasty behaviour that it generates the same output
for passwords that has several trailing zero bytes.
(IOW null trailing bytes causes collision.)
Unfortunatelly our test plays with password length
and expect wrong length must always fail.
Sometimes the randomly generated key key contains
the null byte in the "wrong" place and PBKDF2 causes test to fail.
For now, fix it by using fixed keyfile without null bytes
(similar to fixed passphrased we already have).
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.
For some strange filesystems (nfs) we get big block size (1MB).
For temporary keyslot devices this mapping does not make sense and
can cause problem with detached headers that are smaller (contains
exactly the slot size).
add --with-tmpfilesdir configuration option. Use the option
either to override default systemd tmpfiles.d directory location
or to specify install location for systems without systemd.
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
This patch duplicates part of the code because following
switch to non-recursive automake is not easily fixable without this change.
(Automake cannot use top_srcdir anymore in this context.)
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.
Code is written by Ondrej Kozina.
This patch adds ability to store volume key in kernel keyring
(feature available in recent kernels) and avoid setting
key through dm-ioctl and avoiding key in table mapping.
Will be used in LUKS2.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Code based on patch by Ondrej Mosnacek
The new benchmark works as follows:
Phase 1:
It searches for smallest parameters, such that the duration is 250 ms
(this part is quite fast).
Then it uses that data point to estimate the paramters that will have
the desired duration (and fulfill the basic constraints).
Phase 2:
The candidate parameters are then measured and if their duration falls
within +-5% of the target duration, they are accepted.
Otherwise, new candidate parameters are estimated based on the last
measurement and phase 2 is repeated.
When measuring the duration for given parameters, the measurement
is repeated 3 or 4 times and a minimum of the measured durations
is used as the final duration (to reduce variance in measurements).
A minimum is taken instead of mean, because the measurements definitely
have a certain lower bound, but no upper bound (therefore mean value
would tend to be higher than the value with highest probability density).
The actual "most likely" duration is going to be somewhere just above
the minimum measurable value, so minimum over the observations is
a better estimate than mean.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
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>
The Argon2i/id is a password hashing function that
won Password Hashing Competiton.
It will be (optionally) used in LUKS2 for passworrd-based
key derivation.
We have to bundle code for now (similar PBKDF2 years ago)
because there is yet no usable implementation in common
crypto libraries.
(Once there is native implementation, cryptsetup
will switch to the crypto library version.)
For now, we use reference (not optimized but portable) implementation.
This patch contains bundled Argon2 algorithm library copied from
https://github.com/P-H-C/phc-winner-argon2
For more info see Password Hashing Competition site:
https://password-hashing.net/
and draft of RFC document
https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/
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.
This error code means invalid value, no point in repeating the whole sequence.
(If there is a situation that requires repeat, it should not return EINVAL.)
Initially cryptsetup expected underlying device that was, by definition,
always aligned to a sector size (and length was always multiple of sectors).
For the images in file, we can now access the image directly.
Expecting that the image is always aligned to the whole block is now false
(the last block in file image can be incomplete).
Moreover, we cannot easily detect underlying block device sector (block) size
(the storage stack can be complex with various RAID and loop block sizes),
so code uses systyem PAGE_SIZE in this situation (should be the safest way).
Unfortunately, PAGE_SIZE can be bigger (1MB) than device sector (4k) and
the blockwise functions then fails because the image in file is not
aligned to PAGE_SIZE multiple..
Fix it by checking that read/write for the last part of an image is
the exact requested size and not a full block.
(The problem is for example for an unaligned hidden Truecrypt header
on PPC64LE systems, where page size is 64k.)
With big page size and image in file this can actually happen.
The command works in this situation but the code will be quite
ineffective (due to blockwise handling).
This call is required for deferred removal of device.
Morever, if the system reports that udev is running, we should not
try to "fix" problems by creating or removing nodes directly through libdevmapper.
(Non-udev case should still work.)
this patches improves two areas:
1) it checks for keyslot areas overlaping each other
2) it checks if all keyslot areas fit in header area of device
(pre-data-offset area) or if it can fit file (detached header)
it's being loaded from. Those new checks are based on real data
found in header (offsets) rather than based on assumption calculated
from key length
Because there are already 3 targets used, the current detection
based only on dm-crypt is not sufficient.
Add new definition of dm_flags that allows separate target version detect.
Note: we do not want to load targets explicitly; instead, we repeats
detection after operation that could trigger target load.
If dm_flags() call fails, then the target is not yet loaded.
The dm-integrity target is intended to be used for authenticated
encryption through LUKS and dm-crypt.
It can be used in standalone as well; for this use case there
is a simple configuration utility called integritysetup
(similar to veritysetup to dm-verity).
It is possible to trigger a double free with an invalid verity
partition. All it takes is an unknown hash algorithm, which makes it
a bit more likely than a completely broken partition header. But all
it takes is an error return value of VERITY_read_sb() or strdup().
If crypt_load fails before setting cd->type, crypt_free will handle
the union as if it was of type "none", which means it will call free()
for "active_name", a field which is only properly set up when the
type was actually "none".
In all other cases, "active_name" contains the first 4 or 8 bytes of
the actually used header structure. Fortunately it can be only a
pointer or NULL, so an attacker has no direct control of the value.
Nonetheless it can easily trigger a double free.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Somehow testing in qemu resulted sometimes in an endless loop.
Either the timing or the settle fixed the issue.
When the VM was in an endless loop, an strace showed, that the first 512
and 1024 of the crypt partition was read over and over. Either it was
the udev blkid, or some device mapper udev rule.
Maybe the reencrypt tool opens and closes the device fd, where the close
triggers a udev blkid and causes the reencrypt tool to reread the device...
Anyhow.. with this settle the issue was not seen anymore.
This patch adds a udev rule, so that you can specify
rd.luks.reencrypt=<UUID> instead of rd.luks.reencrypt=<devname>
It also moves the job to the "settled" queue, which means, that it is
executed after udev has settled.
A finished hook prevents dracut-initqueue from exiting and lets it
finish the batched jobs. Without a "finished hook" and without
"root=<dev>" on the kernel command line, the reencrypt job would not be
executed.
Normally you want to reencrypt without a "root=<dev>" on the kernel
command and want to reboot after the reencrypt job is done.
This patch adds the missing "finished hook".
On native 4k-sector device the old hidden header is not aligned
with hw sector size and derect-io access with SEEK_END fails.
Let's extend blockwise functions to support a negative offset
and use the same logic as normal unaligned writes.
Fixes problem mentioned in
https://gitlab.com/cryptsetup/cryptsetup/merge_requests/18
This patch adds the --veracrypt-pim=INT and --veracrypt-query-pim command-
line parameters to support specification of or being queried for a custom
Personal Iteration Multiplier respectively. This affects the number of
iterations for key derivation from the entered password. The manpage is
also updated accordingly.
Fixes Issue #307.
If backward-compatible API is not defined (-DOPENSSL_API_COMPAT=0x10100000L)
deprecated symbols cannot be used.
Also see https://bugs.gentoo.org/show_bug.cgi?id=604698
Thanks eroen for reporting this.
The lseek in function write_blockwise() could return value
that is greater than integer for result so it can overflow
and fail the whole write.
[comment added by mbroz]
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.
The function uuid_or_device is prone to a buffer overflow if a very long
spec has been defined. The range check happens against PATH_MAX, with
i being set to 5 (due to "UUID=" offset of spec), but "/dev/disk/by-uuid"
has been already written into device.
The difference between "/dev/disk/by-uuid" and "UUID=" is 13, therefore
the correct range check must happen against PATH_MAX - 13.
@@ -204,7 +204,7 @@ const char *uuid_or_device(const char *spec)
strcpy(device, "/dev/disk/by-uuid/");
If measurement function returns exactly 500 ms, the iteration
calculation loop doubles iteration count but instead of repeating
measurement it uses this value directly.
Thanks to Ondrej Mosnacek for bug report.
alter all checks for devfd value after device_open to
less than zero insted of equals to -1. device_open will
return values different from -1 in case error happens.
In LUKSv1 device_open should always return -1 in case of
error but this check is safer.
The rest is just formating improvement.
fix double close() cases in LUKS_hdr_backup() and LUKS_hdr_restore()
functions. It should be harmless unless libcryptsetup is used
in multi-thread setup which is not supported anyway.
This patch adds veritysetup support for these Linux kernel dm-verity options:
--ignore-corruption - dm-verity just logs detected corruption
--restart-on-corruption - dm-verity restarts the kernel if corruption is detected
If the options above are not specified, default behaviour for dm-verity remains.
Default is that I/O operation fails with I/O error if corrupted block is detected.
--ignore-zero-blocks - Instructs dm-verity to not verify blocks that are expected
to contain zeroes and always return zeroes directly instead.
NOTE that these options could have serious security or functional impacts,
do not use them without assessing the risks!
- moddir is assigned in parent script run by dracut (warning was
silenced)
- fix defect wrt to assignement and making variable local on
same line. The variable cwd was first assigned by subshell
and later any error originating in subshell was masked by
making the variable local (which returns always 'true')
- ensure that strings are \0 terminated (most of this is already
handled on higher level anyway)
- fix resource leak in error path in tcrypt.c
- fix time of check/time of use race in sysfs path processing
- insruct Coverity scanner to ignore constant expression in random.c
(it is intented to stop compile-time misconfiguration of RNG that would be fatal)
Allow keyfiles up to DEFAULT_KEYFILE_SIZE_MAXKB * 1024 bytes in size, and not that value minus one.
Signed-off-by: Vittorio Gambaletta <git-cryptsetup@vittgam.net>
to enable resume of interrupted decryption user has
to pass uuid of the former luks device. That uuid is used
to resume the operation if temporary files LUKS-* still
exist.
This patch is for issue #287
In the code for returning block size ( device_block_size_fd in lib/utils_device.c ),
always returns zero in case of files and device_read_test is not executed.
This patch is to fix device_block_size_fd to return block size correctly incase of files.
Signed-off-by: Athira Rajeevatrajeev@linux.vnet.ibm.com
There're various situations where hdr backups together with log file
may get removed even when the hdr was already marked unusable. This
patch fixes the most sever case already reported and generaly tries
harder protecting the log file and both hdr backups.
udev cookies should be set right in before the dm_task_run()
call otherwise we risk a hang while waiting for a cookie
associated with not yet executed dm task.
For example: failing to add table line (dm_task_add_target())
results in such hang.
This can happen if write buffer size is smaller than underlying
block size and initial buffer is misaligned.
Also use size_t for buffer length variables.
Batch mode should enable no-query keyslot wipe but only if user
did not provided password or keyfile explicitely.
Fixes issue #265.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
For basic information about the cryptsetup project, please read [README](README.md).
The Cryptsetup project uses free, open-source licenses; details are described in [licensing](README.licensing).
For contribution code or documentation to the cryptsetup project, you must have the necessary rights to the content, and your contribution must be provided under the required license.
We welcome contributions from everyone.
Cryptsetup is an independent project with much volunteer effort, and our resources are limited.
Following the guidelines specified in this file makes it easier for us to process your issue.
Project maintainers can remove or reject abusive or otherwise unacceptable comments or code.
Git repository
--------------
The primary repository is located at [gitlab.com/cryptsetup/cryptsetup](https://gitlab.com/cryptsetup/cryptsetup).
The development branch is ``main``; minor stable releases can use their branches with cherry-picked or backported patches.
There are backup mirrors located at [github.com/mbroz/cryptsetup](https://github.com/mbroz/cryptsetup) and [git.kernel.org/pub/scm/utils/cryptsetup/cryptsetup.git](https://git.kernel.org/pub/scm/utils/cryptsetup/cryptsetup.git).
How to make a bug report
------------------------
To report an issue or feature request, please use GitLab [cryptsetup issue tracker](https://gitlab.com/cryptsetup/cryptsetup/-/issues).
Before reporting an issue, please try to search documentation and existing issues. Always try to reproduce the problem on the latest supported release.
Please *always* collect and attach ``--debug`` log and other information as instructed in the issue template.
Even if you think the problem is obvious, we need logged information about the environment (like versions of kernel modules, etc.).
Please do not report distribution-specific issues if they are not present in the latest upstream release.
For such reports, please use downstream distribution-specific trackers.
If the issue is related to upstream, downstream maintainers will redirect you here, or upstream maintainers will join the discussion.
If you think that you found some security bug, please follow the instructions in the [SECURITY](SECURITY.md) file.
How to contribute changes to cryptsetup
---------------------------------------
The following notes are a very short introduction to cryptsetup internal processes and an overview of generic rules that should be followed for all changes.
Changes from developers and external contributors should go through the GitLab repository [merge reguests](https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests).
Alternatively (for trivial changes), you can send a patch to [cryptsetup mailing list](mailto:cryptsetup@lists.linux.dev).
Please do not write personal emails with questions or patches to maintainers and developers.
### Project structure
Cryptsetup projects include a libcryptsetup library, tools, token plugins, documentation, and a test suite.
The cryptsetup tools and library use low-level functions that depend on many other subsystems.
Currently, the project is supported only for Linux (it will not work on Android or other systems).
Cryptsetup project requires some parts of the Linux kernel, notably the *Device Mapper* (dm-crypt, dm-integrity, dm-verity, dm-zero modules) and kernel *userspace cryptographic interface*.
Missing kernel interface can significantly limit (or even disallow) cryptsetup functionality.
Integration in operating systems also depends on several other projects, most notably *systemd* (that implements its own tooling using libcryptsetup) and *util-Linux* (*blkid* parsing of supported format metadata). Some changes must be synchronized in all needed places (kernel, blkid, libcryptsetup).
Several other projects implement their own token metadata (either through binary token plugins or through generic libcryptsetup JSON token access functions).
### Used cryptography algorithms
Cryptsetup avoids implementing cryptographic primitives but uses cryptographic libraries.
Exceptions were PBKDF internal implementations - PBKDF2 and Argon2 until these were integrated into major cryptographic libraries.
Cryptsetup can be compiled with several cryptographic libraries backend (OpenSSL, libgcrypt, Nettle, NSS, and Linux kernel userspace API).
OpenSSL is the default and strongly recommended configuration.
If the cryptographic library does not implement some cryptographic primitive (for example, if running in a FIPS-140 environment or just
because it does not include it at all), functionality could be limited.
### Configuration and versioning
Cryptsetup can be configured using *Autoconf* or *Meson*. Autoconf support is being deprecated in the long term.
Currently, all new configuration options must be implemented in both systems.
Cryptsetup intentionally does not use a system configuration file (located in /etc).
All functionality must be determined dynamically.
All related /etc configuration files (crypttab, fstab and others) are maintained by systemd (in some legacy distributions by cryptsetup downstream).
Major and minor releases are always based on the main git branch; the minor stable (patch) versions can have some specific branch with backported or cherry-picked patches (from the main branch).
Usually, minor releases happen twice per year and stable patch updates according to reported bugs (in 1-3 month intervals).
### Compilation and debugging
The library and tools are written in C language; we require C99 and support gcc and Clang compilers.
Manual pages are generated from AsciiDoc sources and libcryptsetup API documentation by Doxygen (from libcryptsetup.h comments).
Testsuite is a combination of local C utilities, fuzzing implementation in C++, bash scripts, and uses many other system utilities.
All tools contain compiled-in debug messages that are available through --debug options.
With Autoconf and libtool, you can run the cryptsetup tool in the debugger without installation using this one-line script:
This will ensure that a properly compiled libcryptsetup file is used.
### Coding style
Cryptsetup uses [Linux kernel coding style](https://cdn.kernel.org/doc/html/latest/process/coding-style.html) for libcryptsetup and tools (where applicable) with some additional notes:
- Use tabulators for indentation; the line should not exceed 100 characters with an 8-character tabulator. Otherwise, use a tab of any length. :-).
- The minimal C standard required is C99.
- The ``goto`` use is allowed only for error path (``goto out`` for common code path, ``goto err`` for specific error code path).
- Split patches per change; do not submit huge patches combining several changes.
- Use an elaborative description in the patch header.
- No need to use sign-off-by lines.
- Use name prefixes (``crypt_``, ``LUKS2_`` and similar).
- Avoid extensive preprocessor use (specifically conditional ``#if`` or ``#ifdef`` sections).
- To check detected configuration options stored in config.h, always use ``#if SOMETHING`` (do NOT use ``#ifdef``).
- Use output only through ``log_err, log_std, log_verbose, log_dbg`` macros.
The ``log_dbg`` is always in English; the others should be wrapped in the ``_()`` macro for translation.
- Use ``assert()`` but only for simple invariants and variables (avoid calling functions).
Do not use assert for user-defined input (this should be a normal error path).
- The code style is quite relaxed in testing scripts (code there is not intended for production use).
### General rules and testing
- Cryptsetup should work on all architectures supported by the Linux kernel.
Only very few functionalities require specific hardware (notably Opal SED support).
If you want to introduce some specific hardware support, please discuss it with the maintainers first.
- All code changes should go through merge requests and reviews.
Code can be merged after review approval (done by someone with the commit right to the development repository), but reviews from external people are very welcome, too.
- All new functionality must come with at least rudimentary coverage in the test suite.
Always run the test suite before opening the merge request (``make check`` with root privilege).
- We have continuous integration (CI) that runs many tests automatically, but the output is not directly visible for external merge request authors (for security reasons).
All CI scripts are available in .gitlab and .github folders in the project repository.
Maintainers will provide you log files if anything fails. Your code must produce no warnings before it is merged.
- We run compilation with many extended [gcc](.gitlab/ci/gcc-Wall) and [Clang](.gitlab/ci/clang-Wall) warnings and include some analyzers, notably
- [Coverity](https://scan.coverity.com), GitHub CodeQL, Clang scan-build, and gcc static analyzer, and
- fuzzing integrated in [OSS-fuzz project](https://github.com/google/oss-fuzz/tree/master/projects/cryptsetup).
- Testsuite can also partially run under Valgrind dynamic analyzer with ``make valgrind-check``.
dnl Link with blkid to check for other device types
AC_ARG_ENABLE([blkid],
AS_HELP_STRING([--disable-blkid], [disable use of blkid for device signature detection and wiping]),
[], [enable_blkid=yes])
if test "x$enable_blkid" = "xyes"; then
PKG_CHECK_MODULES([BLKID], [blkid],[AC_DEFINE([HAVE_BLKID], 1, [Define to 1 to use blkid for detection of disk signatures.])],[LIBBLKID_LIBS="-lblkid"])
AC_CHECK_HEADERS(blkid/blkid.h,,[AC_MSG_ERROR([You need blkid development library installed.])])
AC_CHECK_DECL([blkid_do_wipe],
[ AC_DEFINE([HAVE_BLKID_WIPE], 1, [Define to 1 to use blkid_do_wipe.])
enable_blkid_wipe=yes
],,
[#include <blkid/blkid.h>])
AC_CHECK_DECL([blkid_probe_step_back],
[ AC_DEFINE([HAVE_BLKID_STEP_BACK], 1, [Define to 1 to use blkid_probe_step_back.])
enable_blkid_step_back=yes
],,
[#include <blkid/blkid.h>])
AC_CHECK_DECLS([ blkid_reset_probe,
blkid_probe_set_device,
blkid_probe_filter_superblocks_type,
blkid_do_safeprobe,
blkid_do_probe,
blkid_probe_lookup_value
],,
[AC_MSG_ERROR([Can not compile with blkid support, disable it by --disable-blkid.])],
[#include <blkid/blkid.h>])
fi
AM_CONDITIONAL(HAVE_BLKID, test "x$enable_blkid" = "xyes")
AM_CONDITIONAL(HAVE_BLKID_WIPE, test "x$enable_blkid_wipe" = "xyes")
AM_CONDITIONAL(HAVE_BLKID_STEP_BACK, test "x$enable_blkid_step_back" = "xyes")
AC_ARG_ENABLE([hw-opal],
AS_HELP_STRING([--disable-hw-opal], [disable use of hardware-backed OPAL for device encryption]),
[],
[enable_hw_opal=yes])
if test "x$enable_hw_opal" = "xyes"; then
have_opal=yes
AC_CHECK_DECLS([ OPAL_FL_SUM_SUPPORTED,
IOC_OPAL_GET_LR_STATUS,
IOC_OPAL_GET_GEOMETRY
],
[],
[have_opal=no],
[#include <linux/sed-opal.h>])
if test "x$have_opal" = "xyes"; then
AC_DEFINE([HAVE_HW_OPAL], 1, [Define to 1 to enable OPAL support.])
else
AC_MSG_WARN([Can not compile with OPAL support, kernel headers are too old, requires v6.4.])
fi
fi
dnl Magic for cryptsetup.static build.
if test x$enable_static_cryptsetup = xyes; then
if test "x$enable_static_cryptsetup" = "xyes"; then
saved_PKG_CONFIG=$PKG_CONFIG
PKG_CONFIG="$PKG_CONFIG --static"
@@ -347,7 +644,7 @@ if test x$enable_static_cryptsetup = xyes; then
* Fix possible keyslot area size overflow during conversion to LUKS2.
If keyslots are not sorted according to binary area offset, the area
size calculation was wrong and could overflow.
* Hardening and fixes to LUKS2 validation functions:
* Log a visible error if convert fails due to validation check.
* Check for interval (keyslot and segment area) overflow.
* Check cipher availability before LUKS conversion to LUKS2.
Some historic incompatibilities are ignored for LUKS1 but do not
work for LUKS2.
* Add empty string check to LUKS2 metadata JSON validation.
Most of the LUKS2 fields cannot be empty.
* Fix JSON objects validation to check JSON object type properly.
* TCRYPT: Properly apply retry count and continue if some PBKDF variant
is unavailable.
* BITLK: Add a warning when activating a device with the wrong size
stored in metadata.
* BITLK: Add BitLocker volume size to dump command.
* BITLK: Fix possible UTF16 buffer overflow in volume key dump.
* BITLK: Skip question if the batch mode is set for volume key dump.
* BITLK: Check dm-zero availability in the kernel.
Bitlocker compatible mode uses dm-zero to mask metadata area.
The device cannot be activated if dm-zero is not available.
* Fix error message for LUKS2-only cryptsetup commands to explicitly
state LUKS2 version is required.
* Fix error message for incompatible dm-integrity metadata.
If the integritysetup tool is too old, kernel dm-integrity may use
a more recent version of dm-integrity metadata.
* Properly deactivate the integrity device even if the LUKS2 header
is no longer available.
If LUKS2 is used with integrity protection, there is always
a dm-integrity device underneath that must be deactivated.
* Allow use of --header option for cryptsetup close.
This can be used to check that the activated device has the same UUID.
* Fix activation of LUKS2 device with integrity and detached header.
The kernel-parsed dm-integrity superblock is always located on the
data device, the incorrectly used detached header device here.
* Add ZEROOUT IOCTL support for crypt_wipe API call.
For block devices, we can use optimized in-kernel BLKZEROOUT ioctl.
* VERITY: set loopback sector size according to dm-verity block sizes.
Verity block size has the same limits, so we can optimize the loop
device to increase performance.
* Other Documentation and man page improvements:
* Update LUKS2 on-disk format description.
* Add per-keyslot LUKS2 options to the man page.
Some options were missing for LUKS2 luksAddKey and luksChangeKey.
* Fix cryptsetup manpage to use PBKDF consistently.
* Add compile info to README. This information was lost when we removed
the default automake INSTALL file.
* Use volume key consistently in FAQ and man pages.
* Use markdown version of FAQ directly for installation.
* Clarify graceful reencryption interruption.
Currently, it can be interrupted by both SIGINT and SIGTERM signals.
* Add new mailing list info.
* Mention non-cryptographic xxhash64 hash for integrity protection.
* veritysetup: dump device sizes.
Calculating device sizes for verity devices is a little bit tricky.
Data, hash, and FEC can share devices or be separate devices.
Now dump command prints used device sizes, but it requires that
the user specifies all values that are not stored in superblock
(like FEC device and FEC roots).
* Fix check for argp_usage in configure if argp-standalone lib is used.
* Add constant time memcmp and hexa print implementation and use it for
cryptographic keys handling.
* Display progress when wiping the end of the resized device.
* LUKS2 token: prefer token PIN query before passphrase in some cases.
When a user provides --token-type or specific --token-id, a token PIN
query is preferred to a passphrase query.
* LUKS2 token: allow tokens to be replaced with --token-replace option
for cryptsetup token command.
* LUKS2 token: do not continue operation when interrupted in PIN prompt.
* Add --progress-json parameter to utilities.
Progress data can now be printed out in JSON format suitable for
machine processing.
* Embedded Argon2 PBKDF: optimize and simplify thread exit.
* Avoid using SHA1 in tests and fix new enforcements introduced in FIPS
provider for OpenSSL3 (like minimal parameters for PBKDF2).
* Use custom UTF conversion and avoid linking to iconv as a dependency.
* Reimplement BASE64 with simplified code instead of coreutils version.
* Fix regression when warning messages were not displayed
if some kernel feature is not supported (2.4.2).
* Add support for --key-slot option in luksResume action.
Libcryptsetup API extensions and changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Properly define uint32_t constants in API.
This is not a real change, but it avoids strict compiler warnings.
* crypt_resume_by_token_pin() - Resume crypt device using LUKS2 token.
* crypt_get_label() - Get the label of the LUKS2 device.
* crypt_get_subsystem() - Get the subsystem label of the LUKS2 device.
* Make CRYPT_WIPE_ENCRYPTED_ZERO crypt_wipe() option obsolete.
It was never implemented (the idea was to speed up wipe), but with
the recent RNG performance changes, it makes no longer sense.
* Add struct crypt_params_reencrypt changes related to decryption.
* Improve crypt_reencrypt_status() return values.
Empty or any non-LUKS types now returns CRYPT_REENCRYPT_INVALID status.
For LUKS1 devices, it returns CRYPT_REENCRYPT_NONE.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
