FS#9521 - Luks encrypted root doesn't accept keys (padlock-sha/-aes)

Attached to Project: Arch Linux
Opened by Gerhard Brauer (GerBra) - Monday, 11 February 2008, 00:53 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 03 March 2008, 22:45 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Critical
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When unlocking lucks encrypted root the key was not accepted. Only a key
on an extern medium unlock the device.


Additional info:
* package version(s)
kernel26-2.6.24.1-2
* config and/or log files etc.
Direct after/during key requestion:
padlock: VIA Padlock Hash Engine not detected
modprobe: WARNING: Error inserting padlock_sha (/lib/modules/2.6.24-ARCH/kernel/drivers/crypto/padlock-sha.ko)

After init, when loading modules, same WARNING again, but with padlock_aes/padlock-aes.do

Maybe an alias mismatch?:
grep padlock modules.alias
alias aes padlock_aes
alias sha256-padlock padlock_sha
alias sha1-padlock padlock_sha
alias sha256 padlock_sha
alias sha1 padlock_sha
All aliases are with underscore than an hyphen

Or an hyphen/underscore mismatch in encrypt hook in mkinitcpio?

Steps to reproduce:
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 03 March 2008, 22:45 GMT
Reason for closing:  Fixed
Comment by Gerhard Brauer (GerBra) - Monday, 11 February 2008, 01:05 GMT
Additional info:
Comparing old kernel 2.6.23 /lib/modules/kernel/crypto shows, that the wer modules named:
aes,sha1, sha256. In 2.6.24 these modules are renamed with an *_generic (aes_generic.ko)
Comment by Gerhard Brauer (GerBra) - Monday, 11 February 2008, 01:50 GMT
Ok, i got it. It was the key passphrase, which contains local language characters.
During 2.6.22/2.6.23 these key was always accepted, but not on 2.6.24. Any changes in default NLS keymap maybe.
I added a new key (lucky that i have a key on an extern medium to to this, cause the default key was also not accepted when typing in an de_DE.utf8 console). New key is without locals chars and this works.

The WARNING messages are still in dmesg, also when unlocking with the new key or per extern medium.
Maybe you have a look on this, there must be an reason when my default key wasn't accepted.
Comment by Thomas Bächler (brain0) - Monday, 11 February 2008, 09:50 GMT
Do you use the keymap hook? I just found a weird thing in it: If you have a UTF8 locale, it sets the console to UTF8, but doesn't set the LANG variable, so you get your characters typed as UTF8, but the programs assume it is iso8859-1, resulting in broken input (thus non-acceptance of your passphrase). At least that is my first thought, reassigning to tpowa, as he wrote the keymap hook.
Comment by Gerhard Brauer (GerBra) - Monday, 11 February 2008, 10:28 GMT
Yes, keymap hook is in HOOKS line before encrypt
Also in MODULES line in mkinitcpio.conf i have "nls_cp437 vfat". These must be autodetected and inserted maybee during use of an usb storage.

I'am my own fool to use foreign chars (and AltGR-Keystrokes) in my Passphrase. As i setup the system i set initial keys
in the installer shell. I think i set the keymap with km there, but im not sure.
Current i've tested in tty unlocking/add new key with several LANG= values, but my old key isn't accepted anymore.
Comment by Gerhard Brauer (GerBra) - Monday, 11 February 2008, 10:51 GMT
Another test:
I've added a new key in tty-console (de_DE.utf8) with foreign chars (umlauts). This key is accepted for unlocking during
boot.
I think my initial typed key during setup was malformed. And a wonder that it was working under 2.6.22/.23.
But if i haven't not a rescue kernel on HD and a extern key then i would have a big problem (Hm, booting from
install iso-cd and luksOpen maybe still also work).

From my side i could not anymore say: this is a bug. Seems more like an housemade problem.
Comment by Tobias Powalowski (tpowa) - Monday, 11 February 2008, 20:22 GMT
ok so can we close this?
Comment by Gerhard Brauer (GerBra) - Tuesday, 12 February 2008, 09:09 GMT
From my side: yes
If you do not see somthing which is or could be a problem with encrypt from my problem side: close it!
I don't see an gerneral bug, the warnings during boot will sure go away next releases.
And it seems that no one like me have had this problem.
I've changed my keys, live goes on....
Comment by Thomas Haider (gothmog.todi) - Tuesday, 12 February 2008, 13:37 GMT
should a separate bug be filled for the modprobe warning?
There seem to be several people reporting it:
http://bbs.archlinux.org/viewtopic.php?id=43705
Comment by Tobias Powalowski (tpowa) - Monday, 03 March 2008, 22:45 GMT
please fill a seperate bug report about the modprobe warnings

Loading...