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]
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).
Almost all the headers in cryptsetup are self-suffienct (in that they
compile on their own). By including <stddef.h>, <stdint.h>, or
<sys/types.h>, all headers will now compile on their own.
This is useful for importing cryptsetup into Bazel/Blaze.
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.
It is possible to trigger a double free with an invalid verity
partition. All it takes is an unknown hash algorithm, which makes it
a bit more likely than a completely broken partition header. But all
it takes is an error return value of VERITY_read_sb() or strdup().
If crypt_load fails before setting cd->type, crypt_free will handle
the union as if it was of type "none", which means it will call free()
for "active_name", a field which is only properly set up when the
type was actually "none".
In all other cases, "active_name" contains the first 4 or 8 bytes of
the actually used header structure. Fortunately it can be only a
pointer or NULL, so an attacker has no direct control of the value.
Nonetheless it can easily trigger a double free.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
alter all checks for devfd value after device_open to
less than zero insted of equals to -1. device_open will
return values different from -1 in case error happens.
In LUKSv1 device_open should always return -1 in case of
error but this check is safer.
The rest is just formating improvement.
