Moving my patch and discussion here instead of on the the duplicate bug.

In the other bug Steve Langesek (vorion) 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.

Thanks for looking at my proposed patch.

I did some checking to see why the kernel is not auto-loading aesni-intel.ko in this case.

It looks like the initrd modules.alias is correct as it contains these lines:
alias aes aes_x86_64
alias aes aesni_intel

I believe this will load aesni_intel.ko if the command "modprobe aes" is run by the kernel. However, I do not believe the kernel ever runs this command.

Here is my analysis of the related kernel code:
* start with drivers/md/dm-crypt.c
* which calls crypto_alloc_cipher() in include/linux/crypto.h
* which calls crypto_alloc_base() in crypto/api.c
* which calls crypto_alg_mod_lookup()
* which calls crypto_larval_lookup()
* which calls crypto_alg_lookup()
* crypto_alg_lookup() returns the best matching algorithm currently loaded into the kernel, if any.
* crypto_larval_lookup() then calls request_module() if and only if crypto_alg_lookup() did not find a match.
* crypto_larvel_lookup() returns algorithm back through stack to start

Essentially, the kernel will not issue a "modprobe aes" on behalf of dm-crypt.ko if there is already an algorithm loaded that implements AES.

The default Ubuntu 12.04 kernel configuration (3.2.0-31-generic) contains the following:
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m

So the generic implementation of "aes" is built-in to the kernel, but the higher priority implementations are built as modules. 

As a result, the combination of the kernel auto-loading logic with the Ubuntu kernel configuration seems to be what results in the issue.

I view this as a serious issue as it significantly affects the performance of the SSD on my laptop (and likely would of anyone else with a similar setup). With the Ubuntu default mode of 256-bit aes-cbc-essiv:sha256, my average read performance as measured by Disk Utility is limited to 155.3 Mb/s. When this issue is fixed, I get an over three-fold improvement to 537.5 Mb/s, which is essentially the same as the unencrypted speed (538.3 Mb/s). Unnecessarily large performance hits like this will slow the adoption of full-disk encryption.

I see a few potential ways to fix this issue each with pros and cons:

1) Change the kernel so that it always issues "modprobe aes"
pro: keeps responsibility with loading the correct drivers in the kernel, where one might argue it rightfully belongs.
con: this would mean that EVERY call to crypto_alloc_* would result in a user space execution of "modprobe aes", which is potentially a serious performance issue and unlikely to be accepted by kernel developers.

2) Change the Ubuntu kernel configuration so that CONFIG_AES=m
pro: this would cause the kernel to execute "modprobe aes" once, which should load in the correct driver.
con: I haven't explicitly checked, but I would suspect CONFIG_AES=y is set because it is required for a dependency. If so, this may not be an option without wider ranging configuration changes.

3) Change the Ubuntu kernel configuration so that CONFIG_X86_64=y and CONFIG_AES_NI_INTEL=y
pro: any user of AES will then get the highest priority implementation
con: these options will bloat the kernel for users that do not use AES

4) Issue "modprobe aes" manually in cryptroot script
pro: simplest fix that solves the problem (one line change)
pro: additional modules loaded only when they are going to be used
pro: works with existing kernel and any kernel configuration
pro: harmless on systems that don't have non-generic drivers
pro: harmless even if one of the other systems is fixed
con: this is a workaround of the situation caused by other code (e.g. Ubuntu default kernel configuration, and Linux kernel) and should not realy be cryptsetup's responsibility

I suggest the following course of action:
Proceed with fix 4 and clearly label it as a workaround for issues in kernel & Ubuntu default configuration.
Submit bugs to the other projects for fixes 1-3, and if one or more of those goes through, the workaround can eventually be removed.