keyring_link_key_to_keyring_key_type could accidentaly
mask an unreachable key and make it look that key was
succesfully linked in custome keyring when it was not.
Resize operation (crypt_resize) changes only size, so it is safe to
not flush IO (and freeze fs with lockfs) during suspend/resume cycle.
For dm-integrity there can be two suspend/resume cycles as the subsequesnt
call sets recalculating flag.
Based on patch from Yury Vostrikov <mon@unformed.ru>
Resolves: #832
If old util-linux is used, blkid scan can fail because disk
is already locked for OPAL.
Do the same for other internal blkid issue.
Also add some debug messages to be clear what's going on.
Some chipsets will set write-protection for the *full* drive
even if only small locking range is used.
As LUKS header expect to be writable ehen Opal LR is locked,
this is incompatible with LUKS.
Moreover, device need to be PSID reset and reconnected to clear
the flag. (And kernel lies about write protection so we cannot
get BLROGET ioctl to detect it.)
At least print some warning when LUKS2 header cannot be
written after Opal LR setup.
This applies for all USB adapters/firmware with RTL9210 chipset.
(Need experimental patch to enable Opal through USB.)
It makes key verification easier and also allows digest
verification for keys not assigned to device segment
(unbound keys) for more keyslot context types (tokens).
Add --volume-key-keyring option, which takes a name of a key in keyring,
which will be used as a VK during device activation. The key can be
specified in keyctl-compatible syntax "%<key_type>:<key_name>".
Test various combinations of arguments for the options
--link-vk-to-keyring and --volume-key-type. Add API tests for the
crypt_set_keyring_to_link and crypt_set_vk_keyring_type functions.
When using the --link-vk-to-keyring option, allow specifying the keyring
using the same syntax as keyctl (see "man keyctl"). E.g. "@u" for user
keyring and "%:testring" for a user-created keyring.
Add a new API crypt_set_keyring_to_link nad CLI option
--link-vk-to-keyring. This allows the user to specify ID of the keyring
where the VK should be linked.
Just unlink it from thread keyring where it is linked. The key should
get destroyed automatically once the reference count goes to zero, so
the revoke is redundant (unless there's a bug in the kernel keyring).
Note: the explicit revoke would destroy the key even when it is linked
to a user specified keyring.
Extends code so that later API may support LUKS2 device
activation via token with specified keyslot.
Also allows testing if specific token is able to unlock specific
keyslot.
When formating LUKS2 device with no keyslots area (it's valid
LUKS2 header) there's a bug in wipe routine that is supposed
to wipe LUKS2 keyslots area. When the keyslots area size is of
zero length it causes wipe function to erase whole data device
starting at defined data offset.
When no header is available but LUSK2_OPAL dm uuid
prefix is detected try to lock opal locking range
upon LUKS2 device deactivation (best effort only as
in crypt_suspend).
LUKS2 devices with configured HW OPAL encryption (any configuration)
get activated with private dm uuid prefix LUKS2-OPAL so that we
can properly detect devices with HW OPAL encryption even with
missing LUKS2 header (detached header). Internally LUKS2-OPAL
prefix matches LUKS2 device type.
