The volume key structure may often be in configuration
where 'key' member does not contain real data. Some
examples:
- volume key acquired by querring device-mapper where key
was originaly passed by kernel keyring reference.
- volume key allocated by crypt_alloc_volume_key(size, NULL)
With this patch access to internal 'uninitialized' data result
in failed assert().
For use cases where key data are not needed (keyring reference wrapper,
key length info only) we do not have to allocate and lock the safe
buffer in memory.
Further improvements might to completely hide the volume key internals
and access only via setter and getter functions.
crypt_volume_key_length() for key length
crypt_volume_key_get_key() to access key data (if initialized)
crypt_volume_key_description() for kernel key description
crypt_volume_key_kernel_key_type() for kernel keyring key type
This is only preparation for an extension later, however, the volume
keys should not be unloaded unconditionally from keyring.
Note that all other places dropping keys already check that keys
were uploaded through key ID setting.
(And for suspend unconditional unlink make sense too.)
The key_decripion always contains only a key name,
keyring then contains type of keyring as defned un keyring utils.
For now, only LOGON type is used in commands, it will be extended later.
This patch switches code to SPDX one-line license identifiers according to
https://spdx.dev/learn/handling-license-info/
and replacing long license text headers.
I used C++ format on the first line in style
// SPDX-License-Identifier: <id>
except exported libcryptsetup.h, when only C comments are used.
The only additional changes are:
- switch backend utf8.c from LGPL2+ to LGPL2.1+ (as in systemd)
- add some additional formatting lines.
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).
This patch adds support for using keyring for volume key
and support for new integrity fields for dm-crypt.
Also helpers for searching disk by id.
To be used later.
It is possible to overflow integers during memory allocation with
insanely large "key bytes" specified in a LUKS header.
Although it could be argued to properly validate LUKS headers while
parsing them, it's still a good idea to fix any form of possible
overflow attacks against cryptsetup in these allocation functions.
