summaryrefslogtreecommitdiffstats
path: root/arch/x86_64/crypto
Commit message (Collapse)AuthorAgeFilesLines
* [CRYPTO] aes: Add wrappers for assembly routinesHerbert Xu2006-06-262-6/+16
| | | | | | | | | The wrapper routines are required when asmlinkage differs from the usual calling convention. So we need to have them. However, by rearranging the parameters, they will get optimised away to a single jump for most people. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] all: Pass tfm instead of ctx to algorithmsHerbert Xu2006-06-262-12/+16
| | | | | | | | | | | | | | | | Up until now algorithms have been happy to get a context pointer since they know everything that's in the tfm already (e.g., alignment, block size). However, once we have parameterised algorithms, such information will be specific to each tfm. So the algorithm API needs to be changed to pass the tfm structure instead of the context pointer. This patch is basically a text substitution. The only tricky bit is the assembly routines that need to get the context pointer offset through asm-offsets.h. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] aes: Fixed array boundary violationDavid McCullough2006-03-211-4/+3
| | | | | | | | | | | | | | The AES setkey routine writes 64 bytes to the E_KEY area even though there are only 60 bytes there. It is in fact safe since E_KEY is immediately follwed by D_KEY which is initialised afterwards. However, doing this may trigger undefined behaviour and makes Coverity unhappy. So by combining E_KEY and D_KEY into one array we sidestep this issue altogether. This problem was reported by Adrian Bunk. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] Allow AES C/ASM implementations to coexistHerbert Xu2006-01-091-0/+2
| | | | | | | | | | | | As the Crypto API now allows multiple implementations to be registered for the same algorithm, we no longer have to play tricks with Kconfig to select the right AES implementation. This patch sets the driver name and priority for all the AES implementations and removes the Kconfig conditions on the C implementation for AES. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] Use standard byte order macros wherever possibleHerbert Xu2006-01-091-12/+11
| | | | | | | | | | | A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [PATCH] x86_64: add MODULE_ALIAS for aesOlaf Hering2005-08-081-0/+1
| | | | | | | | | modprobe aes does not work on x86_64. i386 has a similar line, this could be the right fix. Would be nice to have in 2.6.13 final. Signed-off-by: Olaf Hering <olh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [CRYPTO] Add x86_64 asm AESAndreas Steinmetz2005-07-063-0/+519
Implementation: =============== The encrypt/decrypt code is based on an x86 implementation I did a while ago which I never published. This unpublished implementation does include an assembler based key schedule and precomputed tables. For simplicity and best acceptance, however, I took Gladman's in-kernel code for table generation and key schedule for the kernel port of my assembler code and modified this code to produce the key schedule as required by my assembler implementation. File locations and Kconfig are kept similar to the i586 AES assembler implementation. It may seem a little bit strange to use 32 bit I/O and registers in the assembler implementation but this gives the best code size. My implementation takes one instruction more per round compared to Gladman's x86 assembler but it doesn't require any stack for local variables or saved registers and it is less serialized than Gladman's code. Note that all comparisons to Gladman's code were done after my code was implemented. I did only use FIPS PUB 197 for the implementation so my implementation is independent work. If anybody has a better assembler solution for x86_64 I'll be pleased to have my code replaced with the better solution. Testing: ======== The implementation passes the in-kernel crypto testing module and I'm running it without any problems on my laptop where it is mainly used for dm-crypt. Microbenchmark: =============== The microbenchmark was done in userspace with similar compile flags as used during kernel compile. Encrypt/decrypt is about 35% faster than the generic C implementation. As the generic C as well as my assembler implementation are both table I don't really expect that there is much room for further improvements though I'll be glad to be corrected here. The key schedule is about 5% slower than the generic C implementation. This is due to the fact that some more work has to be done in the key schedule routine to fit the schedule to the assembler implementation. Code Size: ========== Encrypt and decrypt are together about 2.1 Kbytes smaller than the generic C implementation which is important with regard to L1 cache usage. The key schedule routine is about 100 bytes larger than the generic C implementation. Data Size: ========== There's no difference in data size requirements between the assembler implementation and the generic C implementation. License: ======== Gladmans's code is dual BSD/GPL whereas my assembler code is GPLv2 only (I'm not going to change the license for my code). So I had to change the module license for the x86_64 aes module from 'Dual BSD/GPL' to 'GPL' to reflect the most restrictive license within the module. Signed-off-by: Andreas Steinmetz <ast@domdv.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
OpenPOWER on IntegriCloud