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.
Switch current code to use following volume key helpers
for accessing internal properties:
crypt_volume_key_length(), crypt_volume_key_get_key(),
crypt_volume_key_description() and crypt_volume_key_kernel_key_type()
Remaining direct access to volume key internals will be dealt with in
later commits since it requires some further changes.
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
There were two different use cases for weaker keys:
1) empty keys (zero filled buffer)
2) weak 'random' keys not sucking entropy while being generated
Those key types must not be used to encrypt real data. It's used either
to check cipher can be configured sucessfully on the system or as
a fake envelope during metadata repair.
The volume key uploaded attribute is respected only with
regard to volume keys uploaded in the thread keyring in logon key type.
Here the uploaded attribute was set for volume keys uploaded in
custom user keyrings in custome key descriptions.
The file is used to describe project compilation independent
of build system in use.
It can also help LSP servers to improve code suggestions since
it can see how the project is configured and respect, for example,
content of config.h file.
The dm-integrity table always contains number of feature arguments
(since introduction in kernel 4.12).
Moreover, the code already dereferences params field, so the test
make no sense.
Found by CodeQL check.
If bash test script uses a pattern that test that command should fail
command && fail
(IOW fail function is called only if command exited successfully),
it can mask potential segfault, as it return non-zero exit code.
Fix it by using trap for scripts that uses this pattern.
The same applies for SIGABRT (abort() call).
Reaching maximal keyfile size is already reported as error.
Note that interactive really means user entering password.
For all other us there is keyfile processing.
Related: #933
