Debian Bug report logs - #541835
cryptsetup: unclear kernel requirements

version graph

Package: cryptsetup; Maintainer for cryptsetup is Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>; Source for cryptsetup is src:cryptsetup.

Reported by: Celejar <celejar@gmail.com>

Date: Sun, 16 Aug 2009 15:42:02 UTC

Severity: normal

Found in version cryptsetup/2:1.0.7-1

Fixed in version cryptsetup/2:1.0.7-2

Done: Jonas Meurer <mejo@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Sun, 16 Aug 2009 15:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Celejar <celejar@gmail.com>:
New Bug report received and forwarded. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Sun, 16 Aug 2009 15:42:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Celejar <celejar@gmail.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: cryptsetup: unclear kernel requirements
Date: Sun, 16 Aug 2009 11:34:24 -0400
Package: cryptsetup
Version: 2:1.0.7-1
Severity: normal


This is not really a bug, but it's at least a request for better documentation.

I have a standard LUKS volume (created by the Debian installer), using
aes-cbc-essiv:sha_256.  While stock Debian kernels as well as ones that I build
based on the stock config handle it fine, my 'lean' kernel configurations
choke as follows:

table:254:0:	error allocating crypto tfm
ioctl:		error adding target to table
ioctl:		device doesn't appear to be in the dev hash table
Command failed: failed to setup dm-crypt key mapping for device /dev/hda4
Check that kernel supports aes-cbc-essiv:sha_256 cipher

I have googled extensively, and this message apparently usually indicates that
kernel support for the appropriate cipher / hash is not available, but I've
checked, double-checked, and racked my brains to figure out what I could
possibly be missing, to no avail.  aes_generic.ko, cbc.ko, crypto_blkcipher.ko,
sha256_generic.ko, dm-crypt.ko, dm-mod.ko are all there.

I've obviously disabled something that cryptsetup needs, but what?  Google
turns up nothing current and useful.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.31-rc6 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cryptsetup depends on:
ii  dmsetup                      2:1.02.30-3 The Linux Kernel Device Mapper use
ii  libc6                        2.9-24      GNU C Library: Shared libraries
ii  libdevmapper1.02.1           2:1.02.30-3 The Linux Kernel Device Mapper use
ii  libpopt0                     1.14-4      lib for parsing cmdline parameters
ii  libuuid1                     2.16-3      Universally Unique ID library

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
pn  dosfstools                    <none>     (no description available)
ii  initramfs-tools [linux-initra 0.93.4     tools for generating an initramfs
ii  udev                          0.141-1    /dev/ and hotplug management daemo

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Sun, 16 Aug 2009 18:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Sun, 16 Aug 2009 18:48:07 GMT) Full text and rfc822 format available.

Message #10 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Celejar <celejar@gmail.com>, 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Sun, 16 Aug 2009 20:40:41 +0200
[Message part 1 (text/plain, inline)]
hello,

On 16/08/2009 Celejar wrote:
> This is not really a bug, but it's at least a request for better documentation.
> 
> I have a standard LUKS volume (created by the Debian installer), using
> aes-cbc-essiv:sha_256.  While stock Debian kernels as well as ones that I build
> based on the stock config handle it fine, my 'lean' kernel configurations
> choke as follows:
> 
> table:254:0:	error allocating crypto tfm
> ioctl:		error adding target to table
> ioctl:		device doesn't appear to be in the dev hash table
> Command failed: failed to setup dm-crypt key mapping for device /dev/hda4
> Check that kernel supports aes-cbc-essiv:sha_256 cipher
> 
> I have googled extensively, and this message apparently usually indicates that
> kernel support for the appropriate cipher / hash is not available, but I've
> checked, double-checked, and racked my brains to figure out what I could
> possibly be missing, to no avail.  aes_generic.ko, cbc.ko, crypto_blkcipher.ko,
> sha256_generic.ko, dm-crypt.ko, dm-mod.ko are all there.
> 
> I've obviously disabled something that cryptsetup needs, but what?  Google
> turns up nothing current and useful.

please paste the output of the following commands:
# cryptsetup luksDump /dev/hda4
# dmsetup targets
# lsmod
# cat /proc/crypto

greetings,
 jonas
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Sun, 16 Aug 2009 21:00:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Celejar <celejar@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Sun, 16 Aug 2009 21:00:07 GMT) Full text and rfc822 format available.

Message #15 received at 541835@bugs.debian.org (full text, mbox):

From: Celejar <celejar@gmail.com>
To: Jonas Meurer <jonas@freesources.org>
Cc: 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Sun, 16 Aug 2009 16:53:53 -0400
On Sun, 16 Aug 2009 20:40:41 +0200
Jonas Meurer <jonas@freesources.org> wrote:

...

> please paste the output of the following commands:
> # cryptsetup luksDump /dev/hda4

~# cryptsetup luksDump /dev/hda4

LUKS header information for /dev/hda4

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
MK bits:       	256
MK digest:     	c8 9f 7f 46 ae e7 47 9d 70 22 1d 66 21 67 93 45 b0 13 0e 35 
MK salt:       	94 6e bc 69 88 a2 d5 e4 b0 01 f3 1e 61 7c 07 db 
               	8b 93 f3 c3 df ff 86 a1 e2 ca 56 65 6f 04 e8 db 
MK iterations: 	10
UUID:          	6c6eabf0-f0c3-4cab-b61d-75ed2248e1c5

Key Slot 0: ENABLED
	Iterations:         	151612
	Salt:               	99 81 f8 fc 3f 7d 24 af 9d f5 9c 7e 60 ef 18 bf 
	                      	d2 59 f6 50 8b 69 d3 3e f8 87 4a 5c c4 0f 77 45 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

> # dmsetup targets

~# dmsetup targets
mirror           v1.12.0
snapshot-origin  v1.6.0
snapshot         v1.6.0
crypt            v1.7.0
striped          v1.2.0
linear           v1.1.0
error            v1.0.1

> # lsmod

