partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb

[Jonathan Riddell]

[Impact]

 * Performing automatic encrypted LVM installation using Kubuntu and Xubuntu 12.04.4 alternate installer images results in a failure to configure encrypted volumes. Please either use manual partitioning to create encrypted volumes with any non-default "IV algorithm" setting or use 12.04.3 media to complete the installation.

[Error Message]
Configuration of encrypted volumes failed.
An error occurred while configuring encrypted volumes.
The configuration has been aborted.

[Cause of the bug]

 * xts.ko kernel module is missing from 3.2 crypto-modules-udeb

[Working (older) media]

 * Kubuntu http://cdimages.ubuntu.com/kubuntu/releases/12.04.3/release/

 * Xubuntu http://cdimages.ubuntu.com/xubuntu/releases/12.04.3/release/

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1276739

[Jonathan Riddell (jr)]

http://people.ubuntu.com/~jr/tmp/syslog
syslog of install, search for HERE for where the encryption problem occurs (I continued the install without encryption)

[Dimitri John Ledkov (xnox)]

So the only change in the partman-crypto for 12.04.4 is to start using aes-xts-plain64 cipher to protect installations from the pre-imaging attack.

From the syslog:
Feb 6 00:52:00 partman-crypto: kernel entropy_avail: 181 bits
Feb 6 00:52:12 partman-crypto: device-mapper: reload ioctl failed: No such file or directory
Feb 6 00:52:12 partman-crypto:
Feb 6 00:52:12 partman-crypto: Failed to setup dm-crypt key mapping for device /dev/sda5.
Feb 6 00:52:12 partman-crypto: Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
Feb 6 00:52:12 partman-crypto: Failed to write to key storage.

Which for the kubuntu kernel Linux version 3.2.0-58-generic (buildd@allspice) it appears to not be available at the install time.

Based on above i presume flavors that use hwe kernels are not affected.

[Dimitri John Ledkov (xnox)]

So it appears that whilst xts.ko is present in the image-modules with the 3.2 kernel, it's not part of the crypto-modules-udeb for 3.2 based kernels and thus is not present on images that use 3.2 crypto-modules-udeb.

So the following combinations work:
boot hwe stack kernels, yet install 3.2 or any hwe kernel onto the target system encrypted with xts by default

The following combination does not work:
boot 3.2 stack kernel, and install encrypted 3.2 or any hwe kernel onto the target system encrypted with xts by default.

Release note workaround:
Using manual partitioning manually specify previous default IV initialisation vector aes-cbc.

Possibly we could specify that in the default preseed.

I would not want to revert partman-crypto change from using xts back to aes-cbc by default.

Ideally i'd like 3.2 crypto-udeb to contain xts.ko module. Adding linux package bug task. As then this bug would be properly resolved for 3.2 booted d-i.

Release team, please advice on further action.

[Dimitri John Ledkov (xnox)]

performing manual crypto installation works if one changes IV algorithm to cbc-essiv:sha256

[Leonardo Borda (lborda)]

Hi Andy,

Could you please tell me which patch has been committed to Ubuntu precise?

lborda

[Dimitri John Ledkov (xnox)]

I believe the relevant commit for this bug report is here:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commitdiff;h=6e04e48078b50cb0ffbdb7a01d9b8c10b0064d1c

From 6e04e48078b50cb0ffbdb7a01d9b8c10b0064d1c Mon Sep 17 00:00:00 2001
From: Andy Whitcroft <email address hidden>
Date: Thu, 6 Feb 2014 10:37:54 +0000
Subject: [PATCH] UBUNTU: [Config] d-i -- add xts.ko to crypto-modules udeb

BugLink: http://bugs.launchpad.net/bugs/1276739

Signed-off-by: Andy Whitcroft <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
---
 debian.master/d-i/modules/crypto-modules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian.master/d-i/modules/crypto-modules b/debian.master/d-i/modules/crypto-modules
index b2f623a..1c3df90 100644
--- a/debian.master/d-i/modules/crypto-modules
+++ b/debian.master/d-i/modules/crypto-modules
@@ -6,3 +6,4 @@ sha256_generic ?
 cbc ?
 ecb ?
 crc32c ?
+xts ?
--
1.7.9.5

[Dimitri John Ledkov (xnox)]

Closing partman-crypto task, as nothing to do here. Related SRU upload bug is bug #1263740 which caused this issue to appear on d-i based installation media with original 12.04.0 kernel stacks.

partman-crypto (50ubuntu2) precise; urgency=medium

  * Backport support for, and use by default, xts-plain64. (LP: #1263740) (closes: #482092)
    - Double key size if xts mode is selected.
 -- Dimitri John Ledkov <email address hidden> Wed, 22 Jan 2014 12:25:11 +0000

[Dave Chiluk (chiluk)]

So has a new 12.04.4 cd image been spun with the fix for this?

[Brad Figg (brad-figg)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-precise' to 'verification-done-precise'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.2.0-60.91

---------------
linux (3.2.0-60.91) precise; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1281800

  [ Andy Whitcroft ]

  * [Config] d-i -- add xts.ko to crypto-modules udeb
    - LP: #1276739

  [ Upstream Kernel Changes ]

  * ath9k_htc: properly set MAC address and BSSID mask
    - LP: #1252422
    - CVE-2013-4579
  * SELinux: Fix kernel BUG on empty security contexts.
    - CVE-2014-1874
  * net: do not pretend FRAGLIST support
    - LP: #1281620
  * rds: prevent BUG_ON triggered on congestion update to loopback
    - LP: #1281620
  * ipv6: don't count addrconf generated routes against gc limit
    - LP: #1281620
  * net: drop_monitor: fix the value of maxattr
    - LP: #1281620
  * tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0
    - LP: #1281620
  * net: unix: allow bind to fail on mutex lock
    - LP: #1281620
  * net: inet_diag: zero out uninitialized idiag_{src,dst} fields
    - LP: #1281620
  * drivers/net/hamradio: Integer overflow in hdlcdrv_ioctl()
    - LP: #1281620
  * hamradio/yam: fix info leak in ioctl
    - LP: #1281620
  * rds: prevent dereference of a NULL device
    - LP: #1281620
  * net: rose: restore old recvmsg behavior
    - LP: #1281620
  * vlan: Fix header ops passthru when doing TX VLAN offload.
    - LP: #1281620
  * net: llc: fix use after free in llc_ui_recvmsg
    - LP: #1281620
  * bridge: use spin_lock_bh() in br_multicast_set_hash_max
    - LP: #1281620
  * bnx2x: fix DMA unmapping of TSO split BDs
    - LP: #1281620
  * inet_diag: fix inet_diag_dump_icsk() timewait socket state logic
    - LP: #1281620
  * net: avoid reference counter overflows on fib_rules in multicast
    forwarding
    - LP: #1281620
  * xfs: Account log unmount transaction correctly
    - LP: #1281620
  * PCI: Enable ARI if dev and upstream bridge support it; disable
    otherwise
    - LP: #1281620
  * mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate
    successfully
    - LP: #1281620
  * staging: comedi: cb_pcidio: fix for newer PCI-DIO48H
    - LP: #1281620
  * Fix warning from machine_kexec.c
    - LP: #1281620
  * hpfs: fix warnings when the filesystem fills up
    - LP: #1281620
  * KVM: x86: Convert vapic synchronization to _cached functions
    (CVE-2013-6368)
    - LP: #1281620
  * x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround
    - LP: #1281620
  * mm: ensure get_unmapped_area() returns higher address than
    mmap_min_addr
    - LP: #1281620
  * ceph: cleanup aborted requests when re-sending requests.
    - LP: #1281620
  * ceph: wake up 'safe' waiters when unregistering request
    - LP: #1281620
  * sh: always link in helper functions extracted from libgcc
    - LP: #1281620
  * libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus
    SpinPoint M8
    - LP: #1281620
  * ext4: call ext4_error_inode() if jbd2_journal_dirty_metadata() fails
    - LP: #1281620
  * ext4: fix use-after-free in ext4_mb_new_blocks
    - LP: #1281620
  * ext4: check for overlapping extents in ext4_valid_extent_entries()
    - LP: #1281620
  * ext2: Fix oops in ext2_get_block() called from ext2_quota_write()
    - LP...

[Dimitri John Ledkov (xnox)]

debian-installer rebuild against 3.2.0-60 is in precise-proposed unapproved queue.

[Dimitri John Ledkov (xnox)]

debian-installer (20101020ubuntu136.16) precise; urgency=medium

  * Move master kernels to 3.2.0-60.
  * Move armadaxp kernels to 3.2.0-1631.
  * Move ti-omap4 kernels to 3.2.0-1444.
  * Move lts-quantal kernels to 3.5.0-47.
  * Move lts-raring kernels to 3.8.0-37.
  * Move lts-saucy kernels to 3.11.0-18.
 -- Dimitri John Ledkov <email address hidden> Fri, 07 Mar 2014 10:52:20 +0000

[markling (markling)]

This bug appears to be a problem with Xubuntu AMD64 12.04.4 Alternate.

I have been prevented using this disk to rescue an encrypted LVM system because, it says, "reload ioctl failed...failed to setup dm-crypt key mapping for device... check that kernel supports aes-xts-plain64 cipher".

The system was setup using default Xubuntu installer options for encrypted LVM (can't remember which version but it was recent and it worked).

The rescue has become necessary because kernel -29 update failed due to /root partition becoming full. Kernel update failure consisted of a disk full error before the kernel extras image could be installed. USB Keyboard therefore fails when system asks for encryption password.

The problem would be resolved for common users if the system detected its problem and provided a 'Dummy's' option to resize the partition, with an intelligent guess proffered as the new size.

Rescue of this situation is like venturing into a foggy swamp. Before you even get to attempt the resize operation, the Xubuntu rescue disk is not loaded with the same cipher that it had originally used to setup the encrypted volume.

The DebianLive AMD64 7.5.0 Rescue CD failed as well. It seems to be incapable of recognizing a non-US keyboard, which makes entering an encryption password setup on an English keyboard quite unlikely (unless its a Mickey Mouse password that uses only standard numbers and letters). It is very unlikely a common user will detect this fact from using the live CD. The experience of attempting this operation will therefore be deeply frustrating and ultimately unsuccessful.

The solution now appears to be to keep downloading rescue disks until one works.

[markling (markling)]

GParted Live CD doesn't appear to be able to help either - no facility to work on encrypted partitions: http://gparted.org/features.php