From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com
 [IPv6:2a00:1450:400c:c03::232])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Wed, 23 Jul 2014 09:45:35 +0200 (CEST)
Received: by mail-we0-f178.google.com with SMTP id w61so742442wes.23
 for <dm-crypt@saout.de>; Wed, 23 Jul 2014 00:45:34 -0700 (PDT)
Message-ID: <53CF681B.8030500@gmail.com>
Date: Wed, 23 Jul 2014 09:45:31 +0200
From: Milan Broz <gmazyland@gmail.com>
MIME-Version: 1.0
References: <53CEE763.4030409@archlinux.org>
In-Reply-To: <53CEE763.4030409@archlinux.org>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dm-crypt] libcryptsetup kernel feature detection fails on boot
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: =?ISO-8859-1?Q?Thomas_B=E4chler?= <thomas@archlinux.org>, dm-crypt@saout.de, Milan Broz <gmazyland@gmail.com>

On 23.7.2014 0:36, Thomas B=E4chler wrote:
> Since cryptsetup 1.6.5, libcryptsetup fails to detect the kernel's
> features on boot. In particular, whenever the dm-crypt module is not
> loaded before configuring a mapping with libcryptsetup, the
> allow_discards option is not used.

Hm, yes, that's possible... dmcrypt is now needed only on activation
(previaously it was loaded earlier perhaps).

Well, the workaround for now is probably to always load dmcrypt module,
I'll try to fix it soon.

Milan

p.s.

FYI there are more problems discovered by the userspace header processing
in 1.6.5 (I expected these appears when introducing truecrypt format which
uses the same logic but unfortunately that was not the case).

- with SELinux in enforcing mode (and proper policy, in Fedora this applies
only to systemd-cryptsetup which is labeled as init process) it fails
to activate volumes.
Apparently kernel crypto API socket was never labeled properly(!)
(kernel selinux subsystem bug, patch on the way upstream).
See https://bugzilla.redhat.com/show_bug.cgi?id=3D1115120

- with some crazy configuration we hit the problem that some hash algorithm
are not available in userspace (whirlpool256 for example) so when
used in ESSIV it fails. There was conservative approach to fallback to old
mode, unfortunately I did not implement it correctly for this case.
See https://code.google.com/p/cryptsetup/issues/detail?id=3D222

So anyway, expect cryptsetup 1.6.6 to fix these...