~$ lsmod
Module                  Size  Used by
i915                  181644  1 
drm                   136932  2 i915
i2c_algo_bit            4812  1 i915
ip6table_filter         3028  1 
ip6_tables             11316  1 ip6table_filter
xt_time                 2264  0 
xt_connlimit            3484  0 
xt_realm                1216  0 
iptable_raw             2248  0 
xt_comment              1232  20 
xt_policy               2472  0 
ipt_ULOG                6548  0 
ipt_REJECT              2448  2 
ipt_REDIRECT            1432  0 
ipt_NETMAP              1452  0 
ipt_MASQUERADE          2108  0 
ipt_LOG                 4500  21 
ipt_ECN                 2016  0 
ipt_ecn                 1564  0 
ipt_CLUSTERIP           5608  0 
ipt_ah                  1344  0 
ipt_addrtype            2000  4 
nf_nat_tftp             1276  0 
nf_nat_snmp_basic       7648  0 
nf_nat_sip              5400  0 
nf_nat_pptp             2520  0 
nf_nat_proto_gre        1884  1 nf_nat_pptp
nf_nat_irc              1788  0 
nf_nat_h323             5356  0 
nf_nat_ftp              2244  0 
nf_nat_amanda           1532  0 
ts_kmp                  1832  5 
nf_conntrack_amanda     3512  1 nf_nat_amanda
nf_conntrack_sane       4080  0 
nf_conntrack_tftp       3876  1 nf_nat_tftp
nf_conntrack_sip       15680  1 nf_nat_sip
nf_conntrack_proto_sctp     6288  0 
nf_conntrack_pptp       5420  1 nf_nat_pptp
nf_conntrack_proto_gre     4772  1 nf_conntrack_pptp
nf_conntrack_netlink    13964  0 
nf_conntrack_netbios_ns     2020  0 
nf_conntrack_irc        4820  1 nf_nat_irc
nf_conntrack_h323      43004  1 nf_nat_h323
nf_conntrack_ftp        6240  1 nf_nat_ftp
xt_tcpmss               1652  0 
xt_recent               7648  0 
xt_pkttype              1316  0 
xt_physdev              1936  0 
xt_owner                2132  0 
xt_NFQUEUE              2332  0 
xt_NFLOG                1384  0 
nfnetlink_log           7964  1 xt_NFLOG
xt_multiport            2448  4 
xt_MARK                 1732  0 
xt_mark                 1424  0 
xt_mac                  1300  0 
xt_limit                1980  0 
xt_length               1432  0 
xt_iprange              1928  0 
xt_helper               1684  0 
xt_hashlimit            8084  0 
xt_DSCP                 2612  0 
xt_dscp                 1992  0 
xt_dccp                 2408  0 
xt_conntrack            3664  0 
xt_CONNMARK             2324  0 
xt_connmark             1848  0 
xt_CLASSIFY             1272  0 
xt_tcpudp               2464  27 
xt_state                1724  34 
iptable_nat             4880  0 
nf_nat                 15572  12 ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_proto_gre,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,iptable_nat
nf_conntrack_ipv4      11560  37 iptable_nat,nf_nat
nf_defrag_ipv4          1612  1 nf_conntrack_ipv4
nf_conntrack           58460  31 xt_connlimit,ipt_MASQUERADE,ipt_CLUSTERIP,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_conntrack_amanda,nf_conntrack_sane,nf_conntrack_tftp,nf_conntrack_sip,nf_conntrack_proto_sctp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp,xt_helper,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
iptable_mangle          3212  1 
nfnetlink               4284  2 nf_conntrack_netlink,nfnetlink_log
iptable_filter          2904  1 
ip_tables              10156  4 iptable_raw,iptable_nat,iptable_mangle,iptable_filter
x_tables               14492  44 ip6_tables,xt_time,xt_connlimit,xt_realm,xt_comment,xt_policy,ipt_ULOG,ipt_REJECT,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ipt_LOG,ipt_ECN,ipt_ecn,ipt_CLUSTERIP,ipt_ah,ipt_addrtype,xt_tcpmss,xt_recent,xt_pkttype,xt_physdev,xt_owner,xt_NFQUEUE,xt_NFLOG,xt_multiport,xt_MARK,xt_mark,xt_mac,xt_limit,xt_length,xt_iprange,xt_helper,xt_hashlimit,xt_DSCP,xt_dscp,xt_dccp,xt_conntrack,xt_CONNMARK,xt_connmark,xt_CLASSIFY,xt_tcpudp,xt_state,iptable_nat,ip_tables
loop                   13212  0 
arc4                    1528  2 
ecb                     2336  2 
b43                   107012  0 
mac80211              120656  1 b43
snd_hda_codec_realtek   183864  1 
snd_hda_intel          22900  0 
snd_hda_codec          64036  2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep               6120  1 snd_hda_codec
snd_pcm                63028  2 snd_hda_intel,snd_hda_codec
snd_seq                41820  0 
snd_timer              17432  2 snd_pcm,snd_seq
snd_seq_device          6084  1 snd_seq
snd                    47300  8 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device
soundcore               6248  1 snd
i2c_i801                8504  0 
yenta_socket           21120  1 
cfg80211               76228  2 b43,mac80211
joydev                  8532  0 
acer_wmi               14476  0 
rfkill                 16232  2 cfg80211,acer_wmi
rsrc_nonstatic          9608  1 yenta_socket
psmouse                37468  0 
snd_page_alloc          7960  2 snd_hda_intel,snd_pcm
serio_raw               4560  0 
rng_core                3648  1 b43
i2c_core               19796  4 i915,drm,i2c_algo_bit,i2c_i801
pcspkr                  2148  0 
wmi                     6156  1 acer_wmi
evdev                   8056  18 
container               3204  0 
ac                      2808  0 
processor              34164  1 
battery                 5788  0 
button                  5028  0 
ext3                  105116  6 
jbd                    40736  1 ext3
mbcache                 6832  1 ext3
sha256_generic         11160  0 
sd_mod                 28688  2 
crc_t10dif              1588  1 sd_mod
usbhid                 31332  0 
hid                    34312  1 usbhid
dm_mirror              12064  0 
dm_region_hash         10108  1 dm_mirror
dm_log                  8268  2 dm_mirror,dm_region_hash
dm_snapshot            19032  0 
ide_cd_mod             23908  0 
ide_gd_mod             19812  3 
cdrom                  30292  1 ide_cd_mod
ata_generic             4300  0 
ata_piix               22004  0 
libata                150704  2 ata_generic,ata_piix
ide_pci_generic         3580  0 
usb_storage            48476  1 
scsi_mod              132236  3 sd_mod,libata,usb_storage
b44                    21776  0 
uhci_hcd               18968  0 
sdhci_pci               6560  0 
sdhci                  15124  1 sdhci_pci
piix                    5724  2 
ssb                    37048  2 b43,b44
ehci_hcd               29684  0 
mmc_core               45056  1 sdhci
led_class               3808  3 b43,acer_wmi,sdhci
pcmcia                 23996  2 b43,ssb
pcmcia_core            31012  5 b43,yenta_socket,rsrc_nonstatic,ssb,pcmcia
mii                     4656  1 b44
ide_core               88120  4 ide_cd_mod,ide_gd_mod,ide_pci_generic,piix
usbcore               127944  5 usbhid,usb_storage,uhci_hcd,ehci_hcd
nls_base                6688  1 usbcore
intel_agp              23148  1 
agpgart                30604  3 drm,intel_agp
video                  18244  1 i915
output                  2572  1 video
thermal                12544  0 
fan                     4016  0 
thermal_sys            13096  4 processor,video,thermal,fan
cbc                     2980  2 
aes_generic            27388  4 
dm_crypt               10856  2 
dm_mod                 55860  34 dm_mirror,dm_log,dm_snapshot,dm_crypt

> # cat /proc/crypto

~$ cat /proc/crypto
name         : ecb(arc4)
driver       : ecb(arc4-generic)
module       : ecb
priority     : 0
refcnt       : 3
selftest     : passed
type         : blkcipher
blocksize    : 1
min keysize  : 1
max keysize  : 256
ivsize       : 0
geniv        : <default>

name         : arc4
driver       : arc4-generic
module       : arc4
priority     : 0
refcnt       : 3
selftest     : passed
type         : cipher
blocksize    : 1
min keysize  : 1
max keysize  : 256

name         : sha256
driver       : sha256-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 32
descsize     : 168

name         : sha224
driver       : sha224-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 28
descsize     : 168

name         : cbc(aes)
driver       : cbc(aes-generic)
module       : kernel
priority     : 100
refcnt       : 3
selftest     : passed
type         : givcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : chainiv

name         : cbc(aes)
driver       : cbc(aes-generic)
module       : cbc
priority     : 100
refcnt       : 3
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 5
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : stdrng
driver       : krng
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
type         : rng
seedsize     : 0

name         : md5
driver       : md5-generic
module       : kernel
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 16
descsize     : 88

Note: these are from a kernel that handles the LUKS volume successfully
(2.6.31-rc6 from mainline git repo).  Getting the output from one of my
non-working kernels would be more difficult, since the entire system
(except /boot) is on LVM on top of the LUKS volume, and my kernels'
fail during the initrds' (made by initramfs-tools) attempts to unlock
the LUKS volume.  I have tried to explore the problem using the
'break=mount' kernel parameter, but even after manually modprobing the
aes, cbc, blkcipher, dm-crypt modules, the kernel can't unlock the
volume.

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Sun, 16 Aug 2009 21:24:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Sun, 16 Aug 2009 21:24:14 GMT) Full text and rfc822 format available.

Message #20 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Celejar <celejar@gmail.com>
Cc: 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Sun, 16 Aug 2009 23:10:58 +0200
[Message part 1 (text/plain, inline)]
hey,

On 16/08/2009 Celejar wrote:
> ~# cryptsetup luksDump /dev/hda4
> 
> LUKS header information for /dev/hda4
> 
> Version:       	1
> Cipher name:   	aes
> Cipher mode:   	cbc-essiv:sha256

so you at least need aes, cbc and sha256 kernel modules.

> > # dmsetup targets
> > # lsmod
> > # cat /proc/crypto

the output of these commands would only be interesting when running the
kernel that causes cryptsetup to fail.

> Note: these are from a kernel that handles the LUKS volume successfully
> (2.6.31-rc6 from mainline git repo).  Getting the output from one of my
> non-working kernels would be more difficult, since the entire system
> (except /boot) is on LVM on top of the LUKS volume, and my kernels'
> fail during the initrds' (made by initramfs-tools) attempts to unlock
> the LUKS volume.  I have tried to explore the problem using the
> 'break=mount' kernel parameter, but even after manually modprobing the
> aes, cbc, blkcipher, dm-crypt modules, the kernel can't unlock the
> volume.

all of the above programs (cryptsetup, dmsetup, lsmod and cat) should be
available within the initramfs, so executing them from the emergency
shell shouldn't be a problem. you could pipe them into some file on
/boot after mounting it.

greetings,
 jonas
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Sun, 16 Aug 2009 21:36:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Celejar <celejar@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Sun, 16 Aug 2009 21:36:08 GMT) Full text and rfc822 format available.

