It is possible to add multiple recovery passphrases to a BitLocker
device so we should make sure we check both key slots when trying
to activate the device.
The non compact json area may contiain whitespace characters
in between json object key and value (e.g.: {"key": "the_value"}).
For LUKS2 write optimization we need to check and do regression testing
for the case where LUKS2 metadata would contain valid LUKS2 json area in
non compact format. The test is meant to verify if the write optimization
does not leave invalid characters beyond valid and properly terminated
LUKS2 json area.
LUKS2 supports several jsom area length configurations. With
the largest size supported in megabytes we do not want to write full
metadata area unconditionaly (current code) with every metadata
update. This might generate noticeble overhead with LUKS2
reencryption.
With this patch we write only the real used json area
length plus necessary padding to overwrite remaining previous
metadata stored on the disk.
During LUKS2 format and LUKS2 autorecovery we always overwrite
whole json metadata area no matter the used size.
Add a single function to use when generating
json format string representation for on disk
storage purposes so that it can be easily
reused when needed.
We do not need to used crypt_unlink_key_by_description_from_thread_keyring
since it also sets some additional parameters unrelated to dm-verity
signatures.
Also it's useless to search kernel key by description when
we have the key id.
We do not have to query device-mapper subsystem
twice in order to get volume key description in kernel keyring.
Also there was a bug that wrongly used kernel key type set by function
supposed to set custom user key type used only when linking volume key
in arbitrary kernel keyring on caller demand.
Functions related to uploading/unlinking volume keys in user
requested kernel keyrings are named as follows:
crypt_single_volume_key_load_in_custom_keyring
crypt_volume_key_load_in_custom_keyring
crypt_unlink_key_from_custom_keyring
helpers for unlinking LUKS2 volume keys from thread keyring:
crypt_unlink_key_from_thread_keyring
crypt_unlink_key_by_description_from_thread_keyring
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.
