[Bug 908387] Re: Module aesni_intel not being loaded before mounting LVM2 stacked on LUKS

Sun Sep 30 21:16:38 UTC 2012

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.

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

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

Title:
  Module aesni_intel not being loaded before mounting LVM2 stacked on
  LUKS

Status in “cryptsetup” package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I've made an installation of Ubuntu 11.10 on a system with AES-NI instructions only to find that the aesni_intel module is not being loaded before mounting the root file system, leaving the system with software encryption instead of using the hardware capabilities.

  The problem I think it's due to the modules not existing on the
  initramfs. Naturally, aes_x86_64 and cryptd modules aren't loaded too.

  Having the kernel compiled with options
  CONFIG_CRYPTO_AES=y
  CONFIG_CRYPTO_AES_X86_64=y
  CONFIG_CRYPTO_AES_NI_INTEL=y

  instead of

  CONFIG_CRYPTO_AES=y
  CONFIG_CRYPTO_AES_X86_64=m
  CONFIG_CRYPTO_AES_NI_INTEL=m

  as it appears on "config-3.0.0-14-generic" in the /boot directory
  should be OK too.

  I can manually load those modules after the system boots, but then
  it's not useful for my fully encrypted filesystem.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: linux-image (not installed)
  ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
  Uname: Linux 3.0.0-14-generic x86_64
  AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
  ApportVersion: 1.23-0ubuntu4
  Architecture: amd64
  ArecordDevices:
   **** List of CAPTURE Hardware Devices ****
   card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
     Subdevices: 1/1
     Subdevice #0: subdevice #0
  AudioDevicesInUse:
   USER        PID ACCESS COMMAND
   /dev/snd/controlC0:  raul       1706 F.... pulseaudio
  CRDA: Error: [Errno 2] No existe el archivo o el directorio
  Card0.Amixer.info:
   Card hw:0 'PCH'/'HDA Intel PCH at 0xdf000000 irq 49'
     Mixer name	: 'Intel CougarPoint HDMI'
     Components	: 'HDA:10ec0269,10431063,00100100 HDA:80862805,80860101,00100000'
     Controls      : 22
     Simple ctrls  : 12
  Date: Sat Dec 24 14:06:12 2011
  HibernationDevice: RESUME=UUID=968e95f3-010c-4925-976d-6af33e7c279b
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
  MachineType: ASUSTeK Computer Inc. N53SN
  ProcEnviron:
   PATH=(custom, no user)
   LANG=es_ES.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.0.0-14-generic root=/dev/mapper/ubunturoot-raiz ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.0.0-14-generic N/A
   linux-backports-modules-3.0.0-14-generic  N/A
   linux-firmware                            1.60
  SourcePackage: linux
  StagingDrivers: mei
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/10/2011
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: N53SN.208
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: N53SN
  dmi.board.vendor: ASUSTeK Computer Inc.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK Computer Inc.
  dmi.chassis.version: 1.0
  dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrN53SN.208:bd08/10/2011:svnASUSTeKComputerInc.:pnN53SN:pvr1.0:rvnASUSTeKComputerInc.:rnN53SN:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
  dmi.product.name: N53SN
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK Computer Inc.

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