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.)
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``.
All distributions provide cryptsetup as distro package. If you need to compile cryptsetup youfself, some packages are required for compilation. Please always prefer distro specific build tools to manually configuring cryptsetup.
Fo available compile options, check ``configure --help`` for more info. If you are using a git snapshot, you need to generate configure script with ``autogen.sh`` script.
All major Linux distributions provide cryptsetup as a bundled package. If you need
to compile cryptsetup yourself, various additional packages are required.
Any distribution-specific build tools are preferred when manually configuring cryptsetup.
Here is the list of packages needed for the compilation of project for particular distributions:
* For Fedora: `git gcc make autoconf automake gettext-devel pkgconfig openssl-devel popt-devel device-mapper-devel libuuid-devel json-c-devel libblkid-devel findutils libtool libssh-devel tar`. Optionally `libargon2-devel libpwquality-devel`. To run internal testsuite you also need `sharutils device-mapper jq vim-common expect keyutils netcat shadow-utils openssh-clients openssh sshpass`.
Below are the packages needed to build for certain Linux distributions:
* For Debian and Ubuntu: `git gcc make autoconf automake autopoint pkg-config libtool gettext libssl-dev libdevmapper-dev libpopt-dev uuid-dev libsepol1-dev libjson-c-dev libssh-dev libblkid-dev tar`. Optionally `libargon2-0-dev libpwquality-dev`. To run internal testsuite you also need `sharutils dmsetup jq xxd expect keyutils netcat passwd openssh-client sshpass`
**For Fedora**:
```
git gcc make autoconf automake gettext-devel pkgconfig openssl-devel popt-devel device-mapper-devel libuuid-devel json-c-devel libblkid-devel findutils libtool libssh-devel tar
Note that the list could change as distributions evolve.
Optionally: libargon2-devel libpwquality-devel
```
To run the internal testsuite (make check) you also need to install
Please read the [FAQ](https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions) and search the manuals (man page, man-page) before posting questions in the mailing list. You will be able to ask better questions and better understand the answers. The FAQ is online and in the source code. The man pages are in source and should be available after installation using standard man commands. e.g. man cryptsetup
### Documentation
Please read the following before posting questions to the mailing list so that
you can ask better questions and better understand answers.
For cryptsetup and LUKS related questions, please use the dm-crypt mailing list, [dm-crypt@saout.de](mailto:dm-crypt@saout.de).
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.
