Skip to contentSkip to conversation

New: Cannot open encrypted Luks root filesystem

Bug 112631 [email protected] 1 participant 31 messages Feb 17, 2016 – Mar 11, 2016

lore
Share & tools
lore
#0 lore raw

https://bugzilla.kernel.org/show_bug.cgi?id=112631

            Bug ID: 112631
           Summary: Cannot open encrypted Luks root filesystem
           Product: File System
           Version: 2.5
    Kernel Version: 4.1.18
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: ext4
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No
Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#1 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #1 from alex.theoto <[email protected]> ---
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

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#4 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

Karl Sponser <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #2 from Karl Sponser <[email protected]> ---
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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#5 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

Andreas Amann <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #3 from Andreas Amann <[email protected]> --- I have the same problem. Bisection leads to the following commit:

commit 0571ba52a19e18a1c20469454231eef681cb1310

Author: Herbert Xu <[email protected]>
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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#6 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

Manu Bourguin <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #4 from Manu Bourguin <[email protected]> ---
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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#7 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

Henrique de Moraes Holschuh <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #5 from Henrique de Moraes Holschuh <[email protected]> --- 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.

Signature · 5 lines
You are receiving this mail because:
You are watching the assignee of the bug.--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#8 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #10 from [email protected] ---
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)

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#9 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

alex.theoto <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

     Kernel Version|3.10.97, 3.14.61, 3.18.27,  |3.10.97, 3.14.61, 3.18.27,
                   |4.1.18, 4.3.6, 4.4.2        |4.1.18, 4.4.2
Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#10 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #11 from alex.theoto <[email protected]> --- (In reply to Henrique de Moraes Holschuh from comment #6)

Quoted 9 lines

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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#11 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

alex.theoto <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

     Kernel Version|4.1.18                      |3.10.97, 3.14.61, 3.18.27,
                   |                            |4.1.18, 4.3.6, 4.4.2
         Regression|No                          |Yes
            Summary|Cannot open encrypted Luks  |Cannot open encrypted Luks
                   |root filesystem             |filesystem. Cruptsetup
                   |                            |error.
Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#12 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

alex.theoto <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

     Kernel Version|3.10.97, 3.14.61, 3.18.27,  |3.10.97, 3.14.61, 3.18.27,
                   |4.1.18, 4.4.2               |4.1.18
Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#13 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #8 from Andreas Amann <[email protected]> --- 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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#15 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #6 from Henrique de Moraes Holschuh <[email protected]> --- 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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#16 lore raw

[Bug 112631] Cannot open encrypted Luks root filesystem

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #9 from Henrique de Moraes Holschuh <[email protected]> --- 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...

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#18 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #13 from Henrique de Moraes Holschuh <[email protected]> --- 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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#19 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #14 from Henrique de Moraes Holschuh <[email protected]> --- While reporting the issue to Debian, I've been contacted by Milan Broz with updated information.

http://www.mail-archive.com/[email protected]/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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#20 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

STRSHR <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #15 from STRSHR <[email protected]> --- (In reply to da_audiophile from comment #10)

Quoted 8 lines

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).

Quoted 5 lines

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

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#21 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

Philipp Dijkstal <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #16 from Philipp Dijkstal <[email protected]> --- Yes. After today's upgrade to cryptsetup 1.7.0-2, it is resolved on my Arch System with 4.1.18 lts kernel.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#22 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #17 from Karl Sponser <[email protected]> ---
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.

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#23 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

--- Comment #18 from [email protected] ---
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

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#24 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

Milan Broz <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #19 from Milan Broz <[email protected]> --- 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/[email protected]/msg17926.html

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.
#29 lore raw

[Bug 112631] Cannot open encrypted Luks filesystem. Cruptsetup error.

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=112631

alex.theoto <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |PATCH_ALREADY_AVAILABLE
Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.