[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)
;
#ifdef USE_PADLOCK
- 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
Signed-off-by.
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