The function never writes on-disk. Also removed validation
function call-in since it will be called later before
writing on-disk and metadata does not have to be complete
at the moment of LUKS2_keyslot_reencrypt_allocate call.
The option --disable-luks2-reencryption completely disable
LUKS2 reencryption code.
When used, the libcryptsetup library can read metadata with
reencryption code, but all reencryption API calls and cryptsetup
reencrypt commands are disabled.
Devices with online reencryption in progress cannot be activated.
This option can cause some incompatibilities. Please use with care.
Fix possible attacks against data confidentiality through LUKS2 online
reencryption extension crash recovery.
An attacker can modify on-disk metadata to simulate decryption in
progress with crashed (unfinished) reencryption step and persistently
decrypt part of the LUKS device.
This attack requires repeated physical access to the LUKS device but
no knowledge of user passphrases.
The decryption step is performed after a valid user activates
the device with a correct passphrase and modified metadata.
There are no visible warnings for the user that such recovery happened
(except using the luksDump command). The attack can also be reversed
afterward (simulating crashed encryption from a plaintext) with
possible modification of revealed plaintext.
The problem was caused by reusing a mechanism designed for actual
reencryption operation without reassessing the security impact for new
encryption and decryption operations. While the reencryption requires
calculating and verifying both key digests, no digest was needed to
initiate decryption recovery if the destination is plaintext (no
encryption key). Also, some metadata (like encryption cipher) is not
protected, and an attacker could change it. Note that LUKS2 protects
visible metadata only when a random change occurs. It does not protect
against intentional modification but such modification must not cause
a violation of data confidentiality.
The fix introduces additional digest protection of reencryption
metadata. The digest is calculated from known keys and critical
reencryption metadata. Now an attacker cannot create correct metadata
digest without knowledge of a passphrase for used keyslots.
For more details, see LUKS2 On-Disk Format Specification version 1.1.0.
LUKS2 encryption with data shift required remaining
data size (size remaining after substracting --reduce-data-size value)
to be at least --reduce-data-size. This was wrong. Remaining
data size restriction should be correctly at least single sector
(whatever sector size is selected or auto-detected).
The hotzone segment offset has to be altered
accordingly no matter the segment type.
Note for testing: This feature is currently
blocked in cli but it should be tested via
API tests anyway.
This reverts commit 367cb7a761
and retains original crypt_reencrypt() symbol marked as deprecated
in favour of new crypt_reencrypt_run(). This makes cryptsetup 2.4.0
release fully backward compatible.
Starting with GCC10 and LTO enabled, current symbols
versioning hack does not work anymore. This patch
reflects on that and should be compatible with older
compilers that does not support __attribute__((symver))
yet.
Inspired by following code:
https://github.com/linux-rdma/rdma-core/blob/master/util/symver.h
The code expects that change key is done in-place if there is not
a free space in keyslot area for safe key swap.
This patch makes the code behaves the same as in LUKS1,
luksChangeKey now works the same.
Introducing new version of crypt_reencrypt symbol including
previously missing usrptr parameter. This change should be
backward compatible for existing libcryptsetup users
until next recompilation where it needs to be fixed.
Original messages could evoke reencryption is currently
in progress. That was inaccurate because code only
detected flag marking such device is in transition state
from metadata pov. We should not imply anything about
running processes. That's detected via reencryption locks.
Currently hard memory limit is 1 GiB. Soft limit is
1/4 of system memory.
Note that --hotzone-size cryptsetup parameter can only further
lower hard and soft memory limit on hotzone size and not bypass
it.
If device properly exposes optimal io size, let's align
reencryption hotzone to it. Otherwise device-mapper driver
complaints about misaligned tables and reencryption performance
is not optimal.
Commit 4c73da31 exposed another bug in minimal device size check.
During reencryption initialization wrong data offset value was used
and adjusted as if device was already undergoing reencryption. The
bug fixed by commit 4c73da31 hid this bug.
This is hotfix only and following functions needs more review:
- LUKS2_reencrypt_data_offset
- LUKS2_get_data_offset
- luks2_check_device_size
- LUKS2_get_data_size
- Remove all 'LUKS2_' name prefixes from internal routines
- Make all internal routines prefixed with 'reencrypt_' instead
- Drop few static routines by refactoring
- Rename all variables and routines containing 'pre' prefix to
contain 'hot' prefix instead (when referring to segments
undergoing reencryption)
- Rename all variables and routines containing 'after' prefix to
contain 'post' prefix instead
- Rename all routines prefixed with '_' to 'reencrypt_' instead
