The kernel 6.14-rc3 introduced regretion with 1f47ed294a2bd577d5a
The commit changed how errors are propagated and with it OPAL2 devices
no longer returns -EIO on IO to locker region.
Revert this patch after the kernel gets fixed.
The test was supposed to check if invalid --luks2-keyslots-size
metadata value will trigger failure.
The 128MiB was valid value and the test failed only due to smaller
test device size.
(In case of OPAL2 device it spanned into locked region.)
It is really not a good idea to check minor version without
checking major version is not lower first.
Also try to prepare for situation when major target versions
increases.
The panic/restart_on_error options were introduces in kernel 6.12.
As it does not make sense to set these flags without
data corruption handling, only one option error-as-corruption
is implemented that must be used in combination with
panic/restart on corruption.
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).
