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
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.
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 (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).
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.
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.
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
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.
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.
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 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.
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
This patch adds CRYPT_VERITY_ROOT_HASH_SIGNATURE flag to verity info.
Veritysetup status now display "with signature" if an active
device was activated with root hash signature.
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]
Other APIs use the root hash in place of keys when using verity
devices, so do the same for crypt_volume_key_get to allow users
to retrieve the root hash of an active verity device.
Use it in veritysetup status to print the root hash.
[Patch slightly modified by Milan Broz]