Message #25 received at 541835@bugs.debian.org (full text, mbox):

From: Celejar <celejar@gmail.com>
To: Jonas Meurer <jonas@freesources.org>
Cc: 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Sun, 16 Aug 2009 17:29:49 -0400
On Sun, 16 Aug 2009 23:10:58 +0200
Jonas Meurer <jonas@freesources.org> wrote:

> hey,
> 
> On 16/08/2009 Celejar wrote:
> > ~# cryptsetup luksDump /dev/hda4
> > 
> > LUKS header information for /dev/hda4
> > 
> > Version:       	1
> > Cipher name:   	aes
> > Cipher mode:   	cbc-essiv:sha256
> 
> so you at least need aes, cbc and sha256 kernel modules.

From a bad kernel:

> > > # dmsetup targets

~$ cat /boot/dmsetup-targets 
crypt            v1.7.0
striped          v1.2.0
linear           v1.1.0
error            v1.0.1

> > > # lsmod

lsmod isn't available in the initrd.  I could try adding it and
rebuilding if necessary, but my attempts to repackage initrd's are
often incorrect.

> > > # cat /proc/crypto

~$ cat /boot/proc-crypto 
name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

So it seems that cbc and sha256 are indeed not being properly loaded.
But this was after I had manually modprobed cbc.ko and
sha256_generic.ko (without error).  Any way to figure out why they
aren't being properly loaded?

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Sun, 16 Aug 2009 21:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Sun, 16 Aug 2009 21:48:04 GMT) Full text and rfc822 format available.

Message #30 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Celejar <celejar@gmail.com>
Cc: 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Sun, 16 Aug 2009 23:44:44 +0200
[Message part 1 (text/plain, inline)]
On 16/08/2009 Celejar wrote:
> On Sun, 16 Aug 2009 23:10:58 +0200
> Jonas Meurer <jonas@freesources.org> wrote:
> > so you at least need aes, cbc and sha256 kernel modules.
> 
> ~$ cat /boot/proc-crypto 
> name         : aes
> driver       : aes-generic
> module       : aes_generic
> priority     : 100
> refcnt       : 1
> selftest     : passed
> type         : cipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> 
> So it seems that cbc and sha256 are indeed not being properly loaded.
> But this was after I had manually modprobed cbc.ko and
> sha256_generic.ko (without error).  Any way to figure out why they
> aren't being properly loaded?

i don't know, but maybe the modprobe in initramfs is a striped down
version that doesn't print out errors if the modules don't exist.

how exactly did you try to load cbc and sha256? because you need to give
the module name as argument, not the filename (i.e. modprobe cbc, not
modprobe cbc.ko).

if everything is setup properly, the cryptroot initramfs script should
load required modules automaticly anyway, so i guess that your selfbuild
kernel simply doesn't have cbc and sha256 modules compiled.

greetings,
 jonas
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Mon, 17 Aug 2009 02:36:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Celejar <celejar@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Mon, 17 Aug 2009 02:36:06 GMT) Full text and rfc822 format available.

Message #35 received at 541835@bugs.debian.org (full text, mbox):

From: Celejar <celejar@gmail.com>
To: Jonas Meurer <jonas@freesources.org>
Cc: 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Sun, 16 Aug 2009 22:34:12 -0400
On Sun, 16 Aug 2009 23:44:44 +0200
Jonas Meurer <jonas@freesources.org> wrote:

> On 16/08/2009 Celejar wrote:
> > On Sun, 16 Aug 2009 23:10:58 +0200
> > Jonas Meurer <jonas@freesources.org> wrote:
> > > so you at least need aes, cbc and sha256 kernel modules.
> > 
> > ~$ cat /boot/proc-crypto 
> > name         : aes
> > driver       : aes-generic
> > module       : aes_generic
> > priority     : 100
> > refcnt       : 1
> > selftest     : passed
> > type         : cipher
> > blocksize    : 16
> > min keysize  : 16
> > max keysize  : 32
> > 
> > So it seems that cbc and sha256 are indeed not being properly loaded.
> > But this was after I had manually modprobed cbc.ko and
> > sha256_generic.ko (without error).  Any way to figure out why they
> > aren't being properly loaded?
> 
> i don't know, but maybe the modprobe in initramfs is a striped down
> version that doesn't print out errors if the modules don't exist.

Right you are; I experimented, and modprobe doesn't complain no matter
what I tell it to load - it just fails silently.

> how exactly did you try to load cbc and sha256? because you need to give
> the module name as argument, not the filename (i.e. modprobe cbc, not
> modprobe cbc.ko).

Yup, I was doing this wrong.  But after modprobing correctly, the best
I could get was this:

~$ cat /boot/proc-crypto-iii
name         : sha256
driver       : sha256-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 32
descsize     : 168

name         : sha224
driver       : sha224-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 28
descsize     : 168

name         : aes
driver       : aes-asm
module       : aes_i586
priority     : 200
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

So cbc will not load, no matter what I try.  Any idea what the problem
could be?

> if everything is setup properly, the cryptroot initramfs script should
> load required modules automaticly anyway, so i guess that your selfbuild
> kernel simply doesn't have cbc and sha256 modules compiled.

But they *are* - I see them under lib/modules/xxxx/kernel/crytpo:

aes_generic.ko  cbc.ko  crypto_algapi.ko  crypto_blkcipher.ko  crypto_hash.ko  sha256_generic.ko

So something is seriously messed up with my kernel / initramfs config -
sha256 needs to be manually loaded, and cbc refuses to load at all.
Any idea where to go from here?

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Mon, 17 Aug 2009 17:00:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Mon, 17 Aug 2009 17:00:15 GMT) Full text and rfc822 format available.

Message #40 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Celejar <celejar@gmail.com>
Cc: 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Mon, 17 Aug 2009 18:58:01 +0200
[Message part 1 (text/plain, inline)]
hello,

On 16/08/2009 Celejar wrote:
> On Sun, 16 Aug 2009 23:44:44 +0200
> Jonas Meurer <jonas@freesources.org> wrote:
> > i don't know, but maybe the modprobe in initramfs is a striped down
> > version that doesn't print out errors if the modules don't exist.
> 
> Right you are; I experimented, and modprobe doesn't complain no matter
> what I tell it to load - it just fails silently.
> 
> > how exactly did you try to load cbc and sha256? because you need to give
> > the module name as argument, not the filename (i.e. modprobe cbc, not
> > modprobe cbc.ko).
> 
> So cbc will not load, no matter what I try.  Any idea what the problem
> could be?
> 
> > if everything is setup properly, the cryptroot initramfs script should
> > load required modules automaticly anyway, so i guess that your selfbuild
> > kernel simply doesn't have cbc and sha256 modules compiled.
> 
> But they *are* - I see them under lib/modules/xxxx/kernel/crytpo:
> 
> aes_generic.ko  cbc.ko  crypto_algapi.ko  crypto_blkcipher.ko  crypto_hash.ko  sha256_generic.ko
> 
> So something is seriously messed up with my kernel / initramfs config -
> sha256 needs to be manually loaded, and cbc refuses to load at all.
> Any idea where to go from here?

seems like modprobe in initramfs is silent for non-existant modules even
with the -v (--verbose) commandline option. please check the following
commands and compare the output:

(initramfs) modprobe -vl cbc
kernel/crypto/cbc.ko

(initramfs) modprove -v cbc
insmod /lib/modules/2.6.30-1-amd64/kernel/crypto/cbc.ko

(initramfs) cat /proc/modules | grep cbc
cbc 3776 0 - Live 0xffffffffa015b000

and additionally please send me your kernel .config.

greetings,
 jonas
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Tue, 18 Aug 2009 02:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Celejar <celejar@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Tue, 18 Aug 2009 02:36:02 GMT) Full text and rfc822 format available.

Message #45 received at 541835@bugs.debian.org (full text, mbox):

From: Celejar <celejar@gmail.com>
To: Jonas Meurer <jonas@freesources.org>
Cc: 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Mon, 17 Aug 2009 22:32:19 -0400
[Message part 1 (text/plain, inline)]
On Mon, 17 Aug 2009 18:58:01 +0200
Jonas Meurer <jonas@freesources.org> wrote:

...

> seems like modprobe in initramfs is silent for non-existant modules even
> with the -v (--verbose) commandline option. please check the following
> commands and compare the output:
> 
> (initramfs) modprobe -vl cbc
> kernel/crypto/cbc.ko

That's what I get.
 
> (initramfs) modprove -v cbc

No output.

