Bug 589390 - aesni-intel module breaks booting off encrypted root
aesni-intel module breaks booting off encrypted root
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Kyle McMartin
Fedora Extras Quality Assurance
:
Depends On: 571577
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-05 22:55 EDT by Kyle McMartin
Modified: 2015-08-31 23:53 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 571577
Environment:
Last Closed: 2011-06-15 09:33:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kyle McMartin 2010-05-05 22:55:17 EDT
+++ 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:
  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

--- 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:
kernel-2.6.32.9-67.fc12.x86_64

--- 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 ---

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

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

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

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

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.

--- 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-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.

--- 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.

--Kyle
Comment 1 Bug Zapper 2010-07-30 07:33:30 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Andy Lutomirski 2011-05-25 09:19:46 EDT
This bug will be fixed when these two commits make their way upstream:

http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commit;h=9bed4aca296fdf9c1b85a8f093e92018dc9864f3

http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commit;h=b23b64516500df6b70fcafb820970f18538252cf

Any kernel config workarounds can go away then.


--Andy

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