[PATCH] Enable VIA Padlock on x86_64 platforms

Rafaël Carré funman at videolan.org
Thu Apr 19 18:22:11 CEST 2012

Le 2012-04-12 06:23, Werner Koch a écrit :
> On Wed, 11 Apr 2012 13:03, funman at videolan.org said:
>> After starting to understand what is this mode, I noticed it also failed
>> on 32 bits and just gave up on it, hoping that someone (the padlock code
>> author?) could explain it.
> That's me.  It can't be specific to the padlock code because the
> _gcry_aes_ctr_enc diverts only for AESNI; the default code path is used
> by all other CPUs.

I tried the test suite on your commit introducing PADLOCK code and it
worked, so I spent some time bisecting:

2674140cdfdc59ce5ad0238177da1542f5df6e00 is the first bad commit
commit 2674140cdfdc59ce5ad0238177da1542f5df6e00
Author: Werner Koch <wk at gnupg.org>
Date:   Tue Feb 22 16:08:13 2011 +0100

    Use AES-NI insns for CTR mode.

    That really boosts the performance of CTR.

:100644 100644 ffbdc840c4f74f2866b3179aab232b93ef28dc8a
979ad403e920229d48417e0e41cf3ebf5e9dede0 M	NEWS
:040000 040000 c7ae1843e27728fcb5e7e54d771b68e665fbd822
af64d30472d52e93bad24ca16b2f45205e90340a M	cipher
:100644 100644 a28ea8383ce4b86b7f19aa649143361457d7a640
013ff3af4279e36ed3021e7f6d4b679eabc77bfe M	configure.ac
:040000 040000 23af7cde7dcf6806caa4a907dc6bdb0addaa910f
e027fe7032c7752a94369e34d6736c6734410ceb M	src

I could fix the test suite with the following diff:

diff --git a/cipher/rijndael.c b/cipher/rijndael.c
index 2df8ea9..c7320a4 100644
--- a/cipher/rijndael.c
+++ b/cipher/rijndael.c
@@ -282,7 +282,7 @@ do_setkey (RIJNDAEL_context *ctx, const byte *key,
const unsigned keylen)
   if (0)
-  else if (ctx->use_padlock)
+  else if (0 && ctx->use_padlock)
       /* Nothing to do as we support only hardware key generation for
          now.  */

I believe the correct fix would be to use the padlock for all cipher modes.

Is there a reason why it's not used for CTR?

With this one-liner, the test suite now passes in both 32bits and 64bits
with the patch I previously sent, so I'm resending that one again with a

Btw, thanks for relaxing the requirement on a copyright assignement, I
was already preparing my defense that this code was not mine but instead
a mere copy of 32bits asm code with non-copyrightable very small and
obvious changes.

More information about the Gcrypt-devel mailing list