[Bug 1058896] Re: initramfs cryptroot script does not load aesni_intel.ko before running cryptsetup

[Steve Langasek]

*** This bug is a duplicate of bug 908387 ***
    https://bugs.launchpad.net/bugs/908387

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.

** Package changed: cryptsetup (Ubuntu) => linux (Ubuntu)

** This bug has been marked a duplicate of bug 908387
   Module aesni_intel not being loaded before mounting LVM2 stacked on LUKS

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/1058896

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

Status in “linux” package in Ubuntu:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1058896/+subscriptions