BMC/Intel-BMC/linux.git/arch/s390/crypto, branch dev

Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2015-05-22T21:26:36+00:00

Pull another crypto fix from Herbert Xu: "Fix ICV corruption in s390/ghash when the same tfm is used by more than one thread" * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: s390/ghash - Fix incorrect ghash icv buffer handling.

crypto: s390/ghash - Fix incorrect ghash icv buffer handling.

2015-05-22T03:23:03+00:00

Multitheaded tests showed that the icv buffer in the current ghash implementation is not handled correctly. A move of this working ghash buffer value to the descriptor context fixed this. Code is tested and verified with an multithreaded application via af_alg interface. Cc: stable@vger.kernel.org Signed-off-by: Harald Freudenberger Signed-off-by: Gerald Schaefer Reported-by: Herbert Xu Signed-off-by: Herbert Xu

s390/crypto: fix stckf loop

2015-05-13T07:57:38+00:00

The store-clock-fast loop in generate_entropy() mixes (exors) only the first 64 bytes of the initial page before doing the first SHA256. Fix the loop to mix the store-clock-fast values all over the page. Signed-off-by: Harald Freudenberger Reported-by: David Binderman Signed-off-by: Martin Schwidefsky

s390/zcrypt: Introduce new SHA-512 based Pseudo Random Generator.

2015-04-23T14:56:21+00:00

Rework of the prandom device with introduction of a new SHA-512 based NIST SP 800-90 conform deterministic random bit generator. Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky

s390: remove test_facility(2) (== z/Architecture mode active) checks

2015-03-25T10:49:37+00:00

Given that the kernel now always runs in 64 bit mode, it is pointless to check if the z/Architecture mode is active. Remove the checks. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/crypto: remove 'const' to avoid compiler warnings

2015-01-08T09:02:53+00:00

In aes_encrypt() and aes_decrypt(), need let 'sctx->key' be modified, so remove 'const' for it. The related warnings: CC [M] arch/s390/crypto/aes_s390.o arch/s390/crypto/aes_s390.c: In function 'aes_encrypt': arch/s390/crypto/aes_s390.c:146:37: warning: passing argument 2 of 'crypt_s390_km' discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] crypt_s390_km(KM_AES_128_ENCRYPT, &sctx->key, out, in, ^ ... In file included from arch/s390/crypto/aes_s390.c:29:0: arch/s390/crypto/crypt_s390.h:154:19: note: expected 'void *' but argument is of type 'const u8 (*)[32] {aka const unsigned char (*)[32]}' static inline int crypt_s390_km(long func, void *param, ^ Signed-off-by: Chen Gang Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

crypto: prefix module autoloading with "crypto-"

2014-11-24T14:43:57+00:00

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 Signed-off-by: Herbert Xu

crypto: s390 - fix aes,des ctr mode concurrency finding.

2014-05-08T13:46:09+00:00

An additional testcase found an issue with the last series of patches applied: the fallback solution may not save the iv value after operation. This very small fix just makes sure the iv is copied back to the walk/desc struct. Cc: # 3.14+ Signed-off-by: Harald Freudenberger Signed-off-by: Herbert Xu

crypto: s390 - fix des and des3_ede ctr concurrency issue

2014-01-30T13:45:14+00:00

In s390 des and 3des ctr mode there is one preallocated page used to speed up the en/decryption. This page is not protected against concurrent usage and thus there is a potential of data corruption with multiple threads. The fix introduces locking/unlocking the ctr page and a slower fallback solution at concurrency situations. Cc: stable@vger.kernel.org Signed-off-by: Harald Freudenberger Signed-off-by: Herbert Xu

crypto: s390 - fix des and des3_ede cbc concurrency issue

2014-01-30T13:45:11+00:00

In s390 des and des3_ede cbc mode the iv value is not protected against concurrency access and modifications from another running en/decrypt operation which is using the very same tfm struct instance. This fix copies the iv to the local stack before the crypto operation and stores the value back when done. Cc: stable@vger.kernel.org Signed-off-by: Harald Freudenberger Signed-off-by: Herbert Xu