I cannot boot my system. The root is encrypted with Luks and after booting and enter my password I get the following error: Check that kernel supports aes-xts-plain64 cipher (check syslog for more info) and prompts me again the password. Downgrading into 4.1.17, cryptsetup works fine. Distro: ArchLinux
I can confirm the problem on Fedora ARM with the RPI Kernel 4.1.18 (previous kernels worked). It's not possible to open a luks container nor format a new device: # cryptsetup luksOpen /dev/vg1/test1 luks-test1 Enter passphrase for /dev/vg1/test1: Failed to setup dm-crypt key mapping for device /dev/vg1/test1. Check that kernel supports aes-xts-plain64 cipher (check syslog for more info). # cryptsetup luksFormat /dev/vg1/test2 WARNING! ======== This will overwrite data on /dev/vg1/test2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: Failed to setup dm-crypt key mapping for device /dev/vg1/test2. Check that kernel supports aes-xts-plain64 cipher (check syslog for more info). Even if the message tells to check syslog for more information, there's no entry in /var/log/messages nor in dmesg output.
I have the same problem. Bisection leads to the following commit: commit 0571ba52a19e18a1c20469454231eef681cb1310 Author: Herbert Xu <herbert@gondor.apana.org.au> Date: Wed Dec 30 11:47:53 2015 +0800 crypto: af_alg - Disallow bind/setkey/... after accept(2) [ Upstream commit c840ac6af3f8713a71b4d2363419145760bd6044 ] Each af_alg parent socket obtained by socket(2) corresponds to a tfm object once bind(2) has succeeded. An accept(2) call on that parent socket creates a context which then uses the tfm object. Therefore as long as any child sockets created by accept(2) exist the parent socket must not be modified or freed. This patch guarantees this by using locks and a reference count on the parent socket. Any attempt to modify the parent socket will fail with EBUSY. Cc: stable@vger.kernel.org Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
I confirm same issue, with same error messages with Raspbian Jessie (lite) on Raspberry Pi 2 (ARMv7). Everything is OK with 4.1.17, unable to unlock crypted volume since upgrade to 4.1.18.
From https://lwn.net/Articles/676552/ Posted Feb 20, 2016 16:33 UTC (Sat) by alonz (subscriber, #815) Interesting... the code in cryptsetup indeed breaks the assumptions enforced by this commit (it closed the "tfmfd" before the "opfd", while the code always assumed the opposite and now enforces it). So it has always been "buggy but working" – which is no excuse for breaking userspace.
Meh, cannot fix the bug metadata. Someone with appropriate ACLs (maybe the bug submitter?), please fix: Regression: yes Kernel versions affected: 3.10.97, 3.14.61, 3.18.27, 4.1.18, 4.3.6, 4.4.2. It is assigned to the wrong subsystem (ext4 has nothing to do with this). Remove "root" from bug title, it breaks any attempt to use cryptsetup.
Regarding comment #6, on 4.3.6 I have no issues mounting a luks partition.
Also just tested 4.4.2 and unlocking works. Apparently the original patch c840ac6af3f8713a71b4d2363419145760bd6044 is correct for newer kernels (since 4.3?), but fails for older ones.
It looks like the kernel change actually requires a newer version of cryptsetup to work. cryptsetup 1.6.6 (in Debian stable, for example) is broken (at least on 3.18.27). cryptsetup 1.7.0 has fixes for this, apparently. Looks like the change in Linux needs a KCONFIG guard (default?), that distros can change after they get updated userspace...
Regarding comment #9, Arch Linux ships cryptsetup-1.7.0-1 and when used with 4.1.18-1 does not fix this problem. Enter passphrase for /dev/md0: Failed to setup dm-crypt key mapping for device /dev/md0. Check that kernel supports aes-xts-plain64 cipher (check syslog for more info). uname -r 4.1.18-1-lts pacman -Qs cryptsetup local/cryptsetup 1.7.0-1 (base)
(In reply to Henrique de Moraes Holschuh from comment #6) > Meh, cannot fix the bug metadata. Someone with appropriate ACLs (maybe the > bug submitter?), please fix: > > Regression: yes > Kernel versions affected: 3.10.97, 3.14.61, 3.18.27, 4.1.18, 4.3.6, 4.4.2. > > It is assigned to the wrong subsystem (ext4 has nothing to do with this). > > Remove "root" from bug title, it breaks any attempt to use cryptsetup. Thank you. I'm new here. If there is something wrong, please tell me again.
I'm sorry but I cannot remove the ext4 'assigned to'
Cross-bts link to issue report in cryptsetup upstream: https://gitlab.com/cryptsetup/cryptsetup/issues/284 Apparently, some changes had to be backported to cryptsetup 1.7.x branch, so I expect it will be fixed in the cryptsetup 1.7.1 release, hopefully very soon. The cryptsetup issue report mentions that the kernel change also breaks old versions of libkcapi.
While reporting the issue to Debian, I've been contacted by Milan Broz with updated information. http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg17926.html kernels 4.4.2 and 4.3.6 have a compatibility path that makes them work with old cryptsetup. The two patches implementing that compatibility path are missing from the other kernels, and will require backporting.
(In reply to da_audiophile from comment #10) > Regarding comment #9, Arch Linux ships cryptsetup-1.7.0-1 and when used with > 4.1.18-1 does not fix this problem. > > Enter passphrase for /dev/md0: > Failed to setup dm-crypt key mapping for device /dev/md0. > Check that kernel supports aes-xts-plain64 cipher (check syslog for more > info). > > uname -r > 4.1.18-1-lts > > pacman -Qs cryptsetup > local/cryptsetup 1.7.0-1 (base) Does cryptsetup-1.7.0-2 resolve your issue? https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/cryptsetup&id=ea2c8f73c45aa239ed5f356a8ecd01aeba51ef1d
Yes. After today's upgrade to cryptsetup 1.7.0-2, it is resolved on my Arch System with 4.1.18 lts kernel.
Even if there is an update of cryptsetup available in Arch Linux, other distros doesn't plan to update. E. g. Fedora 23 is on 1.6.8 and I don't know if they will move to a newer version before F24, because they don't ship kernel 4.1.18 (I'm affected because I the RPI kernel on Fedora, because the one they ship doesn't support an RPI). So a workaround/fix for users whose distros won't/can't update cryptsetup is still desirable.
Regarding Comment #17 - It is just 2 patches to apply to cryptsetup. I would think any distro would have no problem with them.[1] 1. https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/cryptsetup&id=ea2c8f73c45aa239ed5f356a8ecd01aeba51ef1d
It is kernel bug and it should be fixed in kernel. Or there is a new rule to break API and userspace in stable kernels? See http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg17926.html
Fedora won't patch to cryptsetup, because it's a kernel bug: https://bugzilla.redhat.com/show_bug.cgi?id=1311286#c2
I think this problem has solved. There are both new linux-lts and cryptsetup packages available. Can someone verify this?
I try tonight on the latest raspbian to check.
Looks like this bug is fixed. Closing...
.