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.
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.)
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.)
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
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.
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
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.
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.
We need to use the iv_large_sectors flag and correct sector size
for the crypt segments for these devices. Used sector size is
read from the device header. This commit also adds two new test
images with 4k sectors.
Fixes: #557
Kernel 5.7 adds support for optional discard/TRIM operation
for dm-integrity (available only for internal hash, not for LUKS2
with integrity).
This patch adds support for the new option.