> insmod /lib/modules/2.6.30-1-amd64/kernel/crypto/cbc.ko

insmod: Error inserting 'xxxx': -1 File exists

[From memory - I didn't manage to redirect stderr properly.]

> (initramfs) cat /proc/modules | grep cbc
> cbc 3776 0 - Live 0xffffffffa015b000

cbc 3396 0 - Live 0xf80a6000
crypto_blkcipher 11976 2 cbc,dm_crypt, Live 0xf804c000
crypto_algapi 16072 3 cbc,aes_generic,crypto_blkcipher, Live 0xf801b000

> and additionally please send me your kernel .config.

Attached.

Thanks for bearing with me :/,
Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator

[config-2.6.31-rc6-lizzie-00042-gb2add73 (application/octet-stream, attachment)]

Reply sent to Jonas Meurer <jonas@freesources.org>:
You have taken responsibility. (Tue, 25 Aug 2009 21:27:16 GMT) Full text and rfc822 format available.

Notification sent to Celejar <celejar@gmail.com>:
Bug acknowledged by developer. (Tue, 25 Aug 2009 21:27:16 GMT) Full text and rfc822 format available.

Message #50 received at 541835-close@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Celejar <celejar@gmail.com>
Cc: 541835-close@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: cryptsetup: unclear kernel requirements
Date: Tue, 25 Aug 2009 23:11:54 +0200
[Message part 1 (text/plain, inline)]
hello,

On 17/08/2009 Celejar wrote:
> On Mon, 17 Aug 2009 18:58:01 +0200
> Jonas Meurer <jonas@freesources.org> wrote:
> > insmod /lib/modules/2.6.30-1-amd64/kernel/crypto/cbc.ko
> 
> insmod: Error inserting 'xxxx': -1 File exists
> 
> [From memory - I didn't manage to redirect stderr properly.]

that should do the trick:
insmod /lib/modules/2.6.30-1-amd64/kernel/crypto/cbc.ko >logfile 2>&1

> > and additionally please send me your kernel .config.
> 
> Attached.
> 
> Thanks for bearing with me :/,

it seems like your kernel config is broken. i rebuilt both 2.6.30
and 2.6.31-rc6 kernels with your config and was able to reproduce the
bug with both kernels. so this bug is not related to any kernel version
but rather to the kernel config.

indeed the behaviour is very strange: in the initramfs, all required
modules do exist (dm-mod, dm-crypt, crypto_blkcipher, crypto_algapi,
crypto_hash, aes_generic, sha256_generic), but for some reson after
loading all of them /proc/crypto lists only aes, sha256 and sha224, not
the cbc blockcipher.

i don't know what's wrong with your kernel but i guess that it's up to
you to find the actual issue. you might try to look at the default
debian kernel configuration for reference.

i close the bugreport with this mail as i'm pretty sure that the bug is
not related to the cryptsetup package in any way.

greetings,
 jonas
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Wed, 26 Aug 2009 00:00:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Celejar <celejar@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Wed, 26 Aug 2009 00:00:10 GMT) Full text and rfc822 format available.

Message #55 received at 541835@bugs.debian.org (full text, mbox):

From: Celejar <celejar@gmail.com>
To: lkml <linux-kernel@vger.kernel.org>
Cc: 541835@bugs.debian.org
Subject: crypto configuration / dependencies broken
Date: Tue, 25 Aug 2009 19:58:52 -0400
I'm having a pretty bizarre problem with my kernel crypto
configuration.  I need support for a bog standard LUKS (aes /
cbc-essiv:sha256) / cryptsetup installation, but even after I enable
virtually everything in the crypto section of the kernel configs, cbc
fails to load.  All the relevant modules are exist (dm-mod, dm-crypt,
crypto_blkcipher, crypto_algapi, crypto_hash, aes_generic,
sha256_generic), but even after modprobing / insmoding
everything, /proc/crypto shows that aes and sha is there, but not cbc.

The problem has been reproduced (using my kernel config) by Jonas
Meurer, the Debian cryptsetup maintainer, so it's not just me ;).
We've tried numerous different kernel versions in the .30 / .31 range.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835

Does this mean that something else somewhere in the kernel needs to be
configured but isn't, and the necessary dependency isn't properly
declared?

My config is at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=config-2.6.31-rc6-lizzie-00042-gb2add73;att=1;bug=541835

[I'm not subscribed to lkml; please cc me on responses]

Celejar
-- 
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Wed, 26 Aug 2009 11:37:00 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Wed, 26 Aug 2009 11:37:00 GMT) Full text and rfc822 format available.

Message #60 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Celejar <celejar@gmail.com>, 541835@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Wed, 26 Aug 2009 12:31:39 +0200
On 25/08/2009 Celejar wrote:
> I'm having a pretty bizarre problem with my kernel crypto
> configuration.  I need support for a bog standard LUKS (aes /
> cbc-essiv:sha256) / cryptsetup installation, but even after I enable
> virtually everything in the crypto section of the kernel configs, cbc
> fails to load.  All the relevant modules are exist (dm-mod, dm-crypt,
> crypto_blkcipher, crypto_algapi, crypto_hash, aes_generic,
> sha256_generic), but even after modprobing / insmoding
> everything, /proc/crypto shows that aes and sha is there, but not cbc.
> 
> The problem has been reproduced (using my kernel config) by Jonas
> Meurer, the Debian cryptsetup maintainer, so it's not just me ;).
> We've tried numerous different kernel versions in the .30 / .31 range.

i just built linux 2.6.29 kernel with your kernel config and it fails
the same way. so this problem is not limited to linux kernel 2.6.30+.

greetings,
 jonas




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Thu, 27 Aug 2009 17:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Randy Dunlap <randy.dunlap@oracle.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Thu, 27 Aug 2009 17:06:03 GMT) Full text and rfc822 format available.

Message #65 received at 541835@bugs.debian.org (full text, mbox):

From: Randy Dunlap <randy.dunlap@oracle.com>
To: Celejar <celejar@gmail.com>
Cc: lkml <linux-kernel@vger.kernel.org>, 541835@bugs.debian.org
Subject: Re: crypto configuration / dependencies broken
Date: Thu, 27 Aug 2009 09:55:16 -0700
On Tue, 25 Aug 2009 19:58:52 -0400 Celejar wrote:

> I'm having a pretty bizarre problem with my kernel crypto
> configuration.  I need support for a bog standard LUKS (aes /
> cbc-essiv:sha256) / cryptsetup installation, but even after I enable
> virtually everything in the crypto section of the kernel configs, cbc
> fails to load.  All the relevant modules are exist (dm-mod, dm-crypt,
> crypto_blkcipher, crypto_algapi, crypto_hash, aes_generic,
> sha256_generic), but even after modprobing / insmoding
> everything, /proc/crypto shows that aes and sha is there, but not cbc.
> 
> The problem has been reproduced (using my kernel config) by Jonas
> Meurer, the Debian cryptsetup maintainer, so it's not just me ;).
> We've tried numerous different kernel versions in the .30 / .31 range.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835
> 
> Does this mean that something else somewhere in the kernel needs to be
> configured but isn't, and the necessary dependency isn't properly
> declared?
> 
> My config is at:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=config-2.6.31-rc6-lizzie-00042-gb2add73;att=1;bug=541835
> 
> [I'm not subscribed to lkml; please cc me on responses]


You could try/test a patch that was just posted:
  http://lkml.org/lkml/2009/8/27/249


---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Thu, 27 Aug 2009 18:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Thu, 27 Aug 2009 18:39:05 GMT) Full text and rfc822 format available.

Message #70 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Randy Dunlap <randy.dunlap@oracle.com>, 541835@bugs.debian.org
Cc: Celejar <celejar@gmail.com>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Thu, 27 Aug 2009 20:35:01 +0200
[Message part 1 (text/plain, inline)]
hey,

