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 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.
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.
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>
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.
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).
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.
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.
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.
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
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).
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
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
Attribute unused is useless and makes code imcomprehensible
when decorates internal functions not exposed via API.
Let's cleanup internal funtion prototypes whenever possible.
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.
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.
