On Fri, Oct 9, 2009 at 9:50 PM, Hussam Al-Tayeb wrote:

On Fri, 2009-10-09 at 19:48 +0200, Thomas Bächler wrote:

...

Hussam Al-Tayeb schrieb:

...

Hi, I'm having a problem with disk encryption using luks. I have my /home disk (on a separate disk 'sdb') encrypted using luks.

I have this in /etc/cryptsetup home            /dev/sdb1               ASK

and this in /etc/fstab /dev/mapper/home /home ext4 defaults,user_xattr 0 1

Suddenly today, it won't accept the passphrase on boot. I'm sure that I'm entering it correctly. It took me 32 tries the first time and many more the second reboot after kernel 2.6.31.3 update.

I don't really know what's happening right now. However, you should comment out that crypttab line, mark /home as noauto in fstab, boot your system and try unlocking there manually. That way, it will be much easier to investigate the problem.

Ok, I did that. and manually run 'cryptsetup luksOpen /dev/sdb1 home' It literally took over 97 tries before it worked. How do I investigate what's happening?  cryptsetup -v doesn't give extra output?

So this is a 2.6.31 regression, right ? If you go back on 2.6.30, it's all fine ? Did you search for luks regression in 2.6.31 ? After a quick google (less than 1 minute), it seems that some ubuntu users are affected too : https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/433051 Though not much information there. Maybe you should report this problem in more appropriate places, after you managed to get more information about the problem.

Heiko Baums schrieb:

Well, I can't say anything about this issue, but I'd like to suggest not to move kernel26 2.6.31.3 from testing to core, until this issue is fixed, because I think this is a major issue, if it's really kernel related.

It is very unlikely to be kernel related. And 2.6.31 has been in testing far too long, it should really be moved.

On Sat, 2009-10-10 at 00:56 +0200, Heiko Baums wrote:

Am Sat, 10 Oct 2009 00:08:00 +0200 schrieb Thomas Bächler :

...

It is very unlikely to be kernel related. And 2.6.31 has been in testing far too long, it should really be moved.

I just installed kernel26 2.6.31.3 from testing and can't reproduce this issue. I have encrypted my whole system except of the /boot partition of course.

I can unlock every partition by reading the keys from USB stick and by entering the passphrases. So I also don't think that this is kernel related.

Heiko

my root partition passphrase (arch asks for at initramfs stage) always works and it accepts it correctly. This issue happens when you try to unlock a partition later on. This means that if you don't have an encrypted /home on a different partition, you won't see this problem.

Am Sat, 10 Oct 2009 02:35:06 +0300 schrieb Roman Kyrylych :

I have 4 encrypted partitions besides root and don't have this problem, but I have real passwords instead of ASK in /etc/crypttab (otherwise I would be very lazy to enter them 5 times instead of one :-P)

It would probably be a bit more secure to write a keyfile onto a USB stick either as a file or with dd and apply one of those patches to /etc/rc.sysinit: http://bugs.archlinux.org/task/11648 http://bugs.archlinux.org/task/15016 And if you add one of these lines to your kernel line in grub's menu.lst then you don't need to enter one single passphrase. Just plugin the USB stick before and unplug it after booting. ;-) cryptdevice=/dev/sdaX:root root=/dev/mapper/root cryptkey=/dev/usbkey/KEYFILE cryptdevice=/dev/sdaX:root root=/dev/mapper/root cryptkey=/dev/usbkey:OFFSET:SIZE Heiko

Am Sat, 10 Oct 2009 03:09:14 +0300 schrieb Roman Kyrylych :

I don't see why it's more secure.

Because your / partition where you have stored your passphrase as a clear text in /etc/crypttab is unlocked, if your computer is running. If you get hacked your passphrase can easily be read. If the key is on the USB stick, the USB stick is unplugged and the computer gets hacked, the passphrase and the key can't be read. Of course it is somewhere in the RAM, but I don't know how hard it is to find it there, if the system gets hacked online.

And that's way it's much less secure, someone just takes your USB stick and logins.