On 27/08/2009 Randy Dunlap wrote:
> On Tue, 25 Aug 2009 19:58:52 -0400 Celejar wrote:
> 
> > I'm having a pretty bizarre problem with my kernel crypto
> > configuration.  I need support for a bog standard LUKS (aes /
> > cbc-essiv:sha256) / cryptsetup installation, but even after I enable
> > virtually everything in the crypto section of the kernel configs, cbc
> > fails to load.  All the relevant modules are exist (dm-mod, dm-crypt,
> > crypto_blkcipher, crypto_algapi, crypto_hash, aes_generic,
> > sha256_generic), but even after modprobing / insmoding
> > everything, /proc/crypto shows that aes and sha is there, but not cbc.
> > 
> > The problem has been reproduced (using my kernel config) by Jonas
> > Meurer, the Debian cryptsetup maintainer, so it's not just me ;).
> > We've tried numerous different kernel versions in the .30 / .31 range.
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835
> > 
> > Does this mean that something else somewhere in the kernel needs to be
> > configured but isn't, and the necessary dependency isn't properly
> > declared?
> > 
> > My config is at:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=config-2.6.31-rc6-lizzie-00042-gb2add73;att=1;bug=541835
> > 
> > [I'm not subscribed to lkml; please cc me on responses]
> 
> 
> You could try/test a patch that was just posted:
>   http://lkml.org/lkml/2009/8/27/249

that patch seems to be for ecryptfs only, while Celejar uses dm-crypt.
second, the patch just ensures that CRYPTO_ECB and CRYPTO_CBC are
selected along with ECRYPT_FS. but Celejar does have both CRYPTO_ECB and
CRYPTO_CBC selected.

the problem rather is that loading the cbc blockcipher module simply
does nothing. the module is listed in /proc/modules, but the blockcipher
is still missing from /proc/crypto.

the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
even though it has cbc compiled as module as well. but if I recompile
the same kernel sources with Celejars kernel .config, the problem
occurs. thus it must be related to the kernel config in some way.

greetings,
 jonas


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Thu, 27 Aug 2009 19:33:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Randy Dunlap <randy.dunlap@oracle.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Thu, 27 Aug 2009 19:33:09 GMT) Full text and rfc822 format available.

Message #75 received at 541835@bugs.debian.org (full text, mbox):

From: Randy Dunlap <randy.dunlap@oracle.com>
To: Jonas Meurer <jonas@freesources.org>
Cc: 541835@bugs.debian.org, Celejar <celejar@gmail.com>, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Thu, 27 Aug 2009 12:34:01 -0700
On Thu, 27 Aug 2009 20:35:01 +0200 Jonas Meurer wrote:

> hey,
> 
> On 27/08/2009 Randy Dunlap wrote:
> > On Tue, 25 Aug 2009 19:58:52 -0400 Celejar wrote:
> > 
> > > I'm having a pretty bizarre problem with my kernel crypto
> > > configuration.  I need support for a bog standard LUKS (aes /
> > > cbc-essiv:sha256) / cryptsetup installation, but even after I enable
> > > virtually everything in the crypto section of the kernel configs, cbc
> > > fails to load.  All the relevant modules are exist (dm-mod, dm-crypt,
> > > crypto_blkcipher, crypto_algapi, crypto_hash, aes_generic,
> > > sha256_generic), but even after modprobing / insmoding
> > > everything, /proc/crypto shows that aes and sha is there, but not cbc.
> > > 
> > > The problem has been reproduced (using my kernel config) by Jonas
> > > Meurer, the Debian cryptsetup maintainer, so it's not just me ;).
> > > We've tried numerous different kernel versions in the .30 / .31 range.
> > > 
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835
> > > 
> > > Does this mean that something else somewhere in the kernel needs to be
> > > configured but isn't, and the necessary dependency isn't properly
> > > declared?
> > > 
> > > My config is at:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=config-2.6.31-rc6-lizzie-00042-gb2add73;att=1;bug=541835
> > > 
> > > [I'm not subscribed to lkml; please cc me on responses]
> > 
> > 
> > You could try/test a patch that was just posted:
> >   http://lkml.org/lkml/2009/8/27/249
> 
> that patch seems to be for ecryptfs only, while Celejar uses dm-crypt.
> second, the patch just ensures that CRYPTO_ECB and CRYPTO_CBC are
> selected along with ECRYPT_FS. but Celejar does have both CRYPTO_ECB and
> CRYPTO_CBC selected.

ack.

> the problem rather is that loading the cbc blockcipher module simply
> does nothing. the module is listed in /proc/modules, but the blockcipher
> is still missing from /proc/crypto.
> 
> the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
> even though it has cbc compiled as module as well. but if I recompile
> the same kernel sources with Celejars kernel .config, the problem
> occurs. thus it must be related to the kernel config in some way.

add cc: linux-crypto@vger.kernel.org -- maybe someone there can help out.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Fri, 28 Aug 2009 08:09:54 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sebastian Andrzej Siewior <sebastian@breakpoint.cc>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Fri, 28 Aug 2009 08:09:54 GMT) Full text and rfc822 format available.

Message #80 received at 541835@bugs.debian.org (full text, mbox):

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Jonas Meurer <jonas@freesources.org>, 541835@bugs.debian.org, Celejar <celejar@gmail.com>, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Fri, 28 Aug 2009 10:00:56 +0200
* Randy Dunlap | 2009-08-27 12:34:01 [-0700]:

>> On 27/08/2009 Randy Dunlap wrote:
>> > On Tue, 25 Aug 2009 19:58:52 -0400 Celejar wrote:
>> > 
>> > > I'm having a pretty bizarre problem with my kernel crypto
>> > > configuration.  I need support for a bog standard LUKS (aes /
>> > > cbc-essiv:sha256) / cryptsetup installation, but even after I enable
>> > > virtually everything in the crypto section of the kernel configs, cbc
>> > > fails to load.  All the relevant modules are exist (dm-mod, dm-crypt,
>> > > crypto_blkcipher, crypto_algapi, crypto_hash, aes_generic,
>> > > sha256_generic), but even after modprobing / insmoding
>> > > everything, /proc/crypto shows that aes and sha is there, but not cbc.
>> > > 
>> > > The problem has been reproduced (using my kernel config) by Jonas
>> > > Meurer, the Debian cryptsetup maintainer, so it's not just me ;).
>> > > We've tried numerous different kernel versions in the .30 / .31 range.
>> > > 
>> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835
>> > > 
>> > > Does this mean that something else somewhere in the kernel needs to be
>> > > configured but isn't, and the necessary dependency isn't properly
>> > > declared?
>> > > 
>> > > My config is at:
>> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=config-2.6.31-rc6-lizzie-00042-gb2add73;att=1;bug=541835
>> > > 
>> > > [I'm not subscribed to lkml; please cc me on responses]
>> the problem rather is that loading the cbc blockcipher module simply
>> does nothing. the module is listed in /proc/modules, but the blockcipher
>> is still missing from /proc/crypto.
Yes. cbc(aes) is auto-generated once someone requests such a cipher. The
block modes are not listed.

>> the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
>> even though it has cbc compiled as module as well. but if I recompile
>> the same kernel sources with Celejars kernel .config, the problem
>> occurs. thus it must be related to the kernel config in some way.
It must be the kernel confing since I run .30.stable and it works. I try
to look at it later.

>---
>~Randy

Sebastian




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Sun, 30 Aug 2009 16:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sebastian Andrzej Siewior <sebastian@ml.breakpoint.cc>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Sun, 30 Aug 2009 16:00:04 GMT) Full text and rfc822 format available.

Message #85 received at 541835@bugs.debian.org (full text, mbox):

From: Sebastian Andrzej Siewior <sebastian@ml.breakpoint.cc>
To: Celejar <celejar@gmail.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>, Jonas Meurer <jonas@freesources.org>, 541835@bugs.debian.org, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Sun, 30 Aug 2009 17:37:22 +0200
* Sebastian Andrzej Siewior | 2009-08-28 10:00:56 [+0200]:

>>> the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
>>> even though it has cbc compiled as module as well. but if I recompile
>>> the same kernel sources with Celejars kernel .config, the problem
>>> occurs. thus it must be related to the kernel config in some way.
>It must be the kernel confing since I run .30.stable and it works. I try
>to look at it later.

Your kernel config is fine, the problem is that the initramfs tools do
not copy all of the required modules into the initramfs. The missing
modles are:
- cryptomgr: that one is responsible to load the cbc and aes module and
  bind them to cbc(aes)
- chainiv: that one creates IVs if the "user" does not specify one.
  dm-crypt probably does not use that one but is required due to the way
  crypto works atm.
- krng: provides random numbers and is required by chainiv.

If you add those three to /etc/initramfs/modules than it should work.

Could someone please look at initramfs to figure out why those three
modules are not copied in this reduced setup?

>Sebastian




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Mon, 31 Aug 2009 00:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Celejar <celejar@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Mon, 31 Aug 2009 00:09:04 GMT) Full text and rfc822 format available.

Message #90 received at 541835@bugs.debian.org (full text, mbox):

