kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-10-16 22:39:48 +00:00
Code Issues Releases Packages Activity
linux/crypto/aes_generic.c

1478 lines
62 KiB
Raw Permalink Normal View History

crypto: aes_generic - Fix checkpatch errors Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-02-16 20:34:59 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes: Move common defines into a header file This three defines are used in all AES related hardware. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-17 23:18:57 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: make tables used from assembler __visible Tables used from assembler should be marked __visible to let the compiler know. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-10 18:01:11 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: aes - Precompute tables The tables used by the various AES algorithms are currently computed at run-time. This has created an init ordering problem because some AES algorithms may be registered before the tables have been initialised. This patch gets around this whole thing by precomputing the tables. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25 11:05:13 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: aes_generic - Fix checkpatch errors Signed-off-by: Richard Hartmann <richih.mailinglist@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-02-16 20:34:59 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
crypto: aes - Undefined behaviour in crypto_aes_expand_key It's undefined behaviour in C to write outside the bounds of an array. The key expansion routine takes a shortcut of creating 8 words at a time, but this creates 4 additional words which don't fit in the array. As everyone is hopefully now aware, GCC is at liberty to make any assumptions and optimisations it likes in situations where it can detect that UB has occured, up to and including nasal demons, and as the indices being accessed in the array are trivially calculable, it's rash to invite gcc to do take any liberties at all. Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-07-24 13:59:17 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
crypto: aes - Undefined behaviour in crypto_aes_expand_key It's undefined behaviour in C to write outside the bounds of an array. The key expansion routine takes a shortcut of creating 8 words at a time, but this creates 4 additional words which don't fit in the array. As everyone is hopefully now aware, GCC is at liberty to make any assumptions and optimisations it likes in situations where it can detect that UB has occured, up to and including nasal demons, and as the indices being accessed in the array are trivially calculable, it's rash to invite gcc to do take any liberties at all. Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-07-24 13:59:17 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes: Export generic setkey The key expansion routine could be get little more generic, become a kernel doc entry and then get exported. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-01 20:58:51 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] Use standard byte order macros wherever possible 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>
2005-10-30 21:25:15 +11:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes: Export generic setkey The key expansion routine could be get little more generic, become a kernel doc entry and then get exported. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-01 20:58:51 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes: Export generic setkey The key expansion routine could be get little more generic, become a kernel doc entry and then get exported. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-01 20:58:51 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes: Export generic setkey The key expansion routine could be get little more generic, become a kernel doc entry and then get exported. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-01 20:58:51 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes: Export generic setkey The key expansion routine could be get little more generic, become a kernel doc entry and then get exported. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-01 20:58:51 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
crypto: aes - Undefined behaviour in crypto_aes_expand_key It's undefined behaviour in C to write outside the bounds of an array. The key expansion routine takes a shortcut of creating 8 words at a time, but this creates 4 additional words which don't fit in the array. As everyone is hopefully now aware, GCC is at liberty to make any assumptions and optimisations it likes in situations where it can detect that UB has occured, up to and including nasal demons, and as the indices being accessed in the array are trivially calculable, it's rash to invite gcc to do take any liberties at all. Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-07-24 13:59:17 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
crypto: aes - Undefined behaviour in crypto_aes_expand_key It's undefined behaviour in C to write outside the bounds of an array. The key expansion routine takes a shortcut of creating 8 words at a time, but this creates 4 additional words which don't fit in the array. As everyone is hopefully now aware, GCC is at liberty to make any assumptions and optimisations it likes in situations where it can detect that UB has occured, up to and including nasal demons, and as the indices being accessed in the array are trivially calculable, it's rash to invite gcc to do take any liberties at all. Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-07-24 13:59:17 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes: Export generic setkey The key expansion routine could be get little more generic, become a kernel doc entry and then get exported. Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Tested-by: Stefan Hellermann <stefan@the2masters.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-01 20:58:51 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] all: Pass tfm instead of ctx to algorithms 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>
2006-05-16 22:09:29 +10:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] Use standard byte order macros wherever possible 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>
2005-10-30 21:25:15 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] Use standard byte order macros wherever possible 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>
2005-10-30 21:25:15 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] all: Pass tfm instead of ctx to algorithms 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>
2006-05-16 22:09:29 +10:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] Use standard byte order macros wherever possible 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>
2005-10-30 21:25:15 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] Use standard byte order macros wherever possible 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>
2005-10-30 21:25:15 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] Allow AES C/ASM implementations to coexist 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>
2005-11-05 18:06:26 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] cipher: Set alignmask for multi-byte loads Many cipher implementations use 4-byte/8-byte loads/stores which require alignment on some architectures. This patch explicitly sets the alignment requirements for them. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-01-07 16:38:15 +11:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] aes-generic: Make key generation exportable This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 21:20:30 +08:00
[CRYPTO] aes-generic: Coding style cleanup Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08 20:39:26 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: prefix module autoloading with "crypto-" This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-11-20 17:05:53 -08:00
crypto: add missing crypto module aliases Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"") changed the automatic module loading when requesting crypto algorithms to prefix all module requests with "crypto-". This requires all crypto modules to have a crypto specific module alias even if their file name would otherwise match the requested crypto algorithm. Even though commit 5d26a105b5a7 added those aliases for a vast amount of modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO annotations to those files to make them get loaded automatically, again. This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work with kernels v3.18 and below. Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former won't work for crypto modules any more. Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"") Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-01-11 18:17:42 +01:00