[dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules
arno at wagner.name
Mon Oct 24 08:21:16 CEST 2011
the definite authority on this is Milan, but as far as I
understand module autoloading, as long as an implementation
for a requested cipher is already loaded, that will be used.
Now, I expect it would be possible to not build the normal
AES module and thereby have the HW-supported AES module loade
automatically when needed. As the Debian distro-kernel cannot
know HW-support would be there, it obviously defaults to the
AFAIK, if both HW and SW support are loaded, HW support
is used as default. I think there is some kind of priority
system in place. But I am really only guessing here.
I see two ways around this:
1. Load the HW module manually (or scripted).
While I have not used a Debian Distro kernel for a long
time, I think adding the HW-module to /etc/modules
should accomplish that. Noneed to mess with the initrd,
unless possibly if you have encrypted root.
2. Roll your own kernel, possibly with HW support statically
compiled in. I have used Debian with kernels from kernel.org
and module-support turned off with good success for about
10 years now. (I don't like initrds. Good for distros, but
they complicate things and complexity is the enemy of reliablity
and efficiency. Also, I like to mess around with my installatons
and initrds make that harder. I also do not like to use kernel
modules very much, although it is definitely good that they
To use your own kernel with Debian, just boot it and tell it
the root partition. Of course you have to make sure it somehow
has the drivers it needs to fnd and mount the root partition.
On Mon, Oct 24, 2011 at 01:30:56AM +0200, Jonas Meurer wrote:
> In the Debian bugreport #639832 , Simon Mackinlay pointed out, that
> hardware-optimized crypto driver modules aren't loaded automatically
> at cryptsetup invokation in the boot process (initramfs) in Debian.
> I verified this. At least for setups with aes support compiled into
> the kernel, and hardware-optimized aes drivers (aes-x86_64,
> aesni-intel) built as modules (which is the default for Debian and
> Ubuntu kernels), the hardware-optimized aes modules aren't loaded at
> cryptsetup invokation. (Sure, this is tested with aes-encrypted
> volumes.) I didn't have time to check other setups (e.g. everything
> built as modules) yet.
> Is this behaviour intended, or should the kernel select
> hardware-optimized drivers by default in case they're available (even
> as modules) and supported by hardware?
> I'm happy to extend the initramfs scripts to load hardware-optimized
> modules in case they're available before cryptsetup is invoked. But
> that an implementation would be ugly and hard to maintain as it needs
> to be updated for possible kernel crypto driver changes. I would
> prefer a solution where the kernel crypto api took responsibility for
> this task.
>  http://bugs.debian.org/639832
> dm-crypt mailing list
> dm-crypt at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
More information about the dm-crypt