We can not link internal VK kernel key in custom user
keyring. There are two reasons for it:
The internal VK kernel key description can not be
acquired via API and it may change over time
(LUKS2 reencryption).
With recent SED OPAL support volume key becomes a 'blob'
containing up to two keys (dm-crypt key for SWE and key
for unlocking SED OPAL locking range). The internal
kernel key contains only dm-crypt (if required) but
custom user keyring needs to be provided with whole
volume key (blob).
Added user specified key description for the linked key
in custom user keyring. The linked key can be reached by
the specified description after successful activation (resume).
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.
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.
Reduce bloated code in low level keyring utilities code.
Move log messages higher the library code.
Also return -ENOTSUP when code was compiled out by configure
option.
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>
