Bug 112631 - Cannot open encrypted Luks filesystem. Cruptsetup error.
Summary: Cannot open encrypted Luks filesystem. Cruptsetup error.
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: File System
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-17 20:08 UTC by alex.theoto
Modified: 2016-03-23 23:41 UTC (History)
14 users (show)

See Also:
Kernel Version: 3.10.97, 3.14.61, 3.18.27, 4.1.18
Tree: Mainline
Regression: Yes


Attachments

Description alex.theoto 2016-02-17 20:08:29 UTC

    
Comment 1 alex.theoto 2016-02-17 20:10:18 UTC
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
Comment 2 Karl Sponser 2016-02-19 18:52:19 UTC
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.
Comment 3 Andreas Amann 2016-02-20 02:28:03 UTC
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>
Comment 4 Manu Bourguin 2016-02-20 10:15:12 UTC
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.
Comment 5 Henrique de Moraes Holschuh 2016-02-20 18:46:50 UTC
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.
Comment 6 Henrique de Moraes Holschuh 2016-02-21 12:00:27 UTC
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.
Comment 7 da_audiophile 2016-02-21 12:02:25 UTC
Regarding comment #6, on 4.3.6 I have no issues mounting a luks partition.
Comment 8 Andreas Amann 2016-02-21 12:55:56 UTC
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.
Comment 9 Henrique de Moraes Holschuh 2016-02-21 14:23:00 UTC
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...
Comment 10 da_audiophile 2016-02-21 16:12:14 UTC
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)
Comment 11 alex.theoto 2016-02-21 16:19:19 UTC
(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.
Comment 12 alex.theoto 2016-02-21 16:35:26 UTC
I'm sorry but I cannot remove the ext4 'assigned to'
Comment 13 Henrique de Moraes Holschuh 2016-02-21 20:14:58 UTC
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.
Comment 14 Henrique de Moraes Holschuh 2016-02-21 21:27:37 UTC
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.
Comment 15 STRSHR 2016-02-23 08:34:39 UTC
(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
Comment 16 Philipp Dijkstal 2016-02-23 09:37:07 UTC
Yes. After today's upgrade to cryptsetup 1.7.0-2, it is resolved on my Arch System with 4.1.18 lts kernel.
Comment 17 Karl Sponser 2016-02-23 19:41:31 UTC
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.
Comment 18 da_audiophile 2016-02-23 20:30:50 UTC
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
Comment 19 Milan Broz 2016-02-23 20:52:11 UTC
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
Comment 20 Karl Sponser 2016-02-24 21:01:42 UTC
Fedora won't patch to cryptsetup, because it's a kernel bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1311286#c2
Comment 21 alex.theoto 2016-03-07 17:57:29 UTC
I think this problem has solved.
There are both new linux-lts and cryptsetup packages available.

Can someone verify this?
Comment 22 Manu Bourguin 2016-03-07 18:03:07 UTC
I try tonight on the latest raspbian to check.
Comment 23 alex.theoto 2016-03-11 17:38:28 UTC
Looks like this bug is fixed.
Closing...
Comment 24 alex.theoto 2016-03-11 17:43:55 UTC
.

Note You need to log in before you can comment on or make changes to this bug.