Bug#464673: cryptsetup seems to try to load some padlock modules
Joachim Breitner
Version: 2:1.0.6~pre1+svn45-1
Severity: minor
File: /sbin/cryptsetup
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
on my system, when cryptsetup starts the root crypto partition during
the initrd phase, I get error messages that seem to come from modprobing
padlock-* modules, although I do not have such a devices.
These messages are confusing, and I`m not really sure what to think of
them, but they look too much like an error to me than they should.
Greetings,
Joachim
- -- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages cryptsetup depends on:
ii dmsetup 2:1.02.24-3 The Linux Kernel Device Mapper use
ii libc6 2.7-6 GNU C Library: Shared libraries
ii libdevmapper1.02.1 2:1.02.24-3 The Linux Kernel Device Mapper use
ii libpopt0 1.10-3 lib for parsing cmdline parameters
ii libuuid1 1.40.5-2 universally unique id library
cryptsetup recommends no packages.
- -- no debconf information
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHrB6I9ijrk0dDIGwRAh9hAKDGWmsMwAcCjzIt4hSHPQFbKBXxrACeNZiB
bA52zMvYW4pTcjWEr9DCm6U=
=jc0+
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonas Meurer
> Hi,
Hey Joachim,
> on my system, when cryptsetup starts the root crypto partition during
> the initrd phase, I get error messages that seem to come from modprobing
> padlock-* modules, although I do not have such a devices.
>
> These messages are confusing, and I`m not really sure what to think of
> them, but they look too much like an error to me than they should.
Could you provide the exact error message?
I doubt that this is an issue with cryptsetup. Sounds more like a
general problem with initramfs-tools. Does /etc/initramfs-tools/modules
contain any padlock-* modules?
And did this happen forever, or was it introduced by some subsequent
package upgrade?
greetings,
jonas
Joachim Breitner
Am Freitag, den 08.02.2008, 11:13 +0100 schrieb Jonas Meurer:
>On 08/02/2008 Joachim Breitner wrote:
> > on my system, when cryptsetup starts the root crypto partition during
> > the initrd phase, I get error messages that seem to come from modprobing
> > padlock-* modules, although I do not have such a devices.
> >
> > These messages are confusing, and I`m not really sure what to think of
> > them, but they look too much like an error to me than they should.
>
> Could you provide the exact error message?
Not so easy, as it happens during the initramfs state.
When I enter a wrong key, the error message (which seems to be just the
result of a "modprobe padlock-something", no other output happening)
appears before I can retry to enter the password again. This made me
think that it’s a cryptsetup issue.
I also observed:
$ strings /sbin/cryptsetup |grep -i padlock
padlock-rng
padlock-aes
padlock-sha
> I doubt that this is an issue with cryptsetup. Sounds more like a
> general problem with initramfs-tools. Does /etc/initramfs-tools/modules
> contain any padlock-* modules?
No padlock does not appear anywhere in /etc.
> And did this happen forever, or was it introduced by some subsequent
> package upgrade?
Oh, sorry for forgetting to mention that: It occurred after the upgrade
to the kernel version 2.6.24.
Thanks,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nom...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nom...@joachim-breitner.de | http://people.debian.org/~nomeata
Joachim Breitner
Am Freitag, den 08.02.2008, 13:29 +0100 schrieb Jonas Meurer:
> On 08/02/2008 Joachim Breitner wrote:
> > > > on my system, when cryptsetup starts the root crypto partition during
> > > > the initrd phase, I get error messages that seem to come from modprobing
> > > > padlock-* modules, although I do not have such a devices.
> > > >
> > > > These messages are confusing, and I`m not really sure what to think of
> > > > them, but they look too much like an error to me than they should.
> > >
> > > Could you provide the exact error message?
> >
> > Not so easy, as it happens during the initramfs state.
> >
> > When I enter a wrong key, the error message (which seems to be just the
> > result of a "modprobe padlock-something", no other output happening)
> > appears before I can retry to enter the password again. This made me
> > think that it’s a cryptsetup issue.
>
> you could write the error down to a paper ;-)
I’ll do that when I next restart the machine.
>
> does the message look like the following?
> FATAL: Module padlock_rng not found.
No, the module is present, but refused to load. I think the error
message is identical to this one:
$ sudo modprobe padlock-aes
FATAL: Error inserting padlock_aes (/lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko): No such device
This is from dmesg, from the kernel boot:
padlock: VIA PadLock not detected.
padlock: VIA PadLock Hash Engine not detected.
> > I also observed:
> > $ strings /sbin/cryptsetup |grep -i padlock
> > padlock-rng
> > padlock-aes
> > padlock-sha
>
> you're correct, even though these strings don't come from cryptsetup.
> searching for 'padlock' in the sourcecode of cryptsetup doesn't give any
> results other than one comment in line 114 of utils.c:
>
> /* Credits go to Michal's padlock patches for this alignment code */
>
> the strings in /sbin/cryptsetup actually come from static linking
> against libgcrypt:
>
> $ strings /usr/lib/libgcrypt.a |grep -i padlock
> padlock-rng
> padlock-aes
> padlock-sha
Ah, I see. But running gdb during initrd to find out which function by
gcrypt caused this will be hard. And I just tried to cryptsetup open a
loopback-file, without such an error.
> > > And did this happen forever, or was it introduced by some subsequent
> > > package upgrade?
> >
> > Oh, sorry for forgetting to mention that: It occurred after the upgrade
> > to the kernel version 2.6.24.
>
> Ok, so i believe that this is rather an issue with the debian linux 2.6.24
> kernel, not with cryptsetup.
Should I reassign this bug then to the kernel package? Or gcrypt?
Greetings and thanks for helping to debug this,
Jonas Meurer
> > > on my system, when cryptsetup starts the root crypto partition during
> > > the initrd phase, I get error messages that seem to come from modprobing
> > > padlock-* modules, although I do not have such a devices.
> > >
> > > These messages are confusing, and I`m not really sure what to think of
> > > them, but they look too much like an error to me than they should.
> >
> > Could you provide the exact error message?
>
> Not so easy, as it happens during the initramfs state.
>
> When I enter a wrong key, the error message (which seems to be just the
> result of a "modprobe padlock-something", no other output happening)
> appears before I can retry to enter the password again. This made me
> think that it’s a cryptsetup issue.
you could write the error down to a paper ;-)
does the message look like the following?
FATAL: Module padlock_rng not found.
> I also observed:
> $ strings /sbin/cryptsetup |grep -i padlock
> padlock-rng
> padlock-aes
> padlock-sha
you're correct, even though these strings don't come from cryptsetup.
searching for 'padlock' in the sourcecode of cryptsetup doesn't give any
results other than one comment in line 114 of utils.c:
/* Credits go to Michal's padlock patches for this alignment code */
the strings in /sbin/cryptsetup actually come from static linking
against libgcrypt:
$ strings /usr/lib/libgcrypt.a |grep -i padlock
padlock-rng
padlock-aes
padlock-sha
> > I doubt that this is an issue with cryptsetup. Sounds more like a
> > general problem with initramfs-tools. Does /etc/initramfs-tools/modules
> > contain any padlock-* modules?
>
> No padlock does not appear anywhere in /etc.
same for me.
> > And did this happen forever, or was it introduced by some subsequent
> > package upgrade?
>
> Oh, sorry for forgetting to mention that: It occurred after the upgrade
> to the kernel version 2.6.24.
Ok, so i believe that this is rather an issue with the debian linux 2.6.24
kernel, not with cryptsetup.
greetings,
jonas
Jonas Meurer
Hey,
> No, the module is present, but refused to load. I think the error
> message is identical to this one:
>
> $ sudo modprobe padlock-aes
> FATAL: Error inserting padlock_aes (/lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko): No such device
>
> This is from dmesg, from the kernel boot:
>
> padlock: VIA PadLock not detected.
> padlock: VIA PadLock Hash Engine not detected.
ok. i can imagine that the issue here is about padlock-* modules being
built for debian linux 2.6.24 kernel per default, while they weren't
built for previous kernels.
now some initramfs magic tries to load them because they're available,
and this fails due to missing hardware (padlock modules seem to be for
hardware hash generators, which you obviously don't have).
> > > I also observed:
> > > $ strings /sbin/cryptsetup |grep -i padlock
> > > padlock-rng
> > > padlock-aes
> > > padlock-sha
> >
> > the strings in /sbin/cryptsetup actually come from static linking
> > against libgcrypt:
> >
> > $ strings /usr/lib/libgcrypt.a |grep -i padlock
> > padlock-rng
> > padlock-aes
> > padlock-sha
>
> Ah, I see. But running gdb during initrd to find out which function by
> gcrypt caused this will be hard. And I just tried to cryptsetup open a
> loopback-file, without such an error.
The errors are obviously not produced by cryptsetup itself, but rather
by some initramfs magic. that's the reason why they only appear at boot
process, and not at invoking cryptdisks/cryptsetup manually.
the errors are harmless by the way, they just tell you that the required
hardware (a hardware hash generator) is missing.
> > Ok, so i believe that this is rather an issue with the debian linux 2.6.24
> > kernel, not with cryptsetup.
>
> Should I reassign this bug then to the kernel package? Or gcrypt?
neither cryptsetup nor gcrypt seem to cause the issue. and the kernel
team should not be blamed for adding some new modules to be shipped
with the kernel image.
in my eyes the real problem is whatever initramfs script tries to load
the modules per default. maybe you should contact maximilian attems
<ma...@debian.org> or the kernel team as maintainers of initramfs-tools,
they're usually quite responsive.
I've cc'ed debian...@lists.debian.org in this mail.
greetings,
jonas
Joachim Breitner
Am Freitag, den 08.02.2008, 14:16 +0100 schrieb Jonas Meurer:
> On 08/02/2008 Joachim Breitner wrote:
> > > > I also observed:
> > > > $ strings /sbin/cryptsetup |grep -i padlock
> > > > padlock-rng
> > > > padlock-aes
> > > > padlock-sha
> > >
> > > the strings in /sbin/cryptsetup actually come from static linking
> > > against libgcrypt:
> > >
> > > $ strings /usr/lib/libgcrypt.a |grep -i padlock
> > > padlock-rng
> > > padlock-aes
> > > padlock-sha
> >
> > Ah, I see. But running gdb during initrd to find out which function by
> > gcrypt caused this will be hard. And I just tried to cryptsetup open a
> > loopback-file, without such an error.
>
> The errors are obviously not produced by cryptsetup itself, but rather
> by some initramfs magic. that's the reason why they only appear at boot
> process, and not at invoking cryptdisks/cryptsetup manually.
I’m not sure about his. I am pretty sure the error messages came _after_
I entered the password the first time, but _before_ cryptsetup exits,
which I noticed when I entered the password wrong the first time, and
the second prompt came after the error messages.
I’ll make sure this observation is correct at the next boot.
Also, fgrepping the contents of my initramdisk for padlock, I only get:
./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko.
./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-sha.ko.
./sbin/cryptsetup.
./usr/lib/libcrypto.so.0.9.8.
so no script is manually loading these.
> > > Ok, so i believe that this is rather an issue with the debian linux 2.6.24
> > > kernel, not with cryptsetup.
> >
> > Should I reassign this bug then to the kernel package? Or gcrypt?
>
> neither cryptsetup nor gcrypt seem to cause the issue. and the kernel
> team should not be blamed for adding some new modules to be shipped
> with the kernel image.
> in my eyes the real problem is whatever initramfs script tries to load
> the modules per default. maybe you should contact maximilian attems
> <ma...@debian.org> or the kernel team as maintainers of initramfs-tools,
> they're usually quite responsive.
>
> I've cc'ed debian...@lists.debian.org in this mail.
Thanks,
Greetings,
Jonas Meurer
> > The errors are obviously not produced by cryptsetup itself, but rather
> > by some initramfs magic. that's the reason why they only appear at boot
> > process, and not at invoking cryptdisks/cryptsetup manually.
>
> I’m not sure about his. I am pretty sure the error messages came _after_
> I entered the password the first time, but _before_ cryptsetup exits,
> which I noticed when I entered the password wrong the first time, and
> the second prompt came after the error messages.
>
> I’ll make sure this observation is correct at the next boot.
>
> Also, fgrepping the contents of my initramdisk for padlock, I only get:
> ./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko.
> ./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-sha.ko.
> ./sbin/cryptsetup.
> ./usr/lib/libcrypto.so.0.9.8.
>
> so no script is manually loading these.
Hey Joachim,
Still some script adds the modules to you initramdisk, but i'm not sure
whether this is initramfs-tools (update-initramfs) or some thirdparty
script. Maybe you could add some debugging code to
/usr/share/initramfs-tools/scripts/local-top/cryptroot and/or
/usr/share/initramfs-tools/hooks/cryptroot?
David, could you give further advice?
greetings,
jonas
David Härdeman
>On 08/02/2008 Joachim Breitner wrote:
>> I’m not sure about his. I am pretty sure the error messages came _after_
>> I entered the password the first time, but _before_ cryptsetup exits,
>> which I noticed when I entered the password wrong the first time, and
>> the second prompt came after the error messages.
>>
>> I’ll make sure this observation is correct at the next boot.
>>
>> Also, fgrepping the contents of my initramdisk for padlock, I only get:
>> ./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko.
>> ./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-sha.ko.
>> ./sbin/cryptsetup.
>> ./usr/lib/libcrypto.so.0.9.8.
>>
>> so no script is manually loading these.
>
>whether this is initramfs-tools (update-initramfs) or some thirdparty
>script. Maybe you could add some debugging code to
>/usr/share/initramfs-tools/scripts/local-top/cryptroot and/or
>/usr/share/initramfs-tools/hooks/cryptroot?
>
>David, could you give further advice?
/usr/lib/libcrypto.so.0.9.8 comes from the openssl package. The openssl
package changelog says:
openssl (0.9.8e-1) unstable; urgency=low
...
- Load padlock modules (Closes: #345656, #368476)
...
So it seems that the openssl library might be responsible for loading
the padlock modules.
As to why they are included in the initramfs image in the first place,
the cryptsetup initramfs hook uses the initramfs-tools function
manual_add_modules to add modules to the initramfs image.
manual_add_modules checks module dependencies with modprobe, so if the
cryptsetup hook calls "manual_add_modules aes", the following is
executed by that function (this example is for the Debian 2.6.24
kernel):
modprobe --set-version="2.6.24-1-686" --ignore-install --show-depends aes
which gives this output:
insmod /lib/modules/2.6.24-1-686/kernel/crypto/aes_generic.ko
insmod /lib/modules/2.6.24-1-686/kernel/crypto/blkcipher.ko
insmod /lib/modules/2.6.24-1-686/kernel/drivers/crypto/geode-aes.ko
insmod /lib/modules/2.6.24-1-686/kernel/crypto/blkcipher.ko
insmod /lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko
insmod /lib/modules/2.6.24-1-686/kernel/arch/x86/crypto/aes-i586.ko
And all of those modules are added as a result.
I think the next step would be to get some feedback from Maximilian.
--
David Härdeman
Jonas Meurer
> As to why they are included in the initramfs image in the first place,
> the cryptsetup initramfs hook uses the initramfs-tools function
> manual_add_modules to add modules to the initramfs image.
>
> manual_add_modules checks module dependencies with modprobe, so if the
> cryptsetup hook calls "manual_add_modules aes", the following is
> executed by that function (this example is for the Debian 2.6.24
> kernel):
>
> modprobe --set-version="2.6.24-1-686" --ignore-install --show-depends aes
>
> which gives this output:
>
> insmod /lib/modules/2.6.24-1-686/kernel/crypto/aes_generic.ko insmod
> /lib/modules/2.6.24-1-686/kernel/crypto/blkcipher.ko insmod
> /lib/modules/2.6.24-1-686/kernel/drivers/crypto/geode-aes.ko insmod
> /lib/modules/2.6.24-1-686/kernel/crypto/blkcipher.ko insmod
> /lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko insmod
> /lib/modules/2.6.24-1-686/kernel/arch/x86/crypto/aes-i586.ko
>
> And all of those modules are added as a result.
>
> I think the next step would be to get some feedback from Maximilian.
I discussed the issue with maks and waldi on irc today, and finally
waldi told me that the aes module where renamed to aes_generic in kernel
2.6.24. The same goes for des, sha1 and sha256 modules.
All aes* modules do have an alias for aes, thus modprobe from
manual_add_modules() produces the list above.
The proposed fix for this is to check for kernel version in the
initramfs cryptroot hook, and substitute aes/des/sha256 by <cipher>_generic
if necessary. I don't like that idea though, as that bloats the script even
more and doesn't provide a general solution for the future. How shall we
know when yet another cipher module is renamed? and i fear that we will
end up with something like
case "$k_vers" in
2.6.2[4-9]*)
modules=$(sed -e 's/aes/aes_generic' \
-e 's/des/des_generic' [...])
2.6.2[5-9]*)
modules=$(sed -e 's/<cipher>/<cipher>_generic' \
[...])
which in my eyes is a nightmare to maintain.
greetings,
jonas