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

David Holmer 1058896 at bugs.launchpad.net
Sun Sep 30 04:44:27 UTC 2012


Public bug reported:

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

** Affects: cryptsetup (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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 “cryptsetup” 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/cryptsetup/+bug/1058896/+subscriptions




More information about the foundations-bugs mailing list