Bug 589390 - aesni-intel module breaks booting off encrypted root
Summary: aesni-intel module breaks booting off encrypted root
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kyle McMartin
QA Contact: Fedora Extras Quality Assurance
Depends On: 571577
TreeView+ depends on / blocked
Reported: 2010-05-06 02:55 UTC by Kyle McMartin
Modified: 2015-09-01 03:53 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 571577
Last Closed: 2011-06-15 13:33:17 UTC
Type: ---

Attachments (Terms of Use)

Description Kyle McMartin 2010-05-06 02:55:17 UTC
+++ This bug was initially created as a clone of Bug #571577 +++

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:
to the kernel boot line fixed it for me.  (Documenting it here in Bugzilla)

Version-Release number of selected component (if applicable):

--- Additional comment from dmalcolm@redhat.com on 2010-03-08 16:33:19 EST ---

Created an attachment (id=398629)
Photo of the boot failure

--- Additional comment from dmalcolm@redhat.com on 2010-03-09 15:01:19 EST ---

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:

--- Additional comment from cebbert@redhat.com on 2010-03-16 05:15:15 EDT ---

Can you get to a shell after boot fails and see what is in /proc/crypto?

--- Additional comment from kmcmartin@redhat.com on 2010-04-28 12:59:12 EDT ---


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

--- Additional comment from updates@fedoraproject.org on 2010-05-03 21:38:45 EDT ---

kernel- has been submitted as an update for Fedora 13.

--- Additional comment from updates@fedoraproject.org on 2010-05-04 19:53:16 EDT ---

kernel- has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from evan@eklitzke.org on 2010-05-05 13:30:19 EDT ---

I had my wireless AP set to use AES for encryption, and after upgrading to kernel- 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.

--- Additional comment from kmcmartin@redhat.com on 2010-05-05 22:54:07 EDT ---

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.


Comment 1 Bug Zapper 2010-07-30 11:33:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 2 Andy Lutomirski 2011-05-25 13:19:46 UTC
This bug will be fixed when these two commits make their way upstream:



Any kernel config workarounds can go away then.


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