First you should keep the USB stick save and shouldn't let it taken by someone else. Second if you format the USB stick with e.g. ext3 and write the keyfile with dd on a free place, then it looks like an empty filesystem if it gets mounted. The keys can only be found by searching the raw data with e.g. a hex editor. And then the person who has taken your USB key must know that it is a key for your partitions. Well, of course the offset can be found in the kernel line in menu.lst on the unencrypted /boot partition. But this would imply that the person who has stolen your computer and your USB stick(s) needs to know which is the right stick. And he must know a bit about Linux and LUKS. It's more likely that a hacker who hacks you online has Linux and LUKS knowledge than someone who steals your computer and your USB stick offline. But, of course, nothing is 100% secure. And I guess it's a matter of philosophy. It depends on where is the higher danger, offline or online. Heiko

On Sat, 2009-10-10 at 01:45 +0200, Heiko Baums wrote:

Am Sat, 10 Oct 2009 02:15:35 +0300 schrieb Hussam Al-Tayeb :

...

my root partition passphrase (arch asks for at initramfs stage) always works and it accepts it correctly. This issue happens when you try to unlock a partition later on. This means that if you don't have an encrypted /home on a different partition, you won't see this problem.

Just another thought. I know that this is also pretty improbable.

I don't know the filesystem of your / partition. Can this be an issue with ext4 in kernel 2.6.31 and LUKS?

Have you checked your harddisk with smartctl, badblocks or something similar? Maybe it is indeed dying. Of course it's also improbable if this issue appeared only after upgrading from kernel 2.6.30 to 2.6.31 but maybe worth a try.

Otherwise I don't have any other ideas.

Heiko

I did a fsck and badblocks. nothing wrong there. I don't think it is failing because cryptsetup on an old opensuse live cd successfully unlocks /dev/sdb1 eventhough it doesn't support ext4. I'm reading manpage for smarctl and will run a test and post results.

Am Sat, 10 Oct 2009 03:13:38 +0300 schrieb Hussam Al-Tayeb :

I did a fsck and badblocks. nothing wrong there. I don't think it is failing because cryptsetup on an old opensuse live cd successfully unlocks /dev/sdb1 eventhough it doesn't support ext4.

You're saying "an old opensuse live cd". So I assume, that it hasn't already kernel 2.6.31? Maybe you should try it with a live cd which already has kernel 2.6.31, if there is any released. It probably is a bug in ext4 in 2.6.31 which wasn't present in 2.6.30. It's not likely, but with ext3 I don't have this issue. I guess you already have reinstalled the kernel and/or cryptsetup just in case? If this also doesn't help, I guess someone else who has better knowledge of this than me - should be easy to find ;-) - could try to help. Heiko

Hussam Al-Tayeb (2009-10-10 14:11):

Yes, I've reinstalled both the kernel and cryptsetup. luks is device blocks encryption if I'm not mistaken so filesystem type shouldn't matter.

Yes, the filesystem type shouldn't matter. Anyway, I'm running a custom built 2.6.31.3 and use an encrypted ext4 home partition with passphrases, and it works here. In your previous mails you were saying that your home partition unlocks every time, but only after numerous consecutive tries, correct? That is, after booting, dash -c 'echo "pass"|cryptsetup luksOpen dev name' doesn't work, but dash while ! echo "pass"|cryptsetup luksOpen dev name; do n=$((n+1)); test $n -ge 100 && break done does? If that is the case, it is really strange and I doubt I can help you. Did you try simply booting up, waiting for a minute or two and trying to unlock the partition? You didn't post the relevant part of your /var/log/pacman.log yet (the part with the update which broke cryptsetup). You didn't say why and how did you update to 2.6.31.3. Are you running the testing repository? You didn't say whether you tried downgrading your kernel: $ pacman -S kernel26 and/or $ pacman -S kernel26-lts Did you try running /sbin/cryptsetup.static instead of cryptsetup? Might module loading be delayed because of some obscure reason? $ lsmod|grep -i aes Have you got some exocitc cpu with hardware AES encryption? -- -- Rogutės Sparnuotos

Am Fri, 9 Oct 2009 22:00:15 +0200 schrieb Xavier :

After a quick google (less than 1 minute), it seems that some ubuntu users are affected too : https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/433051

I have an idea. I'm not really sure, if this can be the reason, and I haven't tested it yet. But can this probably be an issue with the keymap? Hussam, do you have keymap in the HOOKS in /etc/mkinitcpio.conf? Maybe you could try to remove it and enter the passphrase with the standard us keymap. You should of course write down the correct keys you have to press, if you don't use a US keyboard. Heiko