From: Celejar <celejar@gmail.com>
To: Sebastian Andrzej Siewior <sebastian@ml.breakpoint.cc>
Cc: Randy Dunlap <randy.dunlap@oracle.com>, Jonas Meurer <jonas@freesources.org>, 541835@bugs.debian.org, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Sun, 30 Aug 2009 20:06:56 -0400
On Sun, 30 Aug 2009 17:37:22 +0200
Sebastian Andrzej Siewior <sebastian@ml.breakpoint.cc> wrote:

> * Sebastian Andrzej Siewior | 2009-08-28 10:00:56 [+0200]:
> 
> >>> the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
> >>> even though it has cbc compiled as module as well. but if I recompile
> >>> the same kernel sources with Celejars kernel .config, the problem
> >>> occurs. thus it must be related to the kernel config in some way.
> >It must be the kernel confing since I run .30.stable and it works. I try
> >to look at it later.
> 
> Your kernel config is fine, the problem is that the initramfs tools do
> not copy all of the required modules into the initramfs. The missing
> modles are:
> - cryptomgr: that one is responsible to load the cbc and aes module and
>   bind them to cbc(aes)
> - chainiv: that one creates IVs if the "user" does not specify one.
>   dm-crypt probably does not use that one but is required due to the way
>   crypto works atm.
> - krng: provides random numbers and is required by chainiv.
> 
> If you add those three to /etc/initramfs/modules than it should work.

Right your are!  It now works, thanks very much.  I guess the catch was
that the working (stock Debian) kernel config built cryptomgr
(CRYPTO_MANAGER and CRYPTO_MANAGER2) and krng (CRYPTO_RNG2, although
not CRYPTO_RNG) and chainiv (CRYPTO_BLKCIPHER2, although not
CRYPTO_BLKCIPHER - I have the impression that chainiv is now
controlled by the BLKCIPHER options?) into the kernel, not as modules,
so I wasn't hit by the initramfs failure until I built them as modules
(I have a bit of a fetish for building everything as a module,
especially when using initrd's :/).

> Could someone please look at initramfs to figure out why those three
> modules are not copied in this reduced setup?

Celejar
-- 
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Mon, 31 Aug 2009 15:57:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Mon, 31 Aug 2009 15:57:08 GMT) Full text and rfc822 format available.

Message #95 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Sebastian Andrzej Siewior <sebastian@ml.breakpoint.cc>
Cc: Celejar <celejar@gmail.com>, Randy Dunlap <randy.dunlap@oracle.com>, 541835@bugs.debian.org, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Mon, 31 Aug 2009 17:52:00 +0200
hey,

On 30/08/2009 Sebastian Andrzej Siewior wrote:
> * Sebastian Andrzej Siewior | 2009-08-28 10:00:56 [+0200]:
> 
> >>> the problem is not reproducible with a debian/unstable 2.6.30.6 kernel,
> >>> even though it has cbc compiled as module as well. but if I recompile
> >>> the same kernel sources with Celejars kernel .config, the problem
> >>> occurs. thus it must be related to the kernel config in some way.
> >It must be the kernel confing since I run .30.stable and it works. I try
> >to look at it later.
> 
> Your kernel config is fine, the problem is that the initramfs tools do
> not copy all of the required modules into the initramfs. The missing
> modles are:
> - cryptomgr: that one is responsible to load the cbc and aes module and
>   bind them to cbc(aes)
> - chainiv: that one creates IVs if the "user" does not specify one.
>   dm-crypt probably does not use that one but is required due to the way
>   crypto works atm.
> - krng: provides random numbers and is required by chainiv.
> 
> If you add those three to /etc/initramfs/modules than it should work.
> 
> Could someone please look at initramfs to figure out why those three
> modules are not copied in this reduced setup?

the reason is simply that no other crypto modules define depends on the
listed ones:

# modinfo -F depends dm-crypt
dm-mod,crypto_blkcipher

# modinfo -F aes_generic sha256_generic cbc
crypto_algapi
crypto_hash
crypto_algapi,crypto_blkcipher

# modinfo -F crypto_blkcipher crypto_hash
crypto_algapi
crypto_algapi

and even the new modules don't depend on each other:

# modinfo -F cryptomgr
crypto_hash,crypto_algapi,crypto_blkcipher,aead,pcompress

# modinfo -F chainiv
crypto_algapi,rng,crypto_wq,crypto_blkcipher

# modinfo -F krng
rng,crypto_algapi

so the following depends should be added/changed:

- chainiv should depend o 'krng' instead of 'rng' at least
- maybe cipher modules like aes,serpent,... should depend on 'cryptomgr'
  instead of 'crypto_algapi'
- crypto_algapi should depend on chainiv

these changes are pure guesses, i don't know the details. but at least
additional depends need to be defined for crypto modules, don't you
think so?

greetings,
 jonas




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Mon, 31 Aug 2009 21:18:27 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sebastian Andrzej Siewior <sebastian@breakpoint.cc>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Mon, 31 Aug 2009 21:18:27 GMT) Full text and rfc822 format available.

Message #100 received at 541835@bugs.debian.org (full text, mbox):

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Jonas Meurer <jonas@freesources.org>
Cc: Celejar <celejar@gmail.com>, Randy Dunlap <randy.dunlap@oracle.com>, 541835@bugs.debian.org, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Mon, 31 Aug 2009 23:16:40 +0200
* Jonas Meurer | 2009-08-31 17:52:00 [+0200]:

>> Could someone please look at initramfs to figure out why those three
>> modules are not copied in this reduced setup?
>
>the reason is simply that no other crypto modules define depends on the
>listed ones:
Well yes, but aes cbc is placed in the new initrd. I took a look, read
below.

>so the following depends should be added/changed:
>
>- chainiv should depend o 'krng' instead of 'rng' at least
   rng is a subsubsystem within crypto. krng is one implementation which
   provides random numbers. So does ansi_cprng. Another implementation
   may come.
>- maybe cipher modules like aes,serpent,... should depend on 'cryptomgr'
>  instead of 'crypto_algapi'
   This isn't possible without dummy variables because they don't need
   each other in first place. We could move code but crypto_algapi can
   live without cryptomgr. However cryptomgr doesn't make sense without
   crypto_algapi.
   Lets say you have a VIA CPU which provides cbc(aes) in HW. So you
   don't need cryptomgr because cbc(aes) is allready available. You need
   aes_generic but that's another story :)

>- crypto_algapi should depend on chainiv
   chainiv is one possible implementation eseqiv is another one. The
   later is used on async-hw and in 2.6.32+ on SMP afaik.
   
>these changes are pure guesses, i don't know the details. but at least
>additional depends need to be defined for crypto modules, don't you
>think so?
We have them in Kconfig. All required modules are built and are
available. However the things aren't that easy. The crypto subsystem is
very flexible and undocumented and this is the problem here I think.
Another example:
The geode aes HW/driver can handle cbc(aes) requests as long as its
keysize is 128bits. Larger keys can't be handled by HW so we fallback to
the next implementation. If you just copy the geode module then the
geode module won't work because an alternative implementation is
missing.

So this brings me to the following question: Why are you so picky and you
don't take all of the modules? sh 2.6.30-1 on various debian archs:
du -sh              x86_64  i386  powerpc  s390x   mips(r5k-ip32)
crypto              720K    636K  1.1M     804K    968K
arch/<arch>/crypto  72K     36K   0        92K     0
driver/crypto       32K     60K   60K      0       52K
Total               824K    732K  1.2M     896K    1020

So all modules together have an average footprint of 941.0K. This isn't
that much. There is no size limit on initrd unless you are on a system
with has 32MiB or something like that :)
With *all* those crypto modules which are selected and built you are
able to cover all corner cases.
I took a look at hooks/cryptroot and really and only a few modules are
included. Right now you don't include HW cipher e.g. VIA's padlock or
AMD's geode. If you don't load those module while openning the root
partition (the first request), then the module is never loaded / used.
The other unhandled case are non default ciphers like xts(aes) which one
might use. The brand new aes implementation aesni-intel is also not be
considered. Most modules have _generic in their name if there is
another implementation available and <name>-arch if there is an assembly
variant but I would prefer that this does not become part of an ABI
where one can rely on.

Would it be okay for you to change the way the crypto modules are picked
and include the full set?

>greetings,
> jonas

Sebastian




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Tue, 01 Sep 2009 00:57:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonas Meurer <jonas@freesources.org>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Tue, 01 Sep 2009 00:57:12 GMT) Full text and rfc822 format available.

Message #105 received at 541835@bugs.debian.org (full text, mbox):

From: Jonas Meurer <jonas@freesources.org>
To: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Cc: Celejar <celejar@gmail.com>, Randy Dunlap <randy.dunlap@oracle.com>, 541835@bugs.debian.org, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org, control@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Tue, 1 Sep 2009 02:51:20 +0200
[Message part 1 (text/plain, inline)]
reopen 541835
thanks

