Re: [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules

[Arno Wagner <arno@wagner.name>]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@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