Hi Jonas, 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 software implementation. 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 are there.) 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. Arno On Mon, Oct 24, 2011 at 01:30:56AM +0200, Jonas Meurer wrote: > Hello, > > In the Debian bugreport #639832 [1], 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. > > Greetings, > jonas > > [1] http://bugs.debian.org/639832 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
