AES assembler implementation for x86_64
RFC PATCH 4/4 AES assembler implementation for x86_64
The attached patch contains the required changes for the crypto Kconfig to enable the usage of the x86_64 AES assembler implementation.
Signature · 1 line
Andreas Steinmetz SPAMmers use [email protected]
crypto/Kconfig +22 -2
@@ -133,7 +133,7 @@ config CRYPTO_AES tristate "AES cipher algorithms" - depends on CRYPTO && !(X86 && !X86_64) + depends on CRYPTO && !X86 && !X86_64 help AES cipher algorithms (FIPS-197). AES uses the Rijndael algorithm.
@@ -153,7 +153,27 @@ config CRYPTO_AES_586 tristate "AES cipher algorithms (i586)" - depends on CRYPTO && (X86 && !X86_64) + depends on CRYPTO && X86 && !X86_64 + help + AES cipher algorithms (FIPS-197). AES uses the Rijndael + algorithm. + + Rijndael appears to be consistently a very good performer in + both hardware and software across a wide range of computing + environments regardless of its use in feedback or non-feedback + modes. Its key setup time is excellent, and its key agility is + good. Rijndael's very low memory requirements make it very well + suited for restricted-space environments, in which it also + demonstrates excellent performance. Rijndael's operations are + among the easiest to defend against power and timing attacks. + + The AES specifies three key sizes: 128, 192 and 256 bits + + See <http://csrc.nist.gov/encryption/aes/> for more information. + +config CRYPTO_AES_X86_64 + tristate "AES cipher algorithms (x86_64)" + depends on CRYPTO && X86 && X86_64 help AES cipher algorithms (FIPS-197). AES uses the Rijndael algorithm.
Quoted 2 lines · Andreas Steinmetz
The attached patch contains the required changes for the crypto
Kconfigto enable the usage of thex86_64AES assembler implementation.
That is not specifically against this patch, but before we add another AES implementation, I'd like to find a better solution for the general AES selection.
My original thoughts on this issue are in [1], but this didn't attack the problem of CRYPTO_DEV_PADLOCK_AES where it might not be known at compile time whether the hardware will be present.
crypto/Kconfig line 156
Quoted 11 lines
Andreas Steinmetz
diff -rNu linux-2.6.11.2.orig/crypto/Kconfig linux-2.6.11.2/crypto/Kconfig
crypto/Kconfig +1
-1config CRYPTO_AES_586 tristate "AES cipher algorithms (i586)" - depends on CRYPTO && (X86 && !X86_64) + depends on CRYPTO && X86 && !X86_64
This doesn't make any difference.
I think the former version was better readable, but that's no strong opinion.
cu
Adrian
[1] http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 3 lines · Adrian Bunk
That is not specifically against this patch, but before we add another AES implementation, I'd like to find a better solution for the general AES selection.
That would be nice as I didn't like having to duplicate a whole Kconfig entry which in fact means that it is triplicated now.
I'm fine with any solution here but I do believe whatever solution is for the crypto maintainers to decide.
[snip]
Quoted 9 lines
Review
Quoted 3 lines
(quoted diff) +2
-0+ depends on CRYPTO && (X86 && !X86_64) + depends on CRYPTO && X86 && !X86_64This doesn't make any difference.
I think the former version was better readable, but that's no strong opinion.
This was only personal preference during development and actually you're right, the former version is better readable.
Signature · 1 line
Andreas Steinmetz SPAMmers use [email protected]