cpu --perf-* options do not trigger error when
not supported by current kernel.
Also be more carefull about --sector-size when not supported by
dm-crypt. Test is made more pedantic now.
Recent kernel changes disallows to use keyed-hash algorithms
without settting the key.
Unfortunately, dm-integrity fails too late (during IO, not on init).
For now fix just the test.
- adapt tests to new features (luks2 keyslot change, pbkdf params)
- add tests for fixes (max keyslot)
- speed up tests significantly by add minimal forced values everywhere.
The change in keyfile processing caused that special loopAES
keyfiles are no longer read from stdin if key-file argument is "-".
Fix it by using /dev/stdin in cryptsetup if "-" is detected.
(The libcryptsetup API no longer parses spacial meaning of "-" internally).
Fixes#364.
This fixes crypt_keyslot_add_by_key where we were unable to store
keyslot (unbound to segment) with different key_size.
The code used (new) volume key size implicitly which could be wrong
if new size was not compatible with cipher parameter for keyslot area.
Add yet another flawed dm-crypt test (keyring)
and test crypt_get_volume_key_size works
as expected after LUKS2 crypt_format (before
adding first keyslot).
For now, crypto API quietly used cipher witout IV if a cipher
algorithm wihtou IV specificaton was used (e.g. aes-xts).
This caused fail later during activation.
This patch allows only two specific backed use without specified IV
(ECB mode and NULL cipher).
Also check cipher string early during parsing of CLI options.
cryptsetup now requires dm-crypt v1.18.1 or higher
to use kernel keyring service for passing VKs.
Also, relevant API functions fail if CRYPT_ACTIVATE_KEYRING_KEY
is set, but library is not allowed to use kernel keyring for
VK.
The keyfile interface was designed, well, for keyfiles.
Unfortunately, a keyfile can be placed on a device and the size_t offset
can overflow.
We have to introduce new set of fucntions that allows 64bit offsets even on 32bit systems:
- crypt_resume_by_keyfile_device_offset
- crypt_keyslot_add_by_keyfile_device_offset
- crypt_activate_by_keyfile_device_offset
- crypt_keyfile_device_read
The new functions have added _device_ in name.
Old functions are just internall wrappers around these.
Also cryptsetup --keyfile-offset and --new-keyfile-offset must now
process 64bit offsets.
For more info see issue 359.
Originally the key description for VK was derived
from segment id. This could lead to ambiguity when
keyslot key is verified and loaded in kernel keyring
using activation functions with CRYPT_ACTIVATE_KEYRING_KEY
flag raised.
PBKDF2 has nasty behaviour that it generates the same output
for passwords that has several trailing zero bytes.
(IOW null trailing bytes causes collision.)
Unfortunatelly our test plays with password length
and expect wrong length must always fail.
Sometimes the randomly generated key key contains
the null byte in the "wrong" place and PBKDF2 causes test to fail.
For now, fix it by using fixed keyfile without null bytes
(similar to fixed passphrased we already have).
On some systems the requested amount of memory causes OOM killer
to kill the process (instead of returning ENOMEM).
For now, we never try to use more than half of available
physical memory.
This patch duplicates part of the code because following
switch to non-recursive automake is not easily fixable without this change.
(Automake cannot use top_srcdir anymore in this context.)
