Bug 571577 - Unable to decrypt disk on F-12 x86_64 install on T410: required "rdblacklist=aesni-intel"
Summary: Unable to decrypt disk on F-12 x86_64 install on T410: required "rdblacklist=...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks: 589390
TreeView+ depends on / blocked
 
Reported: 2010-03-08 21:32 UTC by Dave Malcolm
Modified: 2010-08-03 00:58 UTC (History)
10 users (show)

(edit)
Clone Of:
: 586916 589390 (view as bug list)
(edit)
Last Closed: 2010-08-03 00:58:59 UTC


Attachments (Terms of Use)
Photo of the boot failure (135.40 KB, image/jpeg)
2010-03-08 21:33 UTC, Dave Malcolm
no flags Details

Description Dave Malcolm 2010-03-08 21:32:22 UTC
Description of problem:
I've been attempting to install F12 x86_64 on a new T410 laptop.

I've enabled disk encryption in the Anaconda UI, with a default partitioning scheme.  This is a new laptop, with no previous OS installed.

Manual installation appears to succeed, provided I pass "nomodeset vnc" at installation boot line.

However, on attempting to boot, I get various error messages.

Unable to get a direct screenshot, so manually typing the following:

alg: No test for __aes-aesni (__driver-aes-aesni)
alg: No test for __ecb-aes-aesni (__driver-ecb-aes-aesni)
alg: No test for __cbc-aes-aesni (__driver-cbc-aes-aesni)
alg: No test for __ecb-aes-aesni (cryptd(__driver-ecb-aes-aesni))
padlock: VIA PadLock not detected.
alg: skcipher: Failed to load transform for xts-aes-aesni: -2
device-mapper: table: 253:0: crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table
device-mapper: reload ioctl failed: Invalid argument
Failed to setup dm-crypt key mapping for device /dev/sda2
Check that kernel supports aes-xts-plain-cipher (check syslog for more info).
Failed to read from key storage


Ray Strode told me this is an issue with hardware crypto support: the hardware apparently has hardware crypt support, but a buggy module means that the crypto doesn't work, and thus the encrypted OS can't be booted.

The workaround of adding:
  rdblacklist=aesni-intel
to the kernel boot line fixed it for me.  (Documenting it here in Bugzilla)


Version-Release number of selected component (if applicable):
kernel-2.6.31.5-127.fc12.x86_64

Comment 1 Dave Malcolm 2010-03-08 21:33:19 UTC
Created attachment 398629 [details]
Photo of the boot failure

Comment 2 Dave Malcolm 2010-03-09 20:01:19 UTC
The problem is still present with the latest F12 kernel update; on this hardware I still need to use "rdblacklist=aesni-intel" to boot successfully (with encrypted partitions as per defaults), or the boot fails with (apparently) the same errors as in comment #0.

This is with:
kernel-2.6.32.9-67.fc12.x86_64

Comment 3 Chuck Ebbert 2010-03-16 09:15:15 UTC
Can you get to a shell after boot fails and see what is in /proc/crypto?

Comment 4 Kyle McMartin 2010-04-28 16:59:12 UTC
Dave,

So this error occurs regardless of install or not? (IE: blacklisted on install, then unblacklist and it will fail)
I'm looking into it now, it's a very strange error in a mess of code... If it happens outside of the installer it will be easier for me to test it.

regards, Kyle

Comment 5 Fedora Update System 2010-05-04 01:38:45 UTC
kernel-2.6.33.3-79.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kernel-2.6.33.3-79.fc13

Comment 6 Fedora Update System 2010-05-04 23:53:16 UTC
kernel-2.6.33.3-79.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Evan Klitzke 2010-05-05 17:30:19 UTC
I had my wireless AP set to use AES for encryption, and after upgrading to kernel-2.6.33.3-79.fc13 I have no longer been able to connect to my wireless network. Now that I see this change I can probably just change the encryption settings on my AP (once I get home later today), but this might have broken things for other users who aren't able to control the cipher used by access points they use.

Comment 8 Kyle McMartin 2010-05-06 02:54:07 UTC
No. That's a different bug and unrelated to this. You still have AES support, this just removes the ability to use the Core i7 AES instructions to accelerate it.

--Kyle

Comment 9 Chuck Ebbert 2010-07-13 18:54:00 UTC
Was this also happening on F-13? The bug was reported against F-12 and that is still not fixed, but a patch went into F-13...

Comment 10 Chuck Ebbert 2010-07-18 16:42:35 UTC
Could this be happening because we have CONFIG_CRYPTO_FIPS=y set in our .config? That will disable any crypto drivers that fail testing, and we are seeing messages that no tests exist for that driver.

This patch added NULL tests for those algorithms (?):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=863b557a88f8c033f7419fabafef4712a5055f85

Comment 11 Chuck Ebbert 2010-07-21 04:29:38 UTC
Added patch from comment #10 to 2.6.32.16-144

Comment 12 Chuck Ebbert 2010-07-21 12:23:47 UTC
Reported fixed via IRC. Also added a fix from F-13 in 2.6.32.16-145 for the async crypto testing error messages.

Comment 13 Fedora Update System 2010-07-24 14:01:04 UTC
kernel-2.6.32.16-150.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/kernel-2.6.32.16-150.fc12

Comment 14 Fedora Update System 2010-07-27 02:37:54 UTC
kernel-2.6.32.16-150.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.32.16-150.fc12

Comment 15 Fedora Update System 2010-08-03 00:58:53 UTC
kernel-2.6.32.16-150.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.