From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QAO_Tb9CDPX for ; Mon, 24 Oct 2011 08:30:06 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 24 Oct 2011 08:30:05 +0200 (CEST) Message-ID: <4EA505E5.5080205@redhat.com> Date: Mon, 24 Oct 2011 08:29:57 +0200 From: Milan Broz MIME-Version: 1.0 References: <4EA4A3B0.3030000@freesources.org> In-Reply-To: <4EA4A3B0.3030000@freesources.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jonas Meurer Cc: dm-crypt On 10/24/2011 01:30 AM, Jonas Meurer wrote: > 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. If the modules are present at this time (either compiled-in or as separate modules) this seems to be kernel cryptoAPI bug. If it is not present (in intramfs) then available module is used and later it is not replaced by hw accelerated driver. Anyway, I am using aesni_intel loaded from Debian initramfs and it works with no hacks. Wonder what is the difference... (kernel 3.0.3 but compiled with own config to own kernel deb package.) > 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. I think it should load modules automatically according to its priorities (hw has always higher priority). Anyway, this is the question for linux-crypto (kernel) list. There is no way how to force dm-crypt load specific driver. Milan