it has been sometime ago # grep cryptsetup /var/log/pacman.log [2008-07-16 11:03] upgraded cryptsetup (1.0.6-1 -> 1.0.6-1) [2008-10-08 14:29] upgraded cryptsetup (1.0.6-1 -> 1.0.6-2) [2009-06-19 21:52] upgraded cryptsetup (1.0.6-2 -> 1.0.6-3) [2009-08-10 14:52] upgraded cryptsetup (1.0.6-3 -> 1.0.7-1)

On Tue, 2009-10-13 at 20:10 +0200, Thomas Bächler wrote:

solsTiCe d'Hiver schrieb:

...

it has been sometime ago

# grep cryptsetup /var/log/pacman.log [2008-07-16 11:03] upgraded cryptsetup (1.0.6-1 -> 1.0.6-1) [2008-10-08 14:29] upgraded cryptsetup (1.0.6-1 -> 1.0.6-2) [2009-06-19 21:52] upgraded cryptsetup (1.0.6-2 -> 1.0.6-3) [2009-08-10 14:52] upgraded cryptsetup (1.0.6-3 -> 1.0.7-1)

So that's not it. 1.0.7 should be working better anyway. Sadly, a viable debug option has only been introduced in 1.1.0rc1 afaik, 1.0.7 doesn't have anything that will help here. We need to find out where exactly it fails. Maybe I could write an email to Milan Broz about this, because I am out of ideas.

I compiled 1.1.0rc2 then copied cryptsetup libcryptsetup.so libcryptsetup.so.1 libcryptsetup.so.1.0.0 to /tmp/testfolder then cd /tmp/testfolder then LD_LIBRARY_PATH=./ ./cryptsetup --debug luksOpen /dev/sdb1 home and it unlocks it correctly everytime!

On Tue, 2009-10-13 at 22:07 +0200, Thomas Bächler wrote:

Hussam Al-Tayeb schrieb:

...

I compiled 1.1.0rc2 then copied cryptsetup libcryptsetup.so libcryptsetup.so.1 libcryptsetup.so.1.0.0 to /tmp/testfolder then cd /tmp/testfolder then LD_LIBRARY_PATH=./ ./cryptsetup --debug luksOpen /dev/sdb1 home and it unlocks it correctly everytime!

Nice. I suggest you upgrade to 1.1.0rc2 then (changes to the PKGBUILD should be trivial). I hope it won't break anything for you further. If the problem stays away with 1.1.0, that is solution enough for me. If it returns, we need to really find out what's wrong.

Done! I updated to 1.1.0-rc2 then I also upgraded to kernel 2.6.31.4 After rebooting, things are still fine. /dev/sdb1 unlocked correctly :)

On Tue, 2009-10-13 at 23:27 +0200, Xavier wrote:

On Tue, Oct 13, 2009 at 11:04 PM, Hussam Al-Tayeb wrote:

...

...

Nice. I suggest you upgrade to 1.1.0rc2 then (changes to the PKGBUILD should be trivial). I hope it won't break anything for you further. If the problem stays away with 1.1.0, that is solution enough for me. If it returns, we need to really find out what's wrong.

Done! I updated to 1.1.0-rc2 then I also upgraded to kernel 2.6.31.4 After rebooting, things are still fine. /dev/sdb1 unlocked correctly :)

Could you check the upstream issues to find if one matches your case ? http://code.google.com/p/cryptsetup/issues/list?can=1&q=&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=tiles

It seems there are a few issues related to udev and some locking or racing conditions : http://code.google.com/p/cryptsetup/issues/list?can=1&q=udev&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=tiles

I looked at all your mails, and it seems you never showed exactly what the output of cryptsetup was when it failed.

It's good to know it's fixed in 1.1.0-rc2 but it would be better to know why.

It just didn't accept the passphrase as if I entered it correctly.

solsTiCe d'Hiver schrieb:

i am beginning to think there really is a problem. i have a luks encrypted partition that i automatically mount at boot via /etc/crypttab with a *keyfile*

so this has never failed and it can't fail except if the keyfile is damaged. and today the luks partition failed to be opened for the *first* time *ever* by cryptsetup because of a password problem. once i rebooted it worked. so the keyfile is not wrong. and i double check it with my backup keyfile

this looks like your problem Hussam. it sometimes fails sometimes works.

When did any of you guys upgrade to cryptsetup 1.0.7? Can you grep this from pacman.log please? [2009-07-25 20:43] upgraded cryptsetup (1.0.6-3 -> 1.0.7-1)