Description of problem: cryptsetup luksFormat no longer works with default settings. Version-Release number of selected component (if applicable): cryptsetup-2.5.0-1.fc37.x86_64 How reproducible: 100% Steps to Reproduce: $ dd if=/dev/zero of=/var/tmp/disk bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.493301 s, 2.1 GB/s $ cryptsetup -q luksFormat /var/tmp/disk Enter passphrase for /var/tmp/disk: <<< type something random here Not compatible PBKDF options. Requested maximum PBKDF memory cannot be zero. Additional info: I also saw this error but cannot reproduce it locally: Requested hash sha256 is not supported. Failed to set pbkdf parameters.
Could you please post debug log? (Jus tadd --debug to the cryptsetup command). Such error should never happen, somethiung must be mixed up.
Could you please report with full debug output? cryptsetup -q luksFormat /var/tmp/disk --debug Also, please: what Fedora flavor do you have? rpm -q cryptsetup-libs rpmquery -q openssl
$ cryptsetup --debug -q luksFormat /var/tmp/disk # cryptsetup 2.5.0 processing "cryptsetup --debug -q luksFormat /var/tmp/disk" # Verifying parameters for command luksFormat. # Running command luksFormat. # Locking memory. # setpriority -18 failed: Permission denied # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating context for crypt device /var/tmp/disk. # Trying to open and read device /var/tmp/disk with direct-io. # Initialising device-mapper backend library. # Interactive passphrase entry requested. Enter passphrase for /var/tmp/disk: # Checking new password using default pwquality settings. # New password libpwquality score is 81. # Crypto backend (OpenSSL 3.0.5 5 Jul 2022 [default][legacy]) initialized in cryptsetup library version 2.5.0. # Detected kernel Linux 5.19.13-300.fc37.x86_64 x86_64. # PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4. # Formatting device /var/tmp/disk as type LUKS2. # Auto-detected optimal encryption sector size for device /var/tmp/disk is 4096 bytes. # /dev/mapper/control: open failed: Permission denied # Failure to communicate with kernel device-mapper driver. # Incompatible libdevmapper 1.02.175 (2021-01-08) and kernel driver (unknown version). # Topology info for /var/tmp/disk not supported, using default offset 1048576 bytes. # Checking if cipher aes-xts-plain64 is usable. # Using userspace crypto wrapper to access keyslot area. # Formatting LUKS2 with JSON metadata area 12288 bytes and keyslots area 16744448 bytes. # Creating new digest 0 (pbkdf2). # Setting PBKDF2 type key digest 0. # Running pbkdf2(sha256) benchmark. # PBKDF benchmark: memory cost = 0, iterations = 574877, threads = 0 (took 57 ms) # PBKDF benchmark: memory cost = 0, iterations = 852500, threads = 0 (took 615 ms) # Benchmark returns pbkdf2(sha256) 852500 iterations, 0 memory, 0 threads (for 512-bits key). # Segment 0 assigned to digest 0. # Wiping LUKS areas (0x000000 - 0x1000000) with zeroes. # Wiping keyslots area (0x008000 - 0x1000000) with random data. # Reusing open rw fd on device /var/tmp/disk # Device size 1048576000, offset 16777216. # Acquiring write lock for device /var/tmp/disk. # Verifying lock handle for /var/tmp/disk. # Device /var/tmp/disk WRITE lock taken. # Trying to write LUKS2 header (16384 bytes) at offset 0. # Reusing open rw fd on device /var/tmp/disk # Checksum:66088644ed7bcf134c4b9ad46d0d823ec12664f5f4a7c92d7a4c040a3f4624e8 (in-memory) # Trying to write LUKS2 header (16384 bytes) at offset 16384. # Reusing open rw fd on device /var/tmp/disk # Checksum:620c4a3c53f4a7629facbf43cc7f6e3fdf6220e9c560f418d776b34ada24ad30 (in-memory) # Device /var/tmp/disk WRITE lock released. # Adding new keyslot -1 using volume key. # Adding new keyslot -1 with volume key assigned to a crypt segment. # Selected keyslot 0. # Keyslot 0 assigned to digest 0. # Trying to allocate LUKS2 keyslot 0. # Found area 32768 -> 290816 # Running argon2id() benchmark. Not compatible PBKDF options. # Reloading LUKS2 header (repair disabled). # Acquiring read lock for device /var/tmp/disk. # Verifying lock handle for /var/tmp/disk. # Device /var/tmp/disk READ lock taken. # Trying to read primary LUKS2 header at offset 0x0. # Reusing open ro fd on device /var/tmp/disk # LUKS2 header version 2 of size 16384 bytes, checksum sha256. # Checksum:66088644ed7bcf134c4b9ad46d0d823ec12664f5f4a7c92d7a4c040a3f4624e8 (on-disk) # Checksum:66088644ed7bcf134c4b9ad46d0d823ec12664f5f4a7c92d7a4c040a3f4624e8 (in-memory) # Trying to read secondary LUKS2 header at offset 0x4000. # Reusing open ro fd on device /var/tmp/disk # LUKS2 header version 2 of size 16384 bytes, checksum sha256. # Checksum:620c4a3c53f4a7629facbf43cc7f6e3fdf6220e9c560f418d776b34ada24ad30 (on-disk) # Checksum:620c4a3c53f4a7629facbf43cc7f6e3fdf6220e9c560f418d776b34ada24ad30 (in-memory) # Device size 1048576000, offset 16777216. # Device /var/tmp/disk READ lock released. Requested maximum PBKDF memory cannot be zero. # PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4. Existing 'crypto_LUKS' superblock signature on device /var/tmp/disk will be wiped. Existing 'crypto_LUKS' superblock signature on device /var/tmp/disk will be wiped. # Releasing crypt device /var/tmp/disk context. # Releasing device-mapper backend. # Closing read only fd for /var/tmp/disk. # Closing read write fd for /var/tmp/disk. # Unlocking memory. Command failed with code -3 (out of memory).
openssl version is: openssl-3.0.5-2.fc37.x86_64 which is also the latest.
Could you try to run this comand as root? Log is ok, so my theory is that it cannot use memory locking because of limits (root has no limit). (This version use mlockall(MCL_CURRENT | MCL_FUTURE); devel git already switched to locking only small memory area.) What says ulimit -a?
I need to run this command as non-root. Running it as root did solve the problem, but it's not a good solution for me.
$ ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 62397 max locked memory (kbytes, -l) 16384 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 62397 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
(In reply to Richard W.M. Jones from comment #6) > I need to run this command as non-root. Running it as root did solve > the problem, but it's not a good solution for me. I know, this was just test if it is locking or some lib dependecy issue. So if it works, workaround is perhaps to increase max locked memory limit. (Or decrease, so initial locking fails and it runs withot locked memory, this is perhaps why it works in rawhide, as it has limit 8192.)
Can we make it work without locked memory if running as non-root? I suppose it's trying not to leak the Argon2 stuff to swap, but in the scenarios we use LUKS that's not really a concern because we're never on a shared machine. Also any ideas about the other error: Requested hash sha256 is not supported. Failed to set pbkdf parameters. I can only reproduce this under libguestfs on F37, and I suspect we're missing a dependency somewhere.
The sha256 error happens after upgrading openssl from 3.0.3-1.fc37 to 3.0.5-2.fc37.
We need to lock at least keys in memory. There is unfortunatelly no option to disable it (it worked for years and nobody noticed). So once mlockall() is run, it later fails on some random malloc (I guess sha256 bug is just slightly different memory footprint, so it fails in another call). And I can reproduce this on rawhide if memlock limit is set to 16384. I think the workaround will be to add conf per cryptsetup process (config in /etc/security/limits.d/), if it is possible. Next version of cryptsetup will not use memlockal, bu there is no yet release.
So for workaround - I tried to setup this per-user (or groups) and this works. (Argon limit is 1G of memory, so 2G should be enough for everyone :) cat /etc/security/limits.d/cryptsetup.conf @milan hard memlock 2097152 @milan soft memlock 2097152 The real fix comes with the next release (it locks only memory for keys, these are few kb max).
(obviously @milan is a group limit , not user here)(In reply to Milan Broz from comment #12) > So for workaround - I tried to setup this per-user (or groups) and this > works. > (Argon limit is 1G of memory, so 2G should be enough for everyone :) > > cat /etc/security/limits.d/cryptsetup.conf > @milan hard memlock 2097152 > @milan soft memlock 2097152 > > The real fix comes with the next release (it locks only memory for keys, > these are few kb max). (obviously @milan is a group limit , not user here)
The 2G mlock limit does fix the "Requested maximum PBKDF memory" problem for me. However it _doesn't_ solve the "Requested hash sha256 is not supported" problem. I suspect still that we must be missing a package or configuration file inside the libguestfs appliance (this is not reproducible on Fedora host). I wonder if there's a configuration file that controls what hashes are available.
(In reply to Richard W.M. Jones from comment #14) > However it _doesn't_ solve the "Requested hash sha256 is not supported" > problem. Please post --debug here again... (SHA256 is mandatory for LUKS2, it is used in for on-disk header checksum). We should not require openssl conf. You need to copy providers for fips and legacy modes (/usr/lib64/ossl-modules).
$ virt-rescue --scratch ><rescue> echo 123 > /tmp/keys ><rescue> cryptsetup -q luksFormat /dev/sda /tmp/keys --debug # cryptsetup 2.5.0 processing "cryptsetup -q luksFormat /dev/sda /tmp/keys --debug" # Verifying parameters for command luksFormat. # Running command luksFormat. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating context for crypt device /dev/sda. # Trying to open and read device /dev/sda with direct-io. # Initialising device-mapper backend library. # File descriptor passphrase entry requested. # Crypto backend (OpenSSL 3.0.5 5 Jul 2022 [default][legacy]) initialized in cryptsetup library version 2.5.0. # Detected kernel Linux 5.19.13-300.fc37.x86_64 x86_64. Requested hash sha256 is not supported. Failed to set pbkdf parameters. # Releasing crypt device /dev/sda context. # Releasing device-mapper backend. # Unlocking memory. Command failed with code -1 (wrong or missing parameters). ><rescue> ls -l /usr/lib64/ossl-modules/ total 1584 -rwxr-xr-x 1 root root 1488480 Jul 22 02:40 fips.so -rwxr-xr-x 1 root root 120392 Jul 22 02:40 legacy.so Are there any other files or configuration apart from /usr/lib64/ossl-modules/ that could affect this?
This is really strange, but Fedora openssl build has a lot of patches. I do not see much diference to Debian except libxz and fips... Anyway, can you try to run PBKDF2 benchmark that uses SHA256m like cryptsetup benchmark --hash sha256 (this will not require even locking patch). Does it work? If not, does running as root help? Does "openssl help" print sha256 as supported algorithm? I do not think this is problem with cryptsetup, as this calls only OpenSSL code here (the message is printed only as it cannot get hash output size - trivial operation) Is there some easy way to reproduce it (as plain rawhide works)?
OK it turns out that did help to identify the problem -- which is a combination of the way the rescue environment gets built combined with the obscure way that crypto-policies rebuilds configuration files in %post: ><rescue> openssl help FATAL: Startup failure (dev note: apps_startup()) for openssl 004EF21A347F0000:error:80000002:system library:process_include:No such file or directory:crypto/conf/conf_def.c:805:calling stat(/etc/crypto-policies/back-ends/opensslcnf.config) 004EF21A347F0000:error:07000075:configuration file routines:ssl_module_init:ssl command section empty:crypto/conf/conf_ssl.c:96:name=system_default, value=crypto_policy 004EF21A347F0000:error:0700006D:configuration file routines:module_run:module initialization error:crypto/conf/conf_mod.c:270:module=ssl_conf, value=ssl_module retcode=-1 I'm going to file a separate bug because they require Python to create those files which is ridiculous and won't work in our minimal environment.
--> https://bugzilla.redhat.com/show_bug.cgi?id=2133884
Rawhide now contains cryptsetup-2.6.0~rc0-1.fc38 that does not use memlockall(), so the issue should be fixed there.
I just tried to reproduce this with cryptsetup-2.5.0-1.fc37.x86_64 but for some reason I cannot. That's the same version that I originally reported and the same machine too.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.