For OpenSSL2, we use PKCS5_PBKDF2_HMAC() function.
Unfortunately, the iteration count is defined as signed integer
(unlike unsigned in OpenSSL3 PARAMS KDF API).
This can lead to overflow and decreasing of actual iterations count.
In reality this can happen only if pbkdf-force-iterations is used.
This patch add check to INT_MAX if linked to older OpenSSL and
disallows such setting.
Note, this is misconception in OpenSSL2 API, cryptsetup internally
use uint32_t for iterations count.
Reported by wangzhiqiang <wangzhiqiang95@huawei.com> in cryptsetup list.
Patch libprotobuf-mutator to unpoison buffers obtained from libfuzzer
via LLVMFuzzerMutate. This is required as libfuzzer is usually not
compiled with memory sanitizer support (not even in OSS-Fuzz project,
see https://github.com/google/oss-fuzz/issues/864). Therefore, we
manually mark the buffer as initialized using __msan_unpoison.
Fixes OSS-fuzz bug 52541, 52543 and 52533.
When compiled with enforced ISO C (e.g. -std=c11) 'asm' inline
does not compile (it's GNU extension). Use __asm__ inline assembly
with GCC and clang compliers instead.
Fixes: #786.
For broken metadata BITLK format parsing can cause crash or out of memory
on several places.
Add better size checks to avoid parsing such a metadata.
Also be aware that entry_size can be smalle (so minus operation can underflow).
Also fix memory leak if FVEK entry is more than once in metadata
(just use the first entry and ignore others).
For broken metadata BITLK format parsing can cause crash or out of memory
on several places.
Add better size checks to avoid parsing such a metadata.
Fixes OSS-fuzz bug 54548,54553,54559.
AC_SYS_LARGEFILE autoconf macro is in use in configure script which will
add needed feature macros on commandline to enable 64bit off_t.
Also replace lseek64 with lseek, since it will be same when
_FILE_OFFSET_BITS=64 is defined on relevant platforms via AC_SYS_LARGEFILE
This fixes build with latest musl, where LFS64 interfaces are moved out
of _GNU_SOURCE feature test macros namespace [1]
[1] https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* added fuzz target 'crypt2_load_ondisk_fuzz' that tries to load fuzz input as LUKS1, FileVault2, BitLocker in that order.
* added dictionary for this fuzz target
* added fuzz target to relevant files
If format load fails in some intermediate step, the internal
params struct can contain already set values.
While context is set still to none type, it can cause segfault
in releasing active_name.
(Found by fuzzing target processing crypt_load.)
Skip tests that can not satisfy minimal test passphrase length:
- empty passphrase
- LUKS1 cipher_null tests (empty passphrase is mandatory)
- LUKS1 encryption
The device_check is done in header write functions,
but these are not recached in normal format path as wipe call
is called earlier.
Call the device check also from wipe function to get better error
description.
This situation happens for example when a block device is too small
(regular file can be enlarged by falloc(); block device cannot).
Activation with header only fails too late (in device-mapper
call) while it is clear from the beginning that it cannot succeed.
Just add an early and better worded error.
Ignore this situation for block device (we have to call ioctl to get size).
The most common case is a file container here anyway.
For block devices it fails during activation later.
Header write can call falloc() to increase image size, so we should
check data offset after header is written.
Also change wording to be less cryptic and describe what is the real problem.
Note that the code can be used this way to crate detached header (without
space for data), so it is not an error.
Also fix Makefile to include source in make dist.
Note: we must not use CFLAGS there because possible sanitizers
use will make the loaded library unusable in LD_PRELOAD.
Extends avaiable methods for retrieving device volume key.
The volume key now may be extracted using passphrase, keyfile
(passphrase in a file) or token (LUKS2 only).
For LUKS devices, it returns generated volume key after
sucessfull crypt_format where new volume key got generated.
Fixes: #777.
First, there was a bug where passphrase based
keyslot contextets did not cache volume keys
properly and caused leaks.
Second, it causes problems when keyslot context
is used twice with different keyslot id, e.g.:
CRYPT_ANY_SLOT vs specific id, unbound key vs
volume key, etc.
The function is supposed to check if manipulated
active dm-crypt device matches the on-disk metadata.
Unfortunately it did not take into account differences
between normal cipher specification (aes-xts-plain64)
and capi format specification (capi:xts(aes)-plain64).
The internal query function always converted capi format
in normal format and therefor failed if capi format was
used in metadata.
Fixes: #759.
- Do not require any libraries installed, download everything
from upstream git, statically compile (use include, libs and pkg-config
from local directory under tests/fuzz).
Script should work both from OSS-Fuzz and locally.
- Do not require local protobuf (only staticallly compiled, see above).
- Add README.md (TBD, still not finished).
- Fix make dist and distcheck.
- Remove common.[ch] as we can use internal function.
This makes fuzzers also C++ only (remove CFLAGS from Makefile).
In LUKS1 there is only one hash algorithm specification,
it cannot happen, that AF hash algorithm is not
available, as it is used immediately before in PBKDF2.
In LUKS2 this can be completely different algorithm, so
it make sense to print a visible warning for user.
For example, Whirlpool and RIPEMD160 is now in OpenSSL legacy
provider which can be unavailable, see #773.)
This patch adds a message only, the code already fails with -EINVAL.
In practice luksAddKey action does two operations. It unlocks existing
device volume key and stores unlocked volume key in a new keyslot.
Previously the options were limited to key files and passphrases.
With this patch user may combine freely following options:
To unlock keyslot with volume key user may:
- provide existing passphrase via interactive prompt (default method)
- use --key-file option to provide file with a valid passphrase to existing keyslot
- provide volume key directly via --volume-key-file
- unlock keyslot via all available LUKS2 tokens by --token-only
- unlock keyslot via specific token with --token-id
- unlock keyslot via specific token type by --token-type
To provide the passphrase for a new keyslot user may:
- provide existing passphrase via interactive prompt (default method)
- use --new-keyfile parameter or positional parameter to read the
passphrase from file.
- use --new-token-id to select specific LUKS2 token to get passphrase
for new keyslot. New keyslot is assigned to selected token id if
operation is succesfull.
Fixes: #725.
The crypt_keyslot_add_by_keyslot_context & associated
helper functions allow more options when adding new
keyslot. For example there was no simple way of
adding new LUKS2 keyslot when the only active keyslot
could be unlocked by passphrase (KEK) provided by LUKS2 token
(plugin). Now all available options for unlocking keyslots
may also be used when creating new keyslot and it combine
as called needs.
The available methods (keyslot contexts) are:
passphrase, keyfile, key (binary representation) and LUSK2 token.
json-c parser transforms NULL pointer into special '(null)' string.
While being technically correct it hides the fact user passed NULL
pointer in crypt_token_params_luks2_keyring structure. This bug
could be trigerred by calling crypt_token_luks2_keyring_set().
Following API calls trigerred LUKS2 metadata reload
from storage in case of failure:
crypt_convert
crypt_keyslot_add_by_key
crypt_keyslot_add_by_keyfile_device_offset
crypt_keyslot_add_by_passphrase
crypt_keyslot_change_by_passphrase
crypt_reencrypt_init_by_keyring
crypt_reencrypt_init_by_passphrase
This patch replaces LUKS2 metadata reload with
backup LUKS2 metadata copy kept in memory that is updated on
each sucessfull metadata write and rolled back to it whenever
needed in any of those calls listed above.
The content of LUKS header is not a key material, no need
to lock memory for possibly big header and big memory area locks.
Just ensure we wipe buffer before release of memory.
This patch locks all memory ranges in safe allocations.
While crypto backend can have some secure memory calls,
it is usually limited by intitial config.
For our use is enough to keep keys in memory and prevent
swapping it out.
If the lock fails (because of limits) we quietly
stay with plain malloc.
System FIPS mode check is no longer dependent on /etc/system-fips
file. The change should be compatible with older distributions since
we now depend on crypto backend internal routine.
This commit affects only FIPS enabled systems (with FIPS enabled
builds). In case this causes any regression in current distributions
feel free to drop the patch.
For reference see https://bugzilla.redhat.com/show_bug.cgi?id=2080516
The Debian tooling sets ‘LDFLAGS = -Wl,-z,relro -Wl,-z,now’ and
complains when anything is built without hardened compiler/linker flags.
Granted this is a non-issue here since fake_token_path.so isn't included
in any binary package, but muting the false positive is arguably no
better fix than honoring $(LDFLAGS) during the build.
When reencrypting image files cryptsetup is unable to
detect reliably if image file is in use or not.
User must decide it explictly. Add error message that
references --force-offline-reencrypt to solve the issue
in non interactive mode.
(It will be replaced with early detection in before 2.5.0 final
release).
Do not invalidate LUKS2 format when future online-reencrypt
requirement flag is encountered (by older releases).
But it must stop device from being activated, reencrypted
or modified.
Empty context or any non-LUKS types now returns
CRYPT_REENCRYPT_INVALID value.
For LUKS1 devices return CRYPT_REENCRYPT_NONE
(since any LUKS1 device in legacy reencryption
does not have valid LUKS1 header/metadata).
If keyslots are not sorted according to binary area offset,
the calculation of area size is wrong and can overflow
(LUKS1 does not store area size, only offset).
Let's just use function that calculates size from volume key size.
Images where keyslot areas are not aligned to 4k offset
are not supported anyway.
Fixes: #753
By not testing repeatedly that 'wipe' test utility actually
wipes the device. This test is supposed to test reencryption
code.
I have left untouched already existing first time checks
for each data digest.
Invalid values that overflows in interval check were silently ignored.
Fix this by explictily adding check for interval overflow in keyslots
and segment validation.
Fixes: #748
Adds support for LUKS2 decryption of devices with a
header put in the head of data device. During the initialization
header is exported to a file and first data segment
is moved to head of data device in place of original header.
The feature introduces several new resilience modes (combination
of existing modes datashift and "checksum" or "journal").
Where datashift resilience mode is applied for data moved towards
the first segment and first segment is decrypted in-place.
The mode is not backward compatible with prior LUKS2 reencryption
and therefor interrupted operation in progress can not be resumed
using older cryptsetup releases.
Fixes: #669.
Upper layers always expected 0 on error.
Due to this bug this function could cause
sector_size overflow when segment definition
did not contain 'sector_size' field ('linear').
If some kdf are not available, we incuidentally returned EINVAL
error code instead od EPERM.
This caused that error message is not correctly printed and also
retry count is not applied.
Fixes: #745.
Refresh (and therefore suspend hotzone) reencryption dm
segments in-before actual hotzone reencryption takes place.
This commit shortens time window during which hotzone is
suspended. Also it avoids eventual deadlock if reencryption process
triggers page miss during storage wrapper reinitialization and required
data is stored in (previously) suspended hotzone (corner case).
Checksum hash parameter obtained via API call can not be used directly.
It gets lost during subsequent call to crypt_reencrypt_init_by_* API
when library reloads crypt context.
There are some historic incompatibilities that are ignored
for LUKS1 but do not work for LUKS2.
Check the cipher before conversion through crypto backend.
Also it switches LUKS2_check_cipher to use userspace backend only
(this should be ok for the reencryption code that uses it too).
Fixes: #641
Due to commit 0113ac2d88
we recalculate reencryption digest whenever LUKS2 reencryption
keyslot gets updated. Until now we perform reencryption digest
refresh every time we call LUKS2_keyslot_reencrypt_update even
when no metadata was updated.
This improves on it and should speed up reencryption resume
process.
The LUKS2 reencrypt keyslot update process should
not be performed in crypt_reencrypt_run() loop where
data reencryption takes place.
The proper location is reencryption process initialization
when we validate reencryption metadata and decide if
new user provided resilience metadata are valid.
Prior to commit 0113ac2d88 it did
not matter what resilince metadata we stored during initialization.
So we stored 'none' type unless 'datashift' operation was initialized.
After the commit, it triggered reencryption metadata digest refresh
almost each time (except 'datashift') which was suboptimal.
By storing proper resilience type during reencryption initialization
we will avoid the needless reencryption digest refresh later (after
update optimization).
The structure is supposed to store all data necessary to perform
reencryption crash recovery. The data block size stored
in LUKS2 metadata was missing and stored in reencryption top level handle
instead.
Ths will allow automatic scan of known formats.
Errors are printed only if something is wrong with already detected metadata.
This change means that it is responsibility of the caller to print an error
message if needed.
Also fix some places without a message.
Fixes: #642
If cryptsetup/integritysetup tool is too old, it can happen that
kernel dm-integrity uses more recent version of dm-integrity metadata.
Print (and also traslate) better error in this case.
Fixes: #667
If LUKS2 is used with integrity protection, there is always a dm-integrity
device underneath.
We should deactivate the device if DM status return tag size (it means,
that dm-crypt uses dm-integrity DIF).
This allows "cryptsetup close <name>" peroperly remove both stacked devices
even if LUKS2 header is no longer available (like in detached header activation).
While the metadata device is detached header here, integrity
superblock is located on the data device.
For standalone integrity device it is diffferent
- data device contains only data and possible metadata device
contains integrity superblock and tag areas.
Fix it by checking metadata format.
Fixes: #609,#730
Fast xxhash64 algoritm can be used for integrity protection.
Add implicit tag size (so user do not need to use --tag-size),
mention it in man page and add a test.
Fixes: #632
If existing data device is used, user must specify --no-wipe option
otherwise data device is wiped.
(Tags then can be recalculated on activation with --integrity-recalculate option).
Fixes: #679
INTEGRITY_key_size returns -EINVAL for algorithms without a key
and because crypt_params_integrity.integrity_key_size is an
unsigned integer we get key size 4294967274 instead of more
appropriate 0 for these algorithms.
Calculating device sizes for verity devices is a little bit tricky,
Data, hash and FEC can share devices or it can be a separate devices.
This patch prints used device sizes in veritysetup dump command,
but it requires that user specifies all values that are not stored
in superblock (like a FEC device and FEC roots).
Replace check for argp_usage by argp_parse as argp_usage is not used by
cryptsetup. Moreover, this will fix the following build failure raised
with argp-standalone in version 1.4.0 and
e7ff8d9787:
/home/autobuild/autobuild/instance-10/output-1/host/lib/gcc/i686-buildroot-linux-musl/10.3.0/../../../../i686-buildroot-linux-musl/bin/ld: tokens/ssh/cryptsetup_ssh-cryptsetup-ssh.o: in function `parse_opt':
cryptsetup-ssh.c:(.text+0x14c): undefined reference to `argp_state_help'
/home/autobuild/autobuild/instance-10/output-1/host/lib/gcc/i686-buildroot-linux-musl/10.3.0/../../../../i686-buildroot-linux-musl/bin/ld: tokens/ssh/cryptsetup_ssh-cryptsetup-ssh.o: in function `main':
cryptsetup-ssh.c:(.text+0x7db): undefined reference to `argp_parse'
Fixes:
- http://autobuild.buildroot.org/results/cb3fdae4e0da603f304501f65127800346cb3915
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
The function wrongly expected segment objects being
ordered (ascending order) in segments container.
The LUKS2 format never guaranteed that and it could
lead to wrong LUKS2 device size calculation in case
last segment (by key) was stored before any other segment
with fixed size.
The eventual logical block size increase on dm-crypt device above
filesystem block size may lead making fs unusable. Do not allow
offline reencryption when sector size increase is requested.
If users really want to perform it make them use existing
--force-offline-reencrypt option.
The journal crypt is in wrong format (this never worked! :),
here it takes kernel syntax.
Also use CBC a CTR mode could be missing here.
Fox typo in key length caclulation.
Clear temporary dm devices after test, loop devices are reused.
If the first device format is ok, all subsequent cals should
be treated as an error.
By changing encryption sector size during reencryption we may
increase effective logical block size for dm-crypt active device.
For example if hosted filesystem on encrypted data device
has block size set to 512 bytes and we increase dm-crypt logical
size durign reencryption to 4096 bytes it breaks the filesystem.
Do not allow encryption sector size to be increased over value
provided by fs superblock in BLOCK_SIZE property.
The check is applied while initialising LUKS2 device encryption
(reencrypt --encrypt/--new) or when initialising LUKS2 reencryption
on active dm-crypt device.
Note that this check cannot be applied on offline device (data device
is encrypted).
We should abort LUKS device in-place encryption
when target data device or metadata device
contain broken LUKS metadata (any version).
Filed crypt_load() call was not good enough check
because the call fails also when a device contains
LUKS metadata overlapping with other superblock
(e.g. LVM2 PV signature).
Let blkid decide if device contains broken LUKS
metadata or not.
Fixes: #723.
Do not resume reencryption operation with conflicting parameters.
For example if operation was initialized as --encrypt do not
allow resume with oposing parameter --decrypt and vice versa.
Also checks for conflicting --resilience parameters (datashift cannot
be changed after initialization).
Previously, conflicting reencryption parameters were silently ignored.
So, for example operation initialized with mode --encrypt and resumed
with mode --decrypt simply finished --encrypt operation and did not
report any error. This could lead to impresion different type of
operation was perfomed instead.
Fixes: #570.
If auto-detection fails for other reason just return the
error. Users may now bypass active device auto-detection
with --force-offline-reencrypt option.
It can be used to enforce offline reencryption
in batch mode when data_device is regular file
and therefore cryptsetup cannot detect properly
active device dm name.
Also it may be useful when active device
auto-detection fails for some reason and user
has no other choice but inspect device holders
manually.
To allow resizing integrity devices with detached metadata device, the
check has to be moved from _compare_integrity_devices to
_reload_device_with_integrity.
If the provided key is NULL, we load it from the active device. This is
always available, since keyring keys are not supported in kernel for
integrity devices.
Try to avoid accidental nested encryption via
cryptsetup reencrypt --new/--encrypt command.
If detached header or data device is already reported
as LUKS1 or LUKS2 device operation gets aborted.
Fixes: #713.
Bitlocker compatible mode uses dm-zero to mask metadata area,
device cannot be activated if dm-zero is not available.
Just add zero target check to device-mapper backend and
if activation fails, print a better error message here.
Fixes: #722
When user provides --token-type or specific --token-id
prefer token PIN query over passphrase query (if token
handler responds with 'PIN needed').
Fixes: #670.
The progress routine is now fully translated and
prints out progress in following manner (examples):
Progress: 25,5%, ETA 00m31s, 7 GiB written, speed 838,6 MiB/s
Progress: 25,5%, ETA 20h11m31s, 7 GiB written, speed 24 KiB/s
Progress: 25,5%, ETA 06 days, 12 MiB written, speed 4 KiB/s
Also got rid of -lm dependency due to floor().
Fixes: #671.
If passphrase is read from a real terminal, there is maximum
interactive input length applied. This means that passphrase
can be trimmed in this case.
This patch adds debug log warning, if read does not detect
end of input (EOL or EOF) and the maximal input read is achieved.
We cannot say for sure if the next character is EOL without
actually reading it, debug warning should be enough in this case.
Fixes: #699
Commit 0113ac2d broke test passphrase mode when
device was in LUKS2 reencryption.
Previously --test-passphrase parameter automatically raised
CRYPT_ACTIVATE_ALLOW_UNBOUND_KEY flag. It did not make sense
when users mostly want to test whether device can be activated by
provided passphrase or not. Raise the aforementioned flag only
if user requested it either by --unbound parameter or when
specific keyslot was selected.
Reported in: https://bugzilla.redhat.com/show_bug.cgi?id=2056439Fixes: #716.
Move code setting data device during format so that
we can properly detect optimal encryption sector size
for data device instead of metadata device (header).
Fixes: #708.
We should avoid silently skipping the test if there is something
wrong with the test itself. If we have all dependencies, the test
should be able to run.
ssh-copy-id requires password authentication that might be disabled
on some cloud images. We can simply copy the key manually, because
everything runs on localhost anyway.
Fixes: #701
Abort action luksResume early if device is not suspended.
We would needlesly ask for passphrase or load cryptsetup
plugins only to fail later in crypt_resume_by_* API.
If configured with --disable-cryptsetup (e.g. if only veritysetup is
required), these tests won't be able to run cryptsetup, so they need
to be skipped.
It breaks compile time check for __attribute__((__symver__))
and it does not make sense either. Quoting gcc man page:
-Wno-attributes
Do not warn if an unexpected "__attribute__" is used, such as
unrecognized attributes, function attributes applied to variables,
etc. This does not stop errors for incorrect use of supported attributes.
Well, we do want to check for unsupported __attributes__ un our code,
right?
Attribute unused is useless and makes code imcomprehensible
when decorates internal functions not exposed via API.
Let's cleanup internal funtion prototypes whenever possible.
Returning from the thread creation function is documented to be a valid
way of exiting a thread on both Windows and pthread systems. Removing
the explicit call avoids the need to install libgcc_s.so in initramfs
for glibc systems, and slightly reduces code size.
Upstream: https://github.com/P-H-C/phc-winner-argon2/pull/331
This should silence similar warnings like
warning: cast from 'char *' to 'struct xyz *' increases required alignment from 1 to X
when we try to calclulate byte pointer offsets in a buffer.
Apparently FIPS mode enforces somewhere minimal key size.
As 64bit key is no longer useful anyway, just remove it.
Apparently cipher_null is now more safer with the longer key,
isn't? :-)
OpenSSL with FIPS provider now doesn't not support SHA1.
Kernel still does, but some operations fail anyway (we get
hash size from crypto backend).
Let's remove most of the SHA1 use in tests, SHA1 removal
will happen anyway.
The LUKS1 compatimage is regenerated with the same parameters,
just hash is switched to sha256 so we do not need to fix tests.
OpenSSL now enforces minimal parameters for PBKDF2 according to SP 800-132
key length (112 bits), minimal salt length (128 bits) and minimal number
of iterations (1000).
Our benchmark violates this, causeing cryptsetup misbehave for luksFormat.
Just inrease tet salt to 16 bytes here, it will little bit influence benchmark,
but there is no way back.
It is almost impossible for contributors to replicate our warnings
if filtered. Let's make it simpler.
Also run clang with extended warnings (some fixes needed).
`make -f Makefile.localtest tests CRYPTSETUP_PATH=/sbin TESTSUITE_NOSKIP=y`
exits with status 77 upon the first skipped test. This can be useful
when a full test coverage is desired.
As before the test suite exits (with status 1) as soon as a failed (or
skipped when the TESTSUITE_NOSKIP environment variable is defined to
non-empty string) test is encountered.
AFAIK older versions of the POSIX Standard didn't specify a way to
locate commands. Many operating systems and distributions added a
which(1) utility for that purpose, unfortunately without consistent
behavior across the board.
OTOH POSIX.1-2008 (or was it older? POSIX.1-2001 mentions it too, but
with a restriction: “On systems supporting the User Portability Utilities
option”) specifies that `command -v` can be used for that purpose:
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/command.html
Moreover the standard adds that if the argument is neither a valid
utility, builtin, shell function nor alias then “no output shall be
written and the exit status shall reflect that the name was not found”.
It's therefore no longer needed to void the error output (spewing error
messages was one of the inconsistent behavior of the different which(1)
utilities).
The upcoming Debian 12 (codename Bookworm) appears to have deprecated
its which(1) utility (as a first step for its removal from the base
system):
$ which foo
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
In most places the deprecation notice isn't visible when running the
test suite because most `which` calls run with the error output
redirected to /dev/null, however this is not the case everywhere:
https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.4.3/tests/integrity-compat-test#L333https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.4.3/tests/reencryption-compat-test2#L232
This commit replaces all `which` calls from tests/* with `command -v`,
and removes the error output redirection.
crypt_reencrypt_status() returns this flag if old
online-reencrypt requirement is detected and reencryption
keyslot digest is missing.
crypt_reencrypt_init_by_passphrase() with same flag applied
repairs (upgrade) reencryption metadata so that
automatic reencryption recovery during activation
is again possible and reencryption operation can be resumed
post CVE-2021-4122 fix.
The function never writes on-disk. Also removed validation
function call-in since it will be called later before
writing on-disk and metadata does not have to be complete
at the moment of LUKS2_keyslot_reencrypt_allocate call.
The option --disable-luks2-reencryption completely disable
LUKS2 reencryption code.
When used, the libcryptsetup library can read metadata with
reencryption code, but all reencryption API calls and cryptsetup
reencrypt commands are disabled.
Devices with online reencryption in progress cannot be activated.
This option can cause some incompatibilities. Please use with care.
Fix possible attacks against data confidentiality through LUKS2 online
reencryption extension crash recovery.
An attacker can modify on-disk metadata to simulate decryption in
progress with crashed (unfinished) reencryption step and persistently
decrypt part of the LUKS device.
This attack requires repeated physical access to the LUKS device but
no knowledge of user passphrases.
The decryption step is performed after a valid user activates
the device with a correct passphrase and modified metadata.
There are no visible warnings for the user that such recovery happened
(except using the luksDump command). The attack can also be reversed
afterward (simulating crashed encryption from a plaintext) with
possible modification of revealed plaintext.
The problem was caused by reusing a mechanism designed for actual
reencryption operation without reassessing the security impact for new
encryption and decryption operations. While the reencryption requires
calculating and verifying both key digests, no digest was needed to
initiate decryption recovery if the destination is plaintext (no
encryption key). Also, some metadata (like encryption cipher) is not
protected, and an attacker could change it. Note that LUKS2 protects
visible metadata only when a random change occurs. It does not protect
against intentional modification but such modification must not cause
a violation of data confidentiality.
The fix introduces additional digest protection of reencryption
metadata. The digest is calculated from known keys and critical
reencryption metadata. Now an attacker cannot create correct metadata
digest without knowledge of a passphrase for used keyslots.
For more details, see LUKS2 On-Disk Format Specification version 1.1.0.
Windows 11 now includes the BitLocker volume GUID in the BEK file
metadata entries. This was previously not included so cryptsetup
refused to open the file because there was an unknown metadata
entry in the startup key.
Fixes: #690
LUKS2 encryption with data shift required remaining
data size (size remaining after substracting --reduce-data-size value)
to be at least --reduce-data-size. This was wrong. Remaining
data size restriction should be correctly at least single sector
(whatever sector size is selected or auto-detected).
Currently, token import and token add actions will fail if you use the
--token-id option to specify a token ID that is already in use, but there
are scenarios where you might genuinely want to replace an existing token
in a single atomic operation.
A use case for this might be for a keyslot that is protected by a
TPM, where you store the TPM sealed key and associated metadata as a
token and you want to update the PCR policy associated with the sealed
object or make other changes to it. Currently this requires importing a
new token and then removing the old token.
Instead, add a --token-replace option to allow token import and token
add to replace an existing token if you try to add or import one with an
ID that is already in use.
On some "broken" systems, udev directory (where we try to check
if device is active) is present, but the symlink is missing.
Let's fallback in this case on sysfs scanning also, otherwise
possible conversion of an active device can cause data corruption.
LUKS2 code read the whole header to buffer to verify checksum,
so malloc is called on unvalidated input size parameter.
This can cause out of memory or unintentional device reads.
(Header validation will fail later anyway - the size is unsupported.)
Just do not allow too small and too big allocations here and fail quickly.
Fixes: #683.
These tools do not read passphrases, no need to link to these libraries.
Just move the helper code that introduced this dependence as a side-effect.
Fixes: #677
This happens when concurrent creation of DM devices meets
in the very early state (no device node exists but creation fails).
Return -ENODEV here instead of -EINVAL.
(Should "fix" random verity concurrent test failure.)
If zeroing memory is implemented through libc call (like memset_bzero),
compiler should never remove such call. It is not needed to set O0
optimization flag explicitly.
Various checkers like annocheck causes problems with these flags,
just remove it where it makes no sense.
(Moreover, we use the same pattern without compiler magic
in crypt_backend_memzero() already.)
The hotzone segment offset has to be altered
accordingly no matter the segment type.
Note for testing: This feature is currently
blocked in cli but it should be tested via
API tests anyway.
Fully leverage openssl custom library context for various
providers (default, legacy). It can be used to properly
free all openssl resources used by libcryptsetup when
libcryptsetup is unloaded (and destructor is triggered).
Currently LUKS2 decryption cannot perform data decryption
with data shift. Even though we can decrypt devices with
data offset > 0 in LUKS2 metadata it does not make much
sense. Such devices cannot be easily mounted after decryption
is finished due to said data offset (fs superblock is moved
typicaly by 16MiBs).
This patch removes magic for backup load that quietly
run lowecase conversion and add this possibility to repair command.
Most of crypto backends allow uppercase though.
1) Crypsetup repair should try to call crypt_repair() even
if crypt_load is ok - it has no validate system unlike LUKS2
and some errors cannot be hard load errors.
2) Move ECB fix to repair code, do not try magic on load that
no longer works.
And do not use ECB :)
Fixes: #664
While adding or importing new token and assigning immediately to
keyslot it would be useful to provide specific error message
directly from cryptsetup utility when keyslot does not exist.
If distro does not use udev/blkid, there is no IO event after activation.
Kernel does not mark the device corrupted then (it happens on the
first IO). Just add a simple read to trigger it.
The external gettext library should be used on main libcryptsetup,
not later for programs (these do not call any translations).
(Also it was in the wrong order there failing compilation.)
If crypto backend does not provide configured hash,
fail crypto backend tests.
(User has to use configure option if backend does not provide seclected algorithm.)
Seen recently with RIPEMD160.
Note: NSS does not provide RIPEMD, use --with-plain-hash etc.
The signature description should be allocated only if params field is used,
otherwise we can leak the string value.
(Moreover, the query path is currently used only for flag, not for the value.)
Allow to pass the root hash via a file, rather than verbatim on
the command line, for the open/verify/format actions.
It is much more convenient when using veritysetup in scripts.
[some modifications by mbroz:]
- Add additional syntax and option description to man page.
- Fix a segfault with non-existing path.
- Do not read full file.
- Small refactor for argc handling and option processing.
This reverts commit 367cb7a761
and retains original crypt_reencrypt() symbol marked as deprecated
in favour of new crypt_reencrypt_run(). This makes cryptsetup 2.4.0
release fully backward compatible.
crypt_activate_by_token functions did not respect LUKS2 keyslot
priorities. These calls were able to activate device via keyslot with
CRYPT_SLOT_PRIORITY_IGNORE even when token was set to
CRYPT_ANY_TOKEN. This commit changes the token based activation
so that keyslot with priority ignore is eligible for unlock only
when specific token is selected. Also when activating with token
set to CRYPT_ANY_TOKEN keyslots with higher priority take precedence
over keyslots with normal priority. Keyslot with priority ignore are
correctly ignored when token is CRYPT_ANY_TOKEN.
crypt_activate_by_token (and _pin variant) now returns -ENOANO
instead -EAGAIN in case token handler identifies specific token
requires PIN to sucessfully complete token based activation.
-EAGAIN is now used for special case when additional system
resources are missing (HW token, other device, system daemon,
etc).
The deadlock is hypothetical since libcryptsetup applications
usualy terminates after error. The deadlock could only emerge
in case where single process handles multiple crypt contexts.
The old API is still supported and because we support very old
OpenSSL, this is the best wrokaround for the warnings.
Once we switch to the new OpenSSL version requirement, we can rewrite
HMAC to new EVP_MAC API.
Reverts commit 96d83455ca partially. It is not necessary to
have specific crypt_activate_by_token_type call. Users
may use crypt_activate_by_token_pin with pin argument set to NULL
and achieve same goal as with crypt_activate_by_token_type.
Currently the "add" action adds the token to all keyslots, this
changes the behaviour to make sure the token is added to the first
keyslot that can be unlocked using the provided passphrase.
Test needs to work also in build environment
before installation takes place. For it we overload
crypt_token_external_path symbol from libcryptsetup
so that it can look for plugins in build environment.
[simplified by mbroz]
Search for token handlers in %{libdir}/cryptsetup directory
by default. Distros may change default location via
--with-luks2-external-tokens-path parameter during configuration.
Argon2 draft defines suggested parameters for disk encryption use, but LUKS2
approach is slightly different. We need to provide platform independent
values. The values in draft expects 64bit systems (suggesting using 6 GiB
of RAM), while we need to provide compatibility with all 32bit systems,
so allocating more than 4GiB memory is not option for LUKS2.
The maximal limit in LUKS2 stays for 4 GiB, and by default LUKS2
PBKDF benchmarking sets maximum to 1 GIB, prefering increase of CPU cost.
But for the minimal memory cost we had a quite low limit 32 MiB.
This patch increases the bechmarking value to 64 MiB (as minimal
suggested values in Argon2 RFC). For compatibility reasons we still
allow older limit if set by a parameter.
Cryptsetup LUKS2 was using Argon2 while there were two versions -
data independt (Argon2i) suitable for the KDF use case andm Argon2d
(data dependent), that is in princile unsuitable for LUKS2.
Later a new version Argon2id was introduced and this is now default
(and mandatory) algorithm as RFC Argon2 draft defines.
While Argon2id basically combines both approaches from Argon2i
and Argon2d (to provide bette side-channel resistence) it seems
reasonable to switch to Argon2id as default.
Fixes: #555
While TrueCrypt is no longer developed and supported since 2014,
VeraCrypt devices (as a successor of TrueCrypt) are much more
used today.
This patch switch default to scan for VeraCrypt signature, making
--veracrypt option obsolete (ignored by default as it is default).
If you need to disable VeraCrypt support, use new option
--disable-veracrypt.
This patch fixes several problems:
- some optional features for dm-verity can be larger than pre-allocated buffer
- device paths and other strings can be allocated dynamically
- featured options with keys in dm-integrity are not wiped on stack
- get rid of strncat()
- always check return code of snprintf
Related #648
Due to nature of recent change in GCC10 that silently
broken symbol versioning, let's be a bit pedantic
and test all symbols are available in all versions that
meant to be exported to users.
Starting with GCC10 and LTO enabled, current symbols
versioning hack does not work anymore. This patch
reflects on that and should be compatible with older
compilers that does not support __attribute__((symver))
yet.
Inspired by following code:
https://github.com/linux-rdma/rdma-core/blob/master/util/symver.h
The new dm-integrity option in kernel 5.13 can restart
recalculation from the beginning of the device.
It can be used to change the integrity checksum function.
This patch adds support to libcryptsetup for this flag
and adds --integrity-recalculate-rest option to integritysetup.
Fixes: #631.
In ideal system nothing should touch test devices, but to make tests
more robust, we should expect that something is still scanning devices
after activation. So replace all checks for CRYPT_ACTIVE to allow
also CRYPT_BUSY.
(Fixes some problems seen in #633)
We support most recent crypto algorithms, so this
is only addition of the Blake hash family.
Kernel and gcrypt crypto backend supports all variants,
OpenSSL only Blake2b-512 and Blake2s-256.
There is no useable support for NSS and Nettle yet.
Crypto backend supports kernel notation e.g. "blake2b-512"
that is translated to the library backend names.
Starting with version 2.0.0, libpasswdqc can use memory allocation
when loading configuration that contains new optional parameters.
It's therefore recommended to free all memory allocated by
passwdqc_params_load using new passwdqc_params_free function
introduced in the same version of libpasswdqc.
[slightly modified by mbroz]
Some stable kernels started to return buffer from terminal
in partial buffers of maximal size 64 bytes.
This breaks all passphrases longer than 64 characters entered
through interactive input (for all crypto formats).
(The problem is probably fixed in more recent kernels, but
the read() call can always return a partial read here.)
This patch also fixes wrong password limit, the last character
of passphrase of maximal size was never handled.
Now the maximal passphrase length is really 512 characters.
Fixes: #627.
Most of these functions already works even with device=NULL.
There can be some rare situations when this call could happen,
so be safe always.
(Like initialization for a device that disappears during init.)
Also see
https://bugzilla.redhat.com/show_bug.cgi?id=1932946
The error correction can fix even problem with root hash.
For now, always return fail if initial check of root hash failed.
FIXME: The FEC verify code need to be rewritten to repair only
blocks where hash is wrong and the re-check hash after recovery,
inclkuding root hash.
Now we do not check hash after FEC recovery. The Reed-Solomon
decoder can then "repair" code wrongly if parity is too damaged.
For now, the information about FEC repaired errors is only
advisory, it does not mean device is fully repaireable.
Do not write more than needed header if hash area is not used later.
All space in hash area is then used in FEC calculation, so it makes
no sense to add unused area.
Reencryption did not take into account adjusted xts
key size configuration option. This patch fix the
issue by using same logic as in luksFormat with xts
mode selected for data encryption.
By default when reencrypting LUKS2 device we regenerate only
the volume key. But if the device was 'encrypted' by cipher_null
this change did not make sense. The key was always empty.
Change the behaviour so that unless user specifies --cipher
parameter on command line, we change data encryption cipher
to default when old segment cipher was cipher_null.
By mistake LUKS2 allowed keyslots 'not-so-encrypted' by
cipher_null (only explicitly requested by --cipher or
--keyslot-cipher parameters). If we encounter
such old key during reencryption let's replace the cipher
for new keyslot with default LUKS2 keyslot cipher.
It does not make sense to upload volume keys in
kernel keyring if segment cipher is cipher_null.
The real volume_key is thrown away and replaced
with empty key anyway.
This bug enabled to create LUKS2 keyslots encrypted by
cipher_null when explicitely requested by user. LUKS2
was never meant to allow keyslot encryption with
cipher_null. cipher_null is meant for debug purposes
only as a segment cipher.
FEC (Forward Error Correction) data should cover the whole data area,
hashes (Merkle tree) and optionally additional metadata (located after hash area).
Unfortunately, if FEC data is stored in the same file as hash, the calculation
wrongly used the whole file size thus overlaps with FEC area itself.
This produces unusable and too large FEC data.
(There is not a problem if FEC image is a separate image.)
This patch fixes the problem, introducing FEC blocks calculation as:
-If hash device is in a separate image, metadata covers the whole rest of the image after hash area.
(Unchanged behaviour.)
-If hash and FEC device is in the image, metadata ends on the FEC area offset.
This should probably fix several issues reported with FEC wrong calculations.
Fixes: #554
If FEC was enabled, the error for bad root hash was replaced
by error correction (datga were ok, only root hash was wrong).
Do not run recovery test if root hash is incorrect.
To avoid confusion, use just one lib include and specify sub-directories
for format inclusions.
This should also help some analysis tools to find proper includes.
It is called from kernel crypt backend unconditionally with
the proper define in config.h but some static parrsers are not so clever.
Compilation will fail in linker phase anyway if wrongly used.
The routine was originaly used in code for resetting default
argument values. It was used in cli plugins related code
where we needed to parse command line arguments twice.
This fixes multiple issues found by coverity in the startup key
code and also makes the parsing less complicated -- we don't need
to loop through all metadata entries in the BEK file if we are
expecting only one metadata entry of a specific type.
These are false positives and gcc internal detection of this
pattern seems to be broken again.
In this path we must avoid memcpy the whole buffer, it can contain
some bytes after null char, so use MIN/strlen here.
Provides example of loadable token handler for activation
json validation and metadata dump.
For creating new ssh example token use special cryptsetup-ssh
binary.
Add API call that can directly print JSON metadata area from LUKS2 device.
For commandline it also adds --dump-json-metadata option for luksDump action.
Note that the binary metadata (UUID, version etc) is not part of this output.
(We reserve flags parameter to be able to add this later.)
Fixes: #511
The code expects that change key is done in-place if there is not
a free space in keyslot area for safe key swap.
This patch makes the code behaves the same as in LUKS1,
luksChangeKey now works the same.
With JSON, we can actually retain the slot number in all cases
(except user intentionally set new slot #).
This patch changes the crypt_keyslot_change_by_passphrase() API
call to retain keyslot number for LUKS2.
Fixes: #464
We cannot trust possibly broken keyslots metadata here through LUKS_keyslots_offset().
Expect first keyslot is aligned, if not, then manual repair is neccessary.
(This situation happen if partition table signarture overwrites slot 4 area).
Also, if keyslot order is different, current repair code does not work properly
(this can happen only with downconverting LUKS2 device).
This patch adds support for Linux kernel (since version 5.11) dm-integrity
fixes that disables integrity recalculation if keyed algorithms (HMAC) is used.
Original dm-integrity superblock version <=4 is recalculation offset
field not protected by HMAC. An attacker can move this pointer and force
the kernel to recalculate the data area, ignoring original HMAC tags.
N.B. dm-integrity was not intended to protect against intentional changes.
Better use authenticated encryption (AEAD) in combination with dm-crypt.
It is designed to protect against random data corruption caused by hardware
or storage medium faults.
Despite that, we try to keep the system secure if keyed algorithms are used.
There are two possible keyed algorithms in dm-integrity - algorithm used
to protect journal and superblock (--journal-integrity) and algorithms
for protecting data (--integrity).
The dm-integrity superblock is guarded by --journal-integrity, so if you want
to protect data with HMAC, you should always also use HMAC for --journal-integrity.
The keys are independent. If HMAC is used for data but not for the journal,
recalculation is disabled by default.
For new kernel dm-integrity, the HMAC option also uses salt in superblock
to avoid an easy way to distinguish that the HMAC key is the same for two devices
(if data are the same).
The new HMAC and superblock are enabled automatically if the kernel supports it
(you can see superblock version 5 and fix_hmac flag in dump command).
If you need to use (insecure) backward compatibility, then two new integritysetup
options are introduced:
Use --integrity-legacy-recalc (instead of --integrity-recalc) to allow recalculation
on legacy devices.
Use --integrity-legacy-hmac in format action to force old insecure version
format (with HMAC).
Libcryptsetup API also introduces flags
CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and
CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC
to set these through crypt_set_compatibility() call.
The crypt_activate_by_pin_token may be used only from new
dynamicly loadable token plugins.
Also refactors code for dynamically loadable plugins so
that it does not use crypt_token_handler structure anymore.
Old structure remains used only in crypt_token_register call.
This reverts mostly these commits:
42692418c2a985c12659
The library was ment to export common functions shared by
all cryptsetup tools and planned LUKS2 tokens plugins.
It is no longer needed.
THis fixes a problem for TCRYPT and reencryption in scripts
where "Nothing to read on input." is displayed because
cryptsetup retries password query even in stdin mode.
LUKS2 decryption is currently not supported for devices
with LUKS2 metadata placed in head of data devices. The decryption
still works correctly, but resulting plaintext device has data on
unexpected (original) offset. For example at offset of 16MiB in case
of default LUKS2 header.
Fixes: #614.
crypt_header_is_detached checks if initialized LUKS context uses detached header
(LUKS header located on a different device than data.)
This is a runtime attribute, it does not say if a LUKS device requires detached header.
If user knows which particular PBKDF2 hash or cipher is used for
True/VeraCrypt container, using --hash of --cipher option in tcryptDump
and tcryptOpen can scan only these variants.
Note for the cipher it means substring (all cipher chains containing
the cipher are tried).
For example, you can use
cryptsetup tcryptDump --hash sha512 <container>
Note: for speed up, usually the hash option matters, cipher variants
are scanned very quickly.
Use witch care, in a script it can reveal some sensitive attribute
of the container.
Fixes#608.
Writing into allocated memory right before calling free can be optimized
away by smart compilers. To prevent this, a volatile access must be
performed. This happens already in crypt_safe_memzero.
It was difficult to provoke GCC to remove the assignment, but I was able
to find a way to prove the theory:
* Build cryptsetup with: CFLAGS="-flto -O3 -g" ./configure --enable-static
* Create main.c:
#include <libcryptsetup.h>
int
main(void) {
char *x = crypt_safe_alloc(64);
crypt_safe_free(x);
return 0;
}
* Build the program with: gcc -O3 -flto -static -o main main.c -lcryptsetup
* Disassemble: objdump -d main
My output on an amd64 system is:
0000000000401670 <main>:
401670: 41 54 push %r12
401672: bf f0 03 00 00 mov $0x3f0,%edi
401677: 55 push %rbp
401678: 48 83 ec 08 sub $0x8,%rsp
40167c: e8 ff 4d 01 00 callq 416480 <__libc_malloc>
401681: 48 85 c0 test %rax,%rax
401684: 74 2f je 4016b5 <main+0x45>
401686: 48 c7 00 e8 03 00 00 movq $0x3e8,(%rax)
40168d: 4c 8d 60 08 lea 0x8(%rax),%r12
401691: 48 89 c5 mov %rax,%rbp
401694: be e8 03 00 00 mov $0x3e8,%esi
401699: 4c 89 e7 mov %r12,%rdi
40169c: e8 4f 76 01 00 callq 418cf0 <explicit_bzero>
4016a1: 48 8b 75 00 mov 0x0(%rbp),%rsi
4016a5: 4c 89 e7 mov %r12,%rdi
4016a8: e8 43 76 01 00 callq 418cf0 <explicit_bzero>
4016ad: 48 89 ef mov %rbp,%rdi
4016b0: e8 3b 54 01 00 callq 416af0 <__free>
4016b5: 48 83 c4 08 add $0x8,%rsp
4016b9: 31 c0 xor %eax,%eax
4016bb: 5d pop %rbp
4016bc: 41 5c pop %r12
4016be: c3 retq
4016bf: 90 nop
You can see that the memory allocation and explicit_bzero calls were not
optimized away. But the size assignment disappeared.
Compiling without -O3 or without -flto does not inline the calls and
keeps the assignment. Also the shared library shipped with my
distribution has the assignment.
It makes more sense to return "real" key sizes, e.g. 256 bit for
AES-XTS 128 and 256/512 bit for AES-CBC with Elephant which has
a separate key for the Elephant mode.
* Rename "BASIC COMMANDS" to "BASIC ACTIONS"
* Changed a sentence saying that luksFormat would work on unmapped luks containers, only.
* Insert 6 examples of using cryptsetup for luks containers
There is a memory leak when PBKDF2_temp > UINT32_MAX. Here,
we change return to goto out to free key.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The value of h may be NULL. Check it vefore visiting its
memeber to avoid segfault.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The value of vk may be NULL in _keyslot_repair. It will
be dereferenced in LUKS_generate_phdr. Check it to avoid
segfault.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The return value of malloc vmk and params->fvek is not
checked. Here we add checking.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
Both BitLocker version 1 and NTFS have the same bootcode eb 52 90
so when trying to open an NTFS device user will get error message
saying that BitLocker version 1 is not supported. This patch
switches to check the superblock first to inform user that the
device is not a BITLK device.
We zero data parts of the test images to make them as small as
possible and for the latest startup key image I deleted bigger
portion of the NTFS header by accident which caused older blkid
on CentOS/RHEL 6 to not identify the NTFS filesystem on the
cleartext device.
We can't easily distinguish between a passphrase and other
protectors like recovery passphrase or startup key during
activation so we can't stop when attempted passphrase activation
fails because a binary startup key can't be conveted to UTF-16
during KDF.
More data about the new IOCTL is here:
https://lwn.net/Articles/818870/
We see 200-500ms boot speed improvement on our platform.
Prefer to define IOCTL when kernel is older version. Also eliminate
duplication since as a result of introduced ifdef.
Signed-off-by: Sinan Kaya <sinan.kaya@microsoft.com>
Right now, cryptsetup makes an attempt to include the correct
definitions in all of its header files, allowing the headers to
compile regardless of the context in which they are included.
A few files were missed, this change fixes them by adding the minimal
set of #includes needed to get them to compile.
Signed-off-by: Joe Richey <joerichey@google.com>
TrueCrypt/VeraCrypt supports backup header, it seems to have
the same format as normal header.
Let's use --header option here, it can be used to unlock data partition
with header backup (open and dump commands).
Fixes: #587.
User have to install gettext package or manually disable translation
using --disable-nls.
Also remove links to GNU packages ftp, all of these should by provided
by native distro packaging systems.
Fixes: #591.
cipher[31] and cipher_mode[31] buffers were passed to
crypt_parse_name_and_mode() routine where sscanf(s, "%31[^-]-%31s",
cipher, cipher_mode) was called.
In corner case it could cause terminating 0 byte written beyond
respective arrays.
Keep it simple. If there's not enough memory we can't validate
segments. The LUKS2 specification does not recommend to continue
processing LUKS2 metadata if it can not be properly validated.
In case LUKS2 backup segment creates gap in between last regular
segment and backup segment report invalid metadata imediately. We stop
on first error so there's no need to allocate large memory on heap
(we may ran with mlock(MCL_FUTURE) set).
Example:
- total segments count is 3
- regular segments have keys "0" and "1"
- first backup segment has key "42"
Segments are validated in hdr_validate_segments. Gaps in segment keys
are detected when collecting offsets. But if an invalid segment is very
large, larger than count, it could happen that cryptsetup is unable to
allocate enough memory, not giving a clue about what actually is the
problem.
Therefore check for gaps even if not enough memory is available. This
gives much more information with debug output enabled.
Obviously cryptsetup still fails if segments are perfectly fine but not
enough RAM available. But at that stage, the user knows that it's the
fault of the system, not of an invalid segment.
These performance options, introduced in kernel 5.9, configures
dm-crypt to bypass read or write workqueues and run encryption
synchronously.
Also support persistent storage of these flags for LUKS2.
Introducing new library supposed to be used in
cryptsetup tools and future cryptsetup loadable plugins
TODO:
- distribution
- cleanup header files
- incorporate also plugin API?
The issue can be reproduced very easily by starting 2 veritysetup processes
at the same time:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814021
device-mapper: create ioctl on img CRYPT-VERITY-cea03b7bc5b94e088e5754ff33be71d6-img failed: Device or resource busy
Verity device detected corruption after activation.
Command successful.
Command failed with code -1 (wrong or missing parameters).
Note how veritysetup open is reporting -EINVAL as the return code.
After the fix:
$ sudo veritysetup open -v ./img.raw img ./img.verity & sudo veritysetup open -v ./img.raw img ./img.verity
[1] 814649
Verity device detected corruption after activation.
Command successful.
Device img already exists.
Command failed with code -5 (device already exists or device is busy).
- crypt_token_register must not be called from withing crypt_token_load
(see later commits)
- minor bug in dlvsym/dlerror handling
- check for overflow in LUKS2_token_handler_type
Introducing new version of crypt_reencrypt symbol including
previously missing usrptr parameter. This change should be
backward compatible for existing libcryptsetup users
until next recompilation where it needs to be fixed.
If users want to use blake2b/blake2s, the kernel algorithm name
includes dash - like "blake2s-256".
Because we use dash as a separator, this patch adds an exception
for this case.
Fixes: #581.
TrueCrypt/VeraCrypt always use 512-bytes sector for encryption,
but for devices with a larger native sector it stores this value in header.
This patch allows activating of such devices, basically ignoring
the mentioned sector size in header (it only must be multiple
of 512-bytes sector).
Fixes: #580.
When creating LUKS2 header with specified --offset much larger
then LUKS2 header size we needlessly also wipe (allocate up to
--offset) much larger file than needed.
We've assumed that first 4 bytes of the decrypted key data is the
size of the key + metadata. Looks like this isn't true and only
first two bytes contain the size and the other two bytes are
unknown data, possibly related to reencryption and/or passphrase
change.
Fixes: #575
All POPT_ARG_STRING pointers must be free'd manually
in calling application. This is unfortunately not documented
well behaviour of popt and we were having memory leaks due to
it.
This is part of effort to eliminate all memory leaks related
to options parsing in popt but for that to work we must avoid
passing constant strings to free().
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.
