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.
