- 30 Jan, 2014 1 commit
-
-
Harald Freudenberger authored
The aes-ctr mode uses one preallocated page without any concurrency protection. When multiple threads run aes-ctr encryption or decryption this can lead to data corruption. The patch introduces locking for the page and a fallback solution with slower en/decryption performance in concurrency situations. Cc: stable@vger.kernel.org Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 28 Nov, 2013 1 commit
-
-
Gerald Schaefer authored
Some s390 crypto algorithms incorrectly use the crypto_tfm structure to store private data. As the tfm can be shared among multiple threads, this can result in data corruption. This patch fixes aes-xts by moving the xts and pcc parameter blocks from the tfm onto the stack (48 + 96 bytes). Cc: stable@vger.kernel.org Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 05 Nov, 2013 1 commit
-
-
Herbert Xu authored
The cbc-aes-s390 algorithm incorrectly places the IV in the tfm data structure. As the tfm is shared between multiple threads, this introduces a possibility of data corruption. This patch fixes this by moving the parameter block containing the IV and key onto the stack (the block is 48 bytes long). The same bug exists elsewhere in the s390 crypto system and they will be fixed in subsequent patches. Cc: stable@vger.kernel.org Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 24 Oct, 2013 1 commit
-
-
Ingo Tuchscherer authored
If a machine has no hardware support for the xts-aes or ctr-aes algorithms they are not registered in aes_s390_init. But aes_s390_fini unconditionally unregisters the algorithms which causes crypto_remove_alg to crash. Add two flag variables to remember if xts-aes and ctr-aes have been added. Signed-off-by:
Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 23 Nov, 2012 1 commit
-
-
Jan Glauber authored
Remove the BUG_ON's that check for failure or incomplete results of the s390 hardware crypto instructions. Rather report the errors as -EIO to the crypto layer. Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 01 Aug, 2012 1 commit
-
-
Jussi Kivilinna authored
Initialization of cra_list is currently mixed, most ciphers initialize this field and most shashes do not. Initialization however is not needed at all since cra_list is initialized/overwritten in __crypto_register_alg() with list_add(). Therefore perform cleanup to remove all unneeded initializations of this field in 'arch/s390/crypto/' Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: linux-s390@vger.kernel.org Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 20 Jul, 2012 1 commit
-
-
Heiko Carstens authored
Remove the file name from the comment at top of many files. In most cases the file name was wrong anyway, so it's rather pointless. Also unify the IBM copyright statement. We did have a lot of sightly different statements and wanted to change them one after another whenever a file gets touched. However that never happened. Instead people start to take the old/"wrong" statements to use as a template for new files. So unify all of them in one go. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com>
-
- 04 May, 2011 3 commits
-
-
Gerald Schaefer authored
This patch adds System z hardware acceleration support for AES, DES and 3DES in CTR mode. The hardware support is available starting with System z196. Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Gerald Schaefer authored
This patch adds System z hardware acceleration support for the AES XTS mode. The hardware support is available beginning with System z196. Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Jan Glauber authored
The specification which crypto facility is required for an algorithm is added as a parameter to the availability check which is done before an algorithm is registered. With this change it is easier to add new algorithms that require different facilities. Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 08 Jan, 2010 1 commit
-
-
Roel Kluin authored
The fallback code in cipher mode touch the union fallback.blk instead of fallback.cip. This is wrong because we use the cipher and not the blockcipher. This did not show any side effects yet because both types / structs contain the same element right now. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 18 Dec, 2009 1 commit
-
-
Roel Kluin authored
Return the PTR_ERR of the correct pointer. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 26 Feb, 2009 1 commit
-
-
Herbert Xu authored
With the mandatory algorithm testing at registration, we have now created a deadlock with algorithms requiring fallbacks. This can happen if the module containing the algorithm requiring fallback is loaded first, without the fallback module being loaded first. The system will then try to test the new algorithm, find that it needs to load a fallback, and then try to load that. As both algorithms share the same module alias, it can attempt to load the original algorithm again and block indefinitely. As algorithms requiring fallbacks are a special case, we can fix this by giving them a different module alias than the rest. Then it's just a matter of using the right aliases according to what algorithms we're trying to find. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 25 Dec, 2008 1 commit
-
-
Jan Glauber authored
Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 17 Apr, 2008 1 commit
-
-
Heiko Carstens authored
Not very helpful when code dies in "init". See also http://lkml.org/lkml/2008/3/26/557 . Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com>
-
- 26 Jan, 2008 1 commit
-
-
Joe Perches authored
Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 10 Jan, 2008 3 commits
-
-
Sebastian Siewior authored
crypto_blkcipher_decrypt is wrong because it does not care about the IV. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Sebastian Siewior authored
Some CPUs support only 128 bit keys in HW. This patch adds SW fallback support for the other keys which may be required. The generic algorithm (and the block mode) must be availble in case of a fallback. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Sebastian Siewior authored
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>
-
- 10 Oct, 2007 1 commit
-
-
Sebastian Siewior authored
Loading the crypto algorithm by the alias instead of by module directly has the advantage that all possible implementations of this algorithm are loaded automatically and the crypto API can choose the best one depending on its priority. Additionally it ensures that the generic implementation as well as the HW driver (if available) is loaded in case the HW driver needs the generic version as fallback in corner cases. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 04 May, 2007 1 commit
-
-
Jan Glauber authored
Register aes-s390 algorithms with the actual supported max keylen size Signed-off-by:
Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 05 Feb, 2007 2 commits
-
-
Jan Glauber authored
This patch moves the config options for the s390 crypto instructions to the standard "Hardware crypto devices" menu. In addition some cleanup has been done: use a flag for supported keylengths, add a warning about machien limitation, return ENOTSUPP in case the hardware has no support, remove superfluous printks and update email addresses. Signed-off-by:
Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Heiko Carstens authored
Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
- 21 Sep, 2006 4 commits
-
-
Herbert Xu authored
This patch removes obsolete block operations of the simple cipher type from drivers. These were preserved so that existing users can make a smooth transition. Now that the transition is complete, they are no longer needed. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
This patch adds block cipher algorithms for S390. Once all users of the old cipher type have been converted the existing CBC/ECB non-block cipher operations will be removed. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
Accelerated versions of crypto algorithms must carry a distinct driver name and priority in order to distinguish themselves from their generic counter- part. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
Now that the tfm is passed directly to setkey instead of the ctx, we no longer need to pass the &tfm->crt_flags pointer. This patch also gets rid of a few unnecessary checks on the key length for ciphers as the cipher layer guarantees that the key length is within the bounds specified by the algorithm. Rather than testing dia_setkey every time, this patch does it only once during crypto_alloc_tfm. The redundant check from crypto_digest_setkey is also removed. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 26 Jun, 2006 1 commit
-
-
Herbert Xu authored
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>
-
- 15 Jan, 2006 1 commit
-
-
Jan Glauber authored
Call KM[C] only with a multiple of block size. Check return value of KM[C] instructions and complain about erros Signed-off-by:
Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 06 Jan, 2006 1 commit
-
-
Jan Glauber authored
Add support for the hardware accelerated AES crypto algorithm. Signed-off-by:
Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-