Hello.
I'm pleased to announce asynchronous crypto layer (acrypto) [1] release
for 2.6.18 kernel tree. Acrypto allows to handle crypto requests
asynchronously in hardware.
Combined patchset includes:
* acrypto core
* IPsec ESP4 port to acrypto
* dm-crypt port to acrypto
* OCF to acrypto bridge
Acrypto supports following crypto providers:
* SW crypto provider
* HIFN 795x adapters
* VIA nehemiah CPU
* SuperCrypt CE99C003B
* devices supported by OCF
With this release of combined patchset for 2.6.18 I drop feature
extensions for 2.6.16 and 2.6.17 trees and move them into maintenance
state.
Combined patchset [190k] and drivers for various acrypto providers can
be found on project's homepage.
1. Acrypto homepage.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=acrypto
Signed-off-by: Evgeniy Polyakov <[email protected]>
--
Evgeniy Polyakov
--
Evgeniy Polyakov
Evgeniy Polyakov wrote:
> Hello.
>
> I'm pleased to announce asynchronous crypto layer (acrypto) [1] release
> for 2.6.18 kernel tree. Acrypto allows to handle crypto requests
> asynchronously in hardware.
>
> Combined patchset includes:
> * acrypto core
> * IPsec ESP4 port to acrypto
> * dm-crypt port to acrypto
so I should be able to replace a plain 2.6.18 kernel with one
with this patchset and use dm-crypt'ed partitions (e.g. swap,
encrypted root filesystem) as usual without further changes?
Did anyone test this with success?
Regards, Andreas
On Thu, Sep 28, 2006 at 03:23:43PM +0200, Andreas Jellinghaus ([email protected]) wrote:
> >I'm pleased to announce asynchronous crypto layer (acrypto) [1] release
> >for 2.6.18 kernel tree. Acrypto allows to handle crypto requests
> >asynchronously in hardware.
> >
> >Combined patchset includes:
> > * acrypto core
> > * IPsec ESP4 port to acrypto
> > * dm-crypt port to acrypto
>
> so I should be able to replace a plain 2.6.18 kernel with one
> with this patchset and use dm-crypt'ed partitions (e.g. swap,
> encrypted root filesystem) as usual without further changes?
Yes.
> Did anyone test this with success?
Except me, I think...
That code was used for OCF dm-crypt port some time ago (I recall it was
Marvell), so the whole base is not limited by acrypto only.
I can only say that there are users out there which use acrypto without
pointing exact names naturally. I agree that it does not sound very
strong, but actually I'm not going to convince someone, I just establish
a fact.
> Regards, Andreas
--
Evgeniy Polyakov
On Thu, Sep 28, 2006 at 03:23:43PM +0200, Andreas Jellinghaus ([email protected]) wrote:
> Evgeniy Polyakov wrote:
> >Hello.
> >
> >I'm pleased to announce asynchronous crypto layer (acrypto) [1] release
> >for 2.6.18 kernel tree. Acrypto allows to handle crypto requests
> >asynchronously in hardware.
> >
> >Combined patchset includes:
> > * acrypto core
> > * IPsec ESP4 port to acrypto
> > * dm-crypt port to acrypto
>
> so I should be able to replace a plain 2.6.18 kernel with one
> with this patchset and use dm-crypt'ed partitions (e.g. swap,
> encrypted root filesystem) as usual without further changes?
>
> Did anyone test this with success?
>
> Regards, Andreas
As I answered in your first e-mail, yes, you just need to patch 2.6.18
tree and load one of the crypto provider.
Acrypto works with request/response model, i.e. you ask acrypto core to
perform some operation on given buffers and if it can, it will call
your callback when it is ready (or some error happend and acrypto was
unable to reroute request to other device), otherwise it will return error.
With such a model it is possible to extend acrypto to any kind of
operations on buffers, not only crypto related, for example it is
possible to onload IPsec header transformation, perform DMA between
specified areas and much more.
--
Evgeniy Polyakov
>>>>> "Evgeniy" == Evgeniy Polyakov <[email protected]> writes:
Evgeniy> Hello. I'm pleased to announce asynchronous crypto layer
Evgeniy> (acrypto) [1] release for 2.6.18 kernel tree. Acrypto allows
Evgeniy> to handle crypto requests asynchronously in hardware.
Would userspace programs benefit from this patch? In particular, would
OpenSSL get better performances on Via nehemiah CPUs or does it need
to be patched?
Sam
--
Samuel Tardieu -- [email protected] -- http://www.rfc1149.net/
On Fri, Sep 29, 2006 at 12:17:58PM +0200, Samuel Tardieu ([email protected]) wrote:
> >>>>> "Evgeniy" == Evgeniy Polyakov <[email protected]> writes:
>
> Evgeniy> Hello. I'm pleased to announce asynchronous crypto layer
> Evgeniy> (acrypto) [1] release for 2.6.18 kernel tree. Acrypto allows
> Evgeniy> to handle crypto requests asynchronously in hardware.
>
> Would userspace programs benefit from this patch? In particular, would
> OpenSSL get better performances on Via nehemiah CPUs or does it need
> to be patched?
Userspace supports Via Nehemiah CPUs crypto engine quite for a long time
without any external patching.
> Sam
> --
> Samuel Tardieu -- [email protected] -- http://www.rfc1149.net/
--
Evgeniy Polyakov
For the best synergy with OpenBSD guys, the OCF API should be considered:
http://www.usenix.org/events/usenix03/tech/full_papers/keromytis/keromytis_html/node8.html
then, whatever a HW driver is added, the same IOCTLs will be used by
OpenSSL. The OCF patch for OpenSSL is already available.
Currently, it is not into the kernel git's repository so I think that
your Via CPU won't get better performances with OpenSSL
Regards,
Vincent
Samuel Tardieu wrote:
>Evgeniy> Hello. I'm pleased to announce asynchronous crypto layer
>Evgeniy> (acrypto) [1] release for 2.6.18 kernel tree. Acrypto allows
>Evgeniy> to handle crypto requests asynchronously in hardware.
>
>Would userspace programs benefit from this patch? In particular, would
>OpenSSL get better performances on Via nehemiah CPUs or does it need
>to be patched?
>
> Sam
>
>
Hi,
I finally got around testing 2.6.18.1 + acrypto.
but it "does not work" - I usualy boot, enter my
passphrases for rsa key / openssl decrypts some random
bytes with them, and a hex version of those random bytes
is used with dm-setup to initialize a dm-crypt mapping
which again is used for mounting root and swap (or
resume in case it has a suspend image on them).
but with the acrypto patched kernel the system freezes
without any response. the script in the initramfs is not
"set +x" so I'm not sure which command causes the freeze,
so I guess it is either the dm-setup, the resume trigger
(echo to a file in /sys/) or the mount for root or the
swapon.
> As I answered in your first e-mail, yes, you just need to patch 2.6.18
> tree and load one of the crypto provider.
what exactly would be "load one of the crypto providers"?
+# Asynchronous crypto layer
+#
+CONFIG_ACRYPTO=y
+CONFIG_ASYNC_PROVIDER=y
+# CONFIG_CONSUMER is not set
+# CONFIG_ASYNC2OCF_BRIDGE is not set
+
+#
this change to .config should be enough
(ok, 2.6.18.1 also enabled CONFIG_CONNECTOR and CONFIG_PROC_EVENTS).
I documented the setup of my laptop with encryption here:
https://help.ubuntu.com/community/EncryptedFilesystemHowto4
and I can post kernel config etc. if it helps. there was no
kernel message when the machine froze (or more like waiting
for something forever - ctrl-alt-del still worked fine).
note: kernel 2.6.18 was working fine, I didn't try 2.6.18.1
without acrypto changes, but I guess that isn't the issues.
still if you think otherwise, I can give it a try. if there
is some boot option to disable acrypto so dm-crypt will work
as if compiled without acrypto, I would try that too.
is there such an option?
Thanks, Andreas
On Thu, Oct 19, 2006 at 05:04:19PM +0200, Andreas Jellinghaus ([email protected]) wrote:
> Hi,
>
> I finally got around testing 2.6.18.1 + acrypto.
> but it "does not work" - I usualy boot, enter my
> passphrases for rsa key / openssl decrypts some random
> bytes with them, and a hex version of those random bytes
> is used with dm-setup to initialize a dm-crypt mapping
> which again is used for mounting root and swap (or
> resume in case it has a suspend image on them).
>
> but with the acrypto patched kernel the system freezes
> without any response. the script in the initramfs is not
> "set +x" so I'm not sure which command causes the freeze,
> so I guess it is either the dm-setup, the resume trigger
> (echo to a file in /sys/) or the mount for root or the
> swapon.
>
> >As I answered in your first e-mail, yes, you just need to patch 2.6.18
> >tree and load one of the crypto provider.
>
> what exactly would be "load one of the crypto providers"?
> +# Asynchronous crypto layer
> +#
> +CONFIG_ACRYPTO=y
> +CONFIG_ASYNC_PROVIDER=y
> +# CONFIG_CONSUMER is not set
> +# CONFIG_ASYNC2OCF_BRIDGE is not set
> +
> +#
> this change to .config should be enough
> (ok, 2.6.18.1 also enabled CONFIG_CONNECTOR and CONFIG_PROC_EVENTS).
Both are not required.
> I documented the setup of my laptop with encryption here:
> https://help.ubuntu.com/community/EncryptedFilesystemHowto4
>
> and I can post kernel config etc. if it helps. there was no
> kernel message when the machine froze (or more like waiting
> for something forever - ctrl-alt-del still worked fine).
>
> note: kernel 2.6.18 was working fine, I didn't try 2.6.18.1
> without acrypto changes, but I guess that isn't the issues.
> still if you think otherwise, I can give it a try. if there
> is some boot option to disable acrypto so dm-crypt will work
> as if compiled without acrypto, I would try that too.
> is there such an option?
If acrypto fails it should automatically switch to sw synchronous mode.
Could you enable debug mode in include/linux/acrypto.h:54 - uncommend
//#define DEBUG
recompile the kernel and give it a try, so I could check where it stops.
Btw, async provider only supports AES-128 in CBC mode, so if you try
different ciphers, there can be some problems.
Thank you.
> Thanks, Andreas
--
Evgeniy Polyakov
> Btw, async provider only supports AES-128 in CBC mode, so if you try
> different ciphers, there can be some problems.
my code does
SECTORS=`blockdev --getsize /dev/hda3`
echo 0 $SECTORS crypt aes-cbc-essiv:sha256 $ROOTKEY 0 /dev/hda3 0 \
|dmsetup create root
so this is not compatible with acrypto I guess :(
any special reason why acrypto is limited this way?
guess that limitation needs to go away before it can be added to
the linux kernel, or some workaround so dm-crypt will fall back on
not using acrypto or something like that in order to not brake existing
and working installations.
Thanks, Andreas
On Fri, Oct 20, 2006 at 03:34:40PM +0200, Andreas Jellinghaus ([email protected]) wrote:
> >Btw, async provider only supports AES-128 in CBC mode, so if you try
> >different ciphers, there can be some problems.
>
> my code does
>
> SECTORS=`blockdev --getsize /dev/hda3`
>
> echo 0 $SECTORS crypt aes-cbc-essiv:sha256 $ROOTKEY 0 /dev/hda3 0 \
> |dmsetup create root
>
> so this is not compatible with acrypto I guess :(
> any special reason why acrypto is limited this way?
I'm lazy and I did not implemented async provider so it would request
other ciphers. It is not limitation of acrypto, but instead of software
async_provider, which should be extended to support any kind of ciphers,
instead of precompiled one.
> guess that limitation needs to go away before it can be added to
> the linux kernel, or some workaround so dm-crypt will fall back on
> not using acrypto or something like that in order to not brake existing
> and working installations.
Well, I guess async_provider itself should go away, instead I will
change synchronous cryptoapi code to register itself as acrypto device
when new tfm is created.
> Thanks, Andreas
--
Evgeniy Polyakov