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]
When integritysetup formats a device with hash or HMAC integrity checksums,
it requires explicitly tag size entry from a user (or default value).
This leads to confusion and shortened tags.
This patch calculates tag size according to real hash output, and
if tag size is specified, it warns if these values differ.
Fixes: #492.
The dump operation prints the fix_padding flag if set.
Also try to print warning if an old kernel is used and th edevice
cannot be activated because of missing fix padding support.
If user has volume key available, LUKS device can be resumed
directly using provided volume key.
No keyslot derivation is needed, only key digest is checked.
Fixes: #502.
If we format LUKS2 device with parameters unsuitable
for current metadata device size we usually fail during header areas
wipe. It was not clear what the reason actually was.
- make error messages propagated to users more comprehensible
- drop some error messages completely
- replace many error messages with debug logs only
Fixes#458.
keyslot_cipher member leaked after existing LUKS2 context reload.
crypt_keyslot_set_encryption may access freed memory if
crypt_keyslot_get_encryption was previously called with
CRYPT_ANY_SLOT parameter.
It's useful to reencrypt only initial device part only.
For example with golden image reencryption it may be useful
to reencrypt only first X bytes of device because we know
the rest of device is empty.