hey,

On 31/08/2009 Sebastian Andrzej Siewior wrote:
> * Jonas Meurer | 2009-08-31 17:52:00 [+0200]:
> 
> >> Could someone please look at initramfs to figure out why those three
> >> modules are not copied in this reduced setup?
> >
> >the reason is simply that no other crypto modules define depends on the
> >listed ones:
> Well yes, but aes cbc is placed in the new initrd. I took a look, read
> below.

as you already discovered, that's because the initramfs hook script for
cryptroot adds some crypto modules manually in debian. currently these
are dm-mod, dm-crypt, cbc, aes, sha256 and all the modules they depend
on.

> >so the following depends should be added/changed:
> >
> >- chainiv should depend o 'krng' instead of 'rng' at least
>    rng is a subsubsystem within crypto. krng is one implementation which
>    provides random numbers. So does ansi_cprng. Another implementation
>    may come.
>
> >- maybe cipher modules like aes,serpent,... should depend on 'cryptomgr'
> >  instead of 'crypto_algapi'
>    This isn't possible without dummy variables because they don't need
>    each other in first place. We could move code but crypto_algapi can
>    live without cryptomgr. However cryptomgr doesn't make sense without
>    crypto_algapi.
>    Lets say you have a VIA CPU which provides cbc(aes) in HW. So you
>    don't need cryptomgr because cbc(aes) is allready available. You need
>    aes_generic but that's another story :)
> 
> >- crypto_algapi should depend on chainiv
>    chainiv is one possible implementation eseqiv is another one. The
>    later is used on async-hw and in 2.6.32+ on SMP afaik.
>    
> >these changes are pure guesses, i don't know the details. but at least
> >additional depends need to be defined for crypto modules, don't you
> >think so?
>
> We have them in Kconfig. All required modules are built and are
> available. However the things aren't that easy. The crypto subsystem is
> very flexible and undocumented and this is the problem here I think.

ok, i see the point that it's not enough to simply add some additional
dependencies in order to fix the problem. seems like an easy solution
doesn't exist.

> So this brings me to the following question: Why are you so picky and you
> don't take all of the modules? sh 2.6.30-1 on various debian archs:
> du -sh              x86_64  i386  powerpc  s390x   mips(r5k-ip32)
> crypto              720K    636K  1.1M     804K    968K
> arch/<arch>/crypto  72K     36K   0        92K     0
> driver/crypto       32K     60K   60K      0       52K
> Total               824K    732K  1.2M     896K    1020
> 
> So all modules together have an average footprint of 941.0K. This isn't
> that much. There is no size limit on initrd unless you are on a system
> with has 32MiB or something like that :)
> With *all* those crypto modules which are selected and built you are
> able to cover all corner cases.
> I took a look at hooks/cryptroot and really and only a few modules are
> included. Right now you don't include HW cipher e.g. VIA's padlock or
> AMD's geode. If you don't load those module while openning the root
> partition (the first request), then the module is never loaded / used.
> The other unhandled case are non default ciphers like xts(aes) which one
> might use. The brand new aes implementation aesni-intel is also not be
> considered. Most modules have _generic in their name if there is
> another implementation available and <name>-arch if there is an assembly
> variant but I would prefer that this does not become part of an ABI
> where one can rely on.
> 
> Would it be okay for you to change the way the crypto modules are picked
> and include the full set?

i don't like the idea to add _all_ crypto modules into the initramfs per
default. the size of crypto and arch/<arch>/crypto will keep on growing
for kernels which do have ship all available modules for ciphers and
implementations. i think that the initramfs should be a _minimal_
system, and detecting the required crypto modules should be possible.

alternative crypto cipher and blockcipher modules are already detected
if required, as information about these are available from the cryptroot
configuration (either luks header or cmdline options given to cryptsetup).

i added cryptomgr, chainiv and krng to the list of required modules in
/usr/share/initramfs-tools/hooks/cryptroot for now.

still i see the point that this solution has it's drawbacks. modules for
crypto hardware and cipher implementations not following the convention to
call modules <cipher>_generic and <cipher>-alias aren't detected by the
current system.

i guess the best solution would be to improve the module dependency
system. cipher meta-modules like 'aes' should depend on all available
implementations. same for ivciphers, hashs, rng implementations etc.

what do you think about it?

greetings,
 jonas
[signature.asc (application/pgp-signature, inline)]

Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 01 Sep 2009 00:57:15 GMT) Full text and rfc822 format available.

Reply sent to Jonas Meurer <mejo@debian.org>:
You have taken responsibility. (Tue, 01 Sep 2009 11:39:12 GMT) Full text and rfc822 format available.

Notification sent to Celejar <celejar@gmail.com>:
Bug acknowledged by developer. (Tue, 01 Sep 2009 11:39:12 GMT) Full text and rfc822 format available.

Message #112 received at 541835-close@bugs.debian.org (full text, mbox):

From: Jonas Meurer <mejo@debian.org>
To: 541835-close@bugs.debian.org
Subject: Bug#541835: fixed in cryptsetup 2:1.0.7-2
Date: Tue, 01 Sep 2009 11:17:22 +0000
Source: cryptsetup
Source-Version: 2:1.0.7-2

We believe that the bug you reported is fixed in the latest version of
cryptsetup, which is due to be installed in the Debian FTP archive:

cryptsetup-udeb_1.0.7-2_amd64.udeb
  to pool/main/c/cryptsetup/cryptsetup-udeb_1.0.7-2_amd64.udeb
cryptsetup_1.0.7-2.diff.gz
  to pool/main/c/cryptsetup/cryptsetup_1.0.7-2.diff.gz
cryptsetup_1.0.7-2.dsc
  to pool/main/c/cryptsetup/cryptsetup_1.0.7-2.dsc
