initramfs cryptroot script does not load aesni_intel.ko before running cryptsetup

Bug #1058896 reported by David Holmer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
New
Undecided
Unassigned

Bug Description

I'm running on machine with an Intel Core i7 CPU which has AES-NI support: an insturction set for AES HW accelleration. Unfortunaately, when booting from an encrypted drive in Ubuntu 12.04, I found that the kernel's general purpose AES implementation was being used rather than the significantly faster AES-NI based implementation (see speed comparison below). Manually loading the aesni_intel.ko module after boot has no effect as the drive binds to the AES implementation durring the boot process. As a result, the initramfs must load the aesni_intel.ko module if it is to be used.

/usr/share/initramfs-tools/hooks/cryptroot correctly detects if the CPU supports AES-NI and correctly copies aesni_intel.ko to the initramfs image. The issue seems to be that /usr/share/initramfs-tools/scripts/local-top/cryptroot (which is transfered to the initramfs) fails to actually load aesni_intel.ko. I've attached a patch that adds modprobes for HW specific .kos to the script. If the initramfs does not contain these modules, these extra modprobes should have no effect.

Testing encryption bandwidth on a encrypted RAM FS best illustrates the performance differences in the different available AES implementations:

----------------------------------
aes (generic built-in version)

Write Read Options
271.62 218.80 -c aes-xts-plain -s 256
244.39 215.58 -c aes-cbc-essiv:sha256 -s 128
227.05 188.93 -c aes-xts-plain -s 384
234.86 186.86 -c aes-cbc-essiv:sha256 -s 192
232.20 166.78 -c aes-xts-plain -s 512
189.28 166.23 -c aes-cbc-essiv:sha256 -s 256

= current baseline performance

----------------------------------
aes_x86_64

Write Read Options
272.34 230.63 -c aes-xts-plain -s 256
270.18 228.06 -c aes-cbc-essiv:sha256 -s 128
237.04 198.83 -c aes-xts-plain -s 384
244.39 197.30 -c aes-cbc-essiv:sha256 -s 192
254.73 175.64 -c aes-xts-plain -s 512
218.80 174.45 -c aes-cbc-essiv:sha256 -s 256

= modest increase in performance for x86 64-bit CPUs that do not support AES-NI

----------------------------------
aesni_intel

Write Read Options
527.84 522.45 -c aes-xts-plain -s 256
701.37 1044.90 -c aes-cbc-essiv:sha256 -s 128
605.92 517.17 -c aes-xts-plain -s 384
644.03 1013.86 -c aes-cbc-essiv:sha256 -s 192
613.17 476.28 -c aes-xts-plain -s 512
711.11 975.24 -c aes-cbc-essiv:sha256 -s 256

= significant increase in performance for CPUs that support AES-NI

Revision history for this message
David Holmer (odinguru) wrote :
Revision history for this message
David Holmer (odinguru) wrote :

Also, forgot to add that this patch should fix this bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/908387

Revision history for this message
Steve Langasek (vorlon) wrote :

Cryptsetup should not be manually loading any modules, the kernel is supposed to take care of this automatically for us (and this works for me). Reassigning to the kernel package.

affects: cryptsetup (Ubuntu) → linux (Ubuntu)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.