Wipe and disable the segment. Also support the factory reset ioctl for
a complete wipe of the entire drive with a specific argument.
Signed-off-by: Luca Boccassi <bluca@debian.org>
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
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.
This allows to specify --hash sha or --hash blake2 to limit
KDF without need to specify full algorithm name
(similar to cipher where we already use substring match).
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.
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.
The same problem fixed in commit 438cf1d1b3
is present in libdevmapper wrapper when parsing active device table.
The whole point of conversion was that non-authenticated modes
can be always represented in the old cipher-mode-iv format.
As the internal names contains dash, these are unsupported.
That said, the libdevmapper backend now correctly returns
full cipher specification including capi prefix for this case.
Init_by_name call now fails with incomplatible cipher definition error.
The common way to specify cipher mode in cryptsetup
is to use cipher-mode-iv notation (like aes-xts-plain64).
With introduction of authenticated ciphers we also allow "capi:<spec>"
notation that is directly used by dm-crypt (e.g. capi:xts(aes)-plain64).
CAPI specification was never intended to be used with internal
kernel crypto api names (with dash in algorithm name), actually the
whole parsing routine wrongly parses mode here now.
The code not checks if parsing wrongly separated the full cipher
string and effectively allowing only proper cipher names
(example of no longer supported string is capi:xts(ecb(aes-generic))-plain64).
Thanks to Jan Wichelmann, Luca Wilke and Thomas Eisenbarth from
University of Lübeck for noticing the problems with this code.
Fixes: #809
Aria cipher is similar to AES and is supported
in Linux kernel crypto API in recent releases.
This patch just add support for internal info table.
(This will cause that it is used also for keyslot
encryption if specified as a cipher argument.)
If a user explicitly specifies PBKDF parameters (like iterations,
used memory of threads), do not limit them, even if it can cause
resource exhaustion.
The only limits are hard limits per the PBKDF algorithm.
The force options were mostly used for decreasing parameters,
but it should work even opposite - despite the fact it can mean
shooting yourself in the foot (OOM).
Fixes: #812
As tests shows, limiting used Argon2 memory to free memory on
systems without swap is still not enough.
Use just half of it, this should bring needed margin while
still use Argon2.
Note, for very-low memory constrained systems user should
avoid memory-hard PBKDF (IOW manually select PBKDF2), we
do not do this automatically.
If a partition is resized after format, activation could
fail when the device is not multiple of a sector size.
Print at least warning here as the message is only in syslog.
Related to Issue #807
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.
Benchmark for memory-hard KDF is tricky, seems that relying
on maximum half of physical memory is not enough.
Let's allow only free physical available space if there is no swap.
This should not cause changes on normal systems, at least.
Initialization by name for dm-crypt with integrity is always
underlying device for dm-integrity target, not dm-integrity
device itself.
This fixes various problems like refresh command or
device printed in status command.
Fixes: #801
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.