cryptsetup_1.0.7-2_amd64.deb
  to pool/main/c/cryptsetup/cryptsetup_1.0.7-2_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 541835@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Meurer <mejo@debian.org> (supplier of updated cryptsetup package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 01 Sep 2009 12:38:02 +0200
Source: cryptsetup
Binary: cryptsetup cryptsetup-udeb
Architecture: source amd64
Version: 2:1.0.7-2
Distribution: unstable
Urgency: low
Maintainer: Jonas Meurer <mejo@debian.org>
Changed-By: Jonas Meurer <mejo@debian.org>
Description: 
 cryptsetup - configures encrypted block devices
 cryptsetup-udeb - configures encrypted block devices (udeb)
Closes: 432150 518266 539734 541344 541835
Changes: 
 cryptsetup (2:1.0.7-2) unstable; urgency=low
 .
   * add a paragraph to the cryptsetup manpage that mentions /proc/crypto as
     source for available crypto ciphers, modes, hashs, keysizes, etc.
     (closes: #518266)
   * fix luksformat to check for mkfs.$fs both in /sbin and /usr/sbin. thanks
     to Jon Dowland. (closes: #539734)
   * mention era eriksson as author of the typo fixes for manpage (submitted as
     bug #476624) in changelog of cryptsetup 2:1.0.6-3. (closes: #541344)
   * bump standards-version to 3.8.3. no changes needed.
   * add 04_no_stderr_success.patch, which adds an option to suppress success
     messages to stderr. don't apply the patch as this already has been fixed
     upstream in another way. next cryptsetup release will print the command
     successfull message to stdout only if opt_verbose is set.
   * add checkscripts blkid and un_blkid for the reason that vol_id will be
     removed from udev soon. advertise the new scripts at all places that
     mentioned vol_id or un_vol_id before.
   * add /usr/share/bug/cryptsetup which adds /proc/cmdline, /etc/crypttab,
     /etc/fstab and output of 'lsmod' to bugs against cryptsetup.
   * add debian/README.remote, which describes how to setup a cryptroot system
     with support for remote unlocking via ssh login into the initramfs. Thanks
     to debian@x.ray.net for writing it down.
   * update debian/copyright for current format from dep.debian.net/deps/dep5
   * add chainiv, cryptomgr and krng to standard list of modules in initramfs
     cryptroot hook. (closes: #541835)
   * add a section describing LUKS header backups and related security
     implications to README.Debian. a tool to automate this task should not be
     distributed at all. (closes: #432150)
Checksums-Sha1: 
 5bc50b6a6d732c85c125fe4f0a4e04821291a549 1486 cryptsetup_1.0.7-2.dsc
 56a491073270cfd6f31afe68fa7af7895ab23a8d 71180 cryptsetup_1.0.7-2.diff.gz
 e19518c6d34f21fa59617784bd33c23c72dd2560 350160 cryptsetup_1.0.7-2_amd64.deb
 25c12918d4cb0327fd6499f420dce3446f942cab 277882 cryptsetup-udeb_1.0.7-2_amd64.udeb
Checksums-Sha256: 
 0bac6c6d02e89e8f54ef2e1e0626bfdf10248e28cf7b81a6cfe051f35b4032a4 1486 cryptsetup_1.0.7-2.dsc
 dc30b80592ddef03e3f4b2790ab9afa9bc819c11ff2e4dc69d5b6609a45cb026 71180 cryptsetup_1.0.7-2.diff.gz
 780f576be5215f3f281377907c0cecc2b85f6b5274f96e363a51b475c9826cab 350160 cryptsetup_1.0.7-2_amd64.deb
 a9196b24016a9608abc8daa4652732baa3d431955abb543b5192f834804d2e2d 277882 cryptsetup-udeb_1.0.7-2_amd64.udeb
Files: 
 a0bc51b65b0384de3dd069b99370c62e 1486 admin optional cryptsetup_1.0.7-2.dsc
 cf850936ac5ba1843ff7370b6482d736 71180 admin optional cryptsetup_1.0.7-2.diff.gz
 41873cec5d55c4e49b1d55211255e41b 350160 admin optional cryptsetup_1.0.7-2_amd64.deb
 8aa45b4f551817c662189547db588876 277882 debian-installer optional cryptsetup-udeb_1.0.7-2_amd64.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqc/CcACgkQd6lUs+JfIQKsegCggDGhJPYf3WMGAfKe9Rj/+t+U
hCMAn1Z/CR5UKGief9LiAziMws0A1+n+
=QJtI
-----END PGP SIGNATURE-----





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Tue, 01 Sep 2009 21:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sebastian Andrzej Siewior <sebastian@breakpoint.cc>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Tue, 01 Sep 2009 21:21:04 GMT) Full text and rfc822 format available.

Message #117 received at 541835@bugs.debian.org (full text, mbox):

From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Jonas Meurer <jonas@freesources.org>
Cc: Celejar <celejar@gmail.com>, Randy Dunlap <randy.dunlap@oracle.com>, 541835@bugs.debian.org, lkml <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Tue, 1 Sep 2009 23:11:55 +0200
* Jonas Meurer | 2009-09-01 02:51:20 [+0200]:

>as you already discovered, that's because the initramfs hook script for
>cryptroot adds some crypto modules manually in debian. currently these
>are dm-mod, dm-crypt, cbc, aes, sha256 and all the modules they depend
>on.

You could add something like
|for dev in $rootdev $resumedevs; do
|       info="$(cryptsetup luksDump $rootdev)"
|       if [ $? -ne 0]; then
|               # Partition is now encrypted
|               continue
|       fi
|       cipher="$(cryptsetup luksDump /dev/md1 |grep "Cipher name:" | \
|            sed 's@^Cipher name:\s\+@@')"
|       add_crypto_modules $cipher
|       mode="$(cryptsetup luksDump /dev/md1 |grep "Cipher name:")"
|       echo "$mode" | sed \
|               -e 's@^Cipher name:\s\+@@') \
|               -e 's@-@ @' \
|               -e 's@:@ @'
|       # mode is now "<block_mode> <IV_mode> <hash>"
|       blk_mode=$(echo $mode | awk '{print $1}'
|       hash=$(echo $mode | awk '{print $3})'
|       add_crypto_modules $blk_mode
|       add_crypto_modules $hash
|done       
instead of hardcoding cbc, aes & sha256

>> So this brings me to the following question: Why are you so picky and you
>> don't take all of the modules? sh 2.6.30-1 on various debian archs:
>> du -sh              x86_64  i386  powerpc  s390x   mips(r5k-ip32)
>> crypto              720K    636K  1.1M     804K    968K
>> arch/<arch>/crypto  72K     36K   0        92K     0
>> driver/crypto       32K     60K   60K      0       52K
>> Total               824K    732K  1.2M     896K    1020
>> 
>> So all modules together have an average footprint of 941.0K. This isn't
>> that much. There is no size limit on initrd unless you are on a system
>> with has 32MiB or something like that :)
>> With *all* those crypto modules which are selected and built you are
>> able to cover all corner cases.
>> I took a look at hooks/cryptroot and really and only a few modules are
>> included. Right now you don't include HW cipher e.g. VIA's padlock or
>> AMD's geode. If you don't load those module while openning the root
>> partition (the first request), then the module is never loaded / used.
>> The other unhandled case are non default ciphers like xts(aes) which one
>> might use. The brand new aes implementation aesni-intel is also not be
>> considered. Most modules have _generic in their name if there is
>> another implementation available and <name>-arch if there is an assembly
>> variant but I would prefer that this does not become part of an ABI
>> where one can rely on.
>> 
>> Would it be okay for you to change the way the crypto modules are picked
>> and include the full set?
>
>i don't like the idea to add _all_ crypto modules into the initramfs per
>default. the size of crypto and arch/<arch>/crypto will keep on growing
>for kernels which do have ship all available modules for ciphers and
>implementations. i think that the initramfs should be a _minimal_
>system, and detecting the required crypto modules should be possible.
Why is a minimal initramsfs here a good thing here? 1 MiB isn't that
huge and with gzip it does not grow much. Here is an example on my amd64
with current initramfs as of 2.6.30-1-amd64:
picky       : 10511917 bytes / 11 MiB
full crypto : 10729154 bytes / 11 MiB / + 2.1%

So. On AMD64 we are talking here about 200KiB or 2% of the whole image
size.
If arch/*/crypto grows than just because there is more support and this
is a good thing not bad.

>alternative crypto cipher and blockcipher modules are already detected
>if required, as information about these are available from the cryptroot
>configuration (either luks header or cmdline options given to cryptsetup).
ah so my little script was not required. What about d-i? AFAIK that one
runs from initramfs and relies on modules which are selected here. Isn't
this the case?

>i added cryptomgr, chainiv and krng to the list of required modules in
>/usr/share/initramfs-tools/hooks/cryptroot for now.
And in .32 you have work again because you need eseqiv.

>still i see the point that this solution has it's drawbacks. modules for
>crypto hardware and cipher implementations not following the convention to
>call modules <cipher>_generic and <cipher>-alias aren't detected by the
>current system.
exactly. Plus runtime dependency.

>i guess the best solution would be to improve the module dependency
>system. cipher meta-modules like 'aes' should depend on all available
>implementations. same for ivciphers, hashs, rng implementations etc.
>
>what do you think about it?
I don't the like extra work for 2%. Even if someone does this, you still
have lets say the geode, via-padlock and the hfin driver on a 486 system
which can't use all of them and relies on pure SW. No benefit there.

Okay. You put the crypto modules in initramfs in case the root partition
and or swap is encrypted. In case just /data is encrypted you don't need
those modules at all. So d-i needs all them in case the user might want
to xts(twofish) and not just the standard thing. The user-initramfs
script could take the full set of crypto modules if it is building a new
initramfs and grab the list of required modules from lsmod if the
initramfs is updated and the kernel is running.

>greetings,
> jonas

Sebastian




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>:
Bug#541835; Package cryptsetup. (Thu, 03 Sep 2009 03:30:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Herbert Xu <herbert@gondor.apana.org.au>:
Extra info received and forwarded to list. Copy sent to Debian Cryptsetup Team <pkg-cryptsetup-devel@lists.alioth.debian.org>. (Thu, 03 Sep 2009 03:30:08 GMT) Full text and rfc822 format available.

Message #122 received at 541835@bugs.debian.org (full text, mbox):

From: Herbert Xu <herbert@gondor.apana.org.au>
To: Jonas Meurer <jonas@freesources.org>
Cc: sebastian@breakpoint.cc, celejar@gmail.com, randy.dunlap@oracle.com, 541835@bugs.debian.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, control@bugs.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
Date: Thu, 3 Sep 2009 13:22:06 +1000
Jonas Meurer <jonas@freesources.org> wrote:
> 
> i guess the best solution would be to improve the module dependency
> system. cipher meta-modules like 'aes' should depend on all available
> implementations. same for ivciphers, hashs, rng implementations etc.

We already do that for algorithms at least, they should all have
aliases of the form "ALG" or "ALG-all".

Things like chainiv/eseqiv should just be included always.  There
are unlikely to be any new algorithms of that type.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 13 Oct 2009 07:35:21 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 04:52:26 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.