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.
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>
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.
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.
Optional parameter root hash signature is added that can be added to
veritysetup.
The signature file is opened and the signature is added to the keyring.
The kernel will use the signature to validate the roothash.
Usage: veritysetup open <data_device> name <hash_device> <root_hash> --root-hash-signature=<roothash_p7_sig_file>
Signed-off-by: Jaskaran Khurana <jaskarankhurana@linux.microsoft.com>
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
[Original patch rewritten by Milan Broz]
This patch adds support for fixed padding to cryptsetup.
* Cryptsetup will accept superblocks version 4.
* If the dm-integrity target version is greater than 1.4, cryptsetup will
add a flag "fix_padding" to the dm-integrity target arguments.
There is still one quirk: if we have an old libdm without
DM_DEVICE_GET_TARGET_VERSION and if dm-integrity module is not loaded,
cryptsetup will not detect that it can use the "fix_padding" option.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
All set_segment funcions must use uin64_t everywhere,
not size_t that is platform dependent.
The code later uses it correctly, it is just wrong function
prototype definitions.
Reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935702
(TODO: add a test for other segment types.)
Support for multi-segment devices is requirement for online
reencryption to work. Introducing modififed dm backend that
splits data structures describing active device and individual
dm target (or segment).
Since the kernel 4.18 there is a possibility to speficy external
data device for dm-integrity that stores all integrity tags.
The new option --data-device in integritysetup uses this feature.
Linux kernel since version 4.18 supports automatic background
recalculation of integrity tags for dm-integrity.
This patch adds new integritysetup --integrity-recalculate options
that uses this option.
crypt_deactivate_* fail earlier without noisy dm retries
when other device holders detected. The early detection
works if:
a) other device-mapper device has a hold reference on the
device
- or -
b) mounted fs is detected on the device
Any deactivation flag CRYPT_DEACTIVATE_FORCE or
CRYPT_DEACTIVATE_DEFERRED will disable this detection
This patch adds support for using keyring for volume key
and support for new integrity fields for dm-crypt.
Also helpers for searching disk by id.
To be used later.
Code is written by Ondrej Kozina.
This patch adds ability to store volume key in kernel keyring
(feature available in recent kernels) and avoid setting
key through dm-ioctl and avoiding key in table mapping.
Will be used in LUKS2.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Because there are already 3 targets used, the current detection
based only on dm-crypt is not sufficient.
Add new definition of dm_flags that allows separate target version detect.
Note: we do not want to load targets explicitly; instead, we repeats
detection after operation that could trigger target load.
If dm_flags() call fails, then the target is not yet loaded.
The dm-integrity target is intended to be used for authenticated
encryption through LUKS and dm-crypt.
It can be used in standalone as well; for this use case there
is a simple configuration utility called integritysetup
(similar to veritysetup to dm-verity).
