Currently we suspend top-level device only.
With OPAL, the underlying device will start to return errors
once OPAL LR is locked.
If the dm-integrity device is not suspended, regular journal
flush corrupts the device (journal write failure),
corrupting data above it.
Suspending the whole stack should fix the issue.
Unfortunately there is currently no way how
to make difference between device lacking SED OPAL support
state and kernel missing SED OPAL support via disabled interface
via configure option.
If LUKS2 keyslot area has to be overwritten (due to lack of free space),
do not wipe the affected area first. It will get overwritten anyway.
Originaly, in between the keyslot wipe and new key material write, pbkdf
calculation took place. The pbkdf calculation takes ~2 seconds by default
and it put the user in unnecesary risk of loosing the keysot data in case
of a crash.
With LUKS2 crypt_keyslot_change_by_passphrase() call
does not have to overwrite binary keyslot
area in-place when user asked for specific keyslot id.
If there's enough free space in keyslot binary area
we can write new keyslot material in the the free area
(identified temporarily by new keyslot id) and switch
pointers (json metadata) to point to the new keyslot area after
the keyslot area write is complete. The old keyslot
area gets deleted after the new area write is finished.
Otherwise we needlesly risk to lose the existing keyslot
if the operation gets interupted.
With this patch LUKS2 crypt_keyslot_change_by_passphrase()
overwrites existing keyslot (including keyslot area)
only if there's no free space and therefore in-place update
is necessary.
Fixes: #839.
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).
Resize operation (crypt_resize) changes only size, so it is safe to
not flush IO (and freeze fs with lockfs) during suspend/resume cycle.
For dm-integrity there can be two suspend/resume cycles as the subsequesnt
call sets recalculating flag.
Based on patch from Yury Vostrikov <mon@unformed.ru>
Resolves: #832
Some chipsets will set write-protection for the *full* drive
even if only small locking range is used.
As LUKS header expect to be writable ehen Opal LR is locked,
this is incompatible with LUKS.
Moreover, device need to be PSID reset and reconnected to clear
the flag. (And kernel lies about write protection so we cannot
get BLROGET ioctl to detect it.)
At least print some warning when LUKS2 header cannot be
written after Opal LR setup.
This applies for all USB adapters/firmware with RTL9210 chipset.
(Need experimental patch to enable Opal through USB.)
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).
When using the --link-vk-to-keyring option, allow specifying the keyring
using the same syntax as keyctl (see "man keyctl"). E.g. "@u" for user
keyring and "%:testring" for a user-created keyring.
Add a new API crypt_set_keyring_to_link nad CLI option
--link-vk-to-keyring. This allows the user to specify ID of the keyring
where the VK should be linked.
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.
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.
This enables creating dm-integrity devices that
does not use all available space but only initial
part of the device.
This will be used with future hw-opal-crypt segment
where partion may be not aligned to locking range
alignment and needs to be reduced.
We dont't want to span dm-integrity device into
area not included in opal locking range.
Deactivation code should deactivate dm-crypt device even if it is unknown
for libcryptsetup. Previous fix for cipher specification was too strict.
Let's allow initialization as null context, that allow status and
deactivate to be usable again.
Code verifying encryption parameters needs to be reusable
for new code that will be added later.
Also due to previous changes to data offset and metadata size
calculations, encryption parameters can now be verified at
single place without need to split it over crypt_format_luks2
routine.
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.
