All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Meurer <jonas@freesources.org>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules
Date: Mon, 24 Oct 2011 14:11:29 +0200	[thread overview]
Message-ID: <4EA555F1.9090506@freesources.org> (raw)
In-Reply-To: <20111024062115.GA5324@tansi.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 24.10.2011 08:21, schrieb Arno Wagner:
> Hi Jonas,

Hey Arno,

> 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.

Nope, the Debian distro-kernel has software implementation built into
the kernel, and hardware-accelerated drivers built as modules. So
according to Milans answers, the kernel crypto engine should load and
use the hardware-optimised drivers in case they're supported.

> 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 guess you're correct 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.

As I'm the maintainer of cryptsetup in Debian, I'm searching for a
solution for default setups. I know how to manually tweak setups to
use the hardware-optimized crypto drivers. But I need a solution for
the default setup with default distro-kernel. Thus building custom
kernels is out of scope in my case.

Greetings,
 jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOpVXxAAoJEFJi5/9JEEn+rAcP+gMbUNbx4/YkZzD2CEEUfJsr
QFgUth+B5znHs7YCo9ndR+uDNyiYu0/EQA9xvjvp/lz8ageynrCiawaClTfytIJW
lpA+qL89WX3gPtKIK/W8TKVor1ArWS6ZqzLZvO4avxt0bqTxfHRR7dilWgvtlWQt
AcA2VeiBwDp7JtTTyKSPgIFYaVDsWo/GhPShQ4fMMQOH0HeuyLOYUgcuP4TlKrPN
17U7AlfkMPwDc1asoMdyAev+0G+3NT8vY+0ppd+aiQygpEJgafJj+UrXjlEb8qBl
s8Byff44+FtyKVbG5q6njS6EWlTygwkVH2YJs5pSqNyJG+EALuj/Mwv8JAzefoYE
GoF1xImNJPLdWf5SfuWw8t+6pOEydtkSKIBAxvaNpTuB8T122iei+GI33RIkH8eR
q6cmdP9Kxau+Hsa6WEMB0fqjzNdekNdtzQHLKqEHjW9Fu4UekzKcV1bslU4hntvh
KA2UTCOxkmopLmWSty2dAfqgVALzSRLBJjC/V6bjWoY/vUCQDOFjexv2vIf4F4Zq
jISypLfsFytZQqOSTcd2gEBOOXEyua+D02Wq6H3SRzxqPRzxAPMFxAO1aVD/Y7lh
64cLd2bfEiDW+IgTUOQAAouOIVIWYRAsmFwEsmP+NDvLDf6b14cHs+Q2m5JY8exX
WP7+vC+GW4zyfxWEKoS8
=elNz
-----END PGP SIGNATURE-----

  reply	other threads:[~2011-10-24 12:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-23 23:30 [dm-crypt] [RFC] dm-crypt and hardware-optimized crypto modules Jonas Meurer
2011-10-24  6:21 ` Arno Wagner
2011-10-24 12:11   ` Jonas Meurer [this message]
2011-10-24 14:25     ` Arno Wagner
2011-10-24  6:29 ` Milan Broz
2011-10-24  6:42   ` Arno Wagner
2011-10-24 12:05   ` Jonas Meurer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EA555F1.9090506@freesources.org \
    --to=jonas@freesources.org \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.