libcryptsetup kernel feature detection fails on boot

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.

# rmmod dm_crypt

# /usr/lib/systemd/systemd-cryptsetup attach test /dev/loop0 none
allow-discards,tries=0
Please enter passphrase for disk test! ****
Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/loop0.

# cryptsetup status test
/dev/mapper/test is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 256 bits
  device:  /dev/loop0
  loop:    /tmp/testfile
  offset:  4096 sectors
  size:    405504 sectors
  mode:    read/write

# /usr/lib/systemd/systemd-cryptsetup detach test

# /usr/lib/systemd/systemd-cryptsetup attach test /dev/loop0 none
allow-discards,tries=0
Please enter passphrase for disk test! ****
Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/loop0.

# cryptsetup status test
/dev/mapper/test is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 256 bits
  device:  /dev/loop0
  loop:    /tmp/testfile
  offset:  4096 sectors
  size:    405504 sectors
  mode:    read/write
  flags:   discards

The culprit seems to be dm_check_versions() in lib/libdevmapper.c - the version number returned here differs when dm_crypt is not loaded.

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=1115120

- 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=222

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

It is fixed in devel git now. Thanks.

(The main problem with detection of features is that without device-mapper target module loaded there is no way to get the version. And using only kernel version is not enough, e.g. RHEL systems often backports features.)

Milan