The read in kernel crypto backend is part of user crypto API
encryption call, we have to trust it here.
JSON fix is just one place where return code was not checked
for this particular function.
It can be used to override system library where
libcryptsetup looks for external token handlers (plugins).
The parameter is required to be absolute path and it is set
per process context.
Fixes: #846.
Add more context to possibly failing kernel keyring routines
in log debug output.
Mostly split debug output for errors while trying to search the kernel
key by description and errors while trying to read/unlink the key
by its id.
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).
Extends code so that later API may support LUKS2 device
activation via token with specified keyslot.
Also allows testing if specific token is able to unlock specific
keyslot.
When formating LUKS2 device with no keyslots area (it's valid
LUKS2 header) there's a bug in wipe routine that is supposed
to wipe LUKS2 keyslots area. When the keyslots area size is of
zero length it causes wipe function to erase whole data device
starting at defined data offset.
When no header is available but LUSK2_OPAL dm uuid
prefix is detected try to lock opal locking range
upon LUKS2 device deactivation (best effort only as
in crypt_suspend).
LUKS2 devices with configured HW OPAL encryption (any configuration)
get activated with private dm uuid prefix LUKS2-OPAL so that we
can properly detect devices with HW OPAL encryption even with
missing LUKS2 header (detached header). Internally LUKS2-OPAL
prefix matches LUKS2 device type.
While activation of internal cipher algorithms (like aes-generic)
is disallowed, some old LUKS2 images can still use it.
Check the cipher in activate call, but allow to load LUKS2 metadata.
This can allow to add repair code easily and also allow luksDump.
Also fix segfault in reencrypt code for such a header.
Fixes: #820
Let's make LUKS2_generate_hdr as clean as possible. Cipher
specification string can be constructed in upper layers.
This will make future LUKS2_generate_hdr extension easier.
The integrity is optional parameter of dm-crypt segment definition.
Move the low level json code in appropriate json helper.
It will make adding new segment easier. The future hw-opal-crypt
segment will inherit all crypt fields.
Move all metadata size and data offset calculations
logic away from LUKS2_generate_hdr. The function
was meant to generate solely LUKS2 header on disk json
format.
The aim is to have all logic related data offset and metadata
size in one place available to be calculated in advance so
that we can easily extend the code.
Function is similar to json_object_object_add_by_uint but
it unsets *jobj_val_ref pointer if the function ends with
success.
It helps to create cleaner error patch and avoids eventual
double free corruption if **jobj_val_ref object changed
ownership.
This warning is displayed only if maximum memory was adjusted:
no swap, not enough memory, but is not printed if user set keyslot
memory cost above default limit intentionally.
In the latter case we have to check all available memory and guess
if swap is enough - this is not job af cryptsetup and also
it should not excessively parse any /sys files during keyslot open.
For OpenSSL2, we use PKCS5_PBKDF2_HMAC() function.
Unfortunately, the iteration count is defined as signed integer
(unlike unsigned in OpenSSL3 PARAMS KDF API).
This can lead to overflow and decreasing of actual iterations count.
In reality this can happen only if pbkdf-force-iterations is used.
This patch add check to INT_MAX if linked to older OpenSSL and
disallows such setting.
Note, this is misconception in OpenSSL2 API, cryptsetup internally
use uint32_t for iterations count.
Reported by wangzhiqiang <wangzhiqiang95@huawei.com> in cryptsetup list.
