linux/drivers/crypto, branch v4.7

crypto: qat - make qat_asym_algs.o depend on asn1 headers

2016-07-21T04:19:53Z

Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory #include "qat_rsapubkey-asn1.h" Cc: stable@vger.kernel.org Signed-off-by: Jan Stancek Signed-off-by: Herbert Xu

crypto: ux500 - memmove the right size

2016-06-13T09:43:05Z

The hash buffer is really HASH_BLOCK_SIZE bytes, someone must have thought that memmove takes n*u32 words by mistake. Tests work as good/bad as before after this patch. Cc: Joakim Bech Cc: stable@vger.kernel.org Reported-by: David Binderman Signed-off-by: Linus Walleij Signed-off-by: Herbert Xu

crypto: vmx - Increase priority of aes-cbc cipher

2016-06-13T09:43:05Z

All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at priority 1000. Unfortunately this means we never use AES-CBC and AES-CTR, because the base AES-CBC cipher that is implemented on top of AES inherits its priority. To fix this, AES-CBC and AES-CTR have to be a higher priority. Set them to 2000. Testing on a POWER8 with: cryptsetup benchmark --cipher aes --key-size 256 Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s, over 7x faster. Thanks to Mike Strosaker for helping me debug this issue. Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module") Cc: stable@vger.kernel.org Signed-off-by: Anton Blanchard Signed-off-by: Herbert Xu

crypto: vmx - Fix ABI detection

2016-06-13T09:43:04Z

When calling ppc-xlate.pl, we pass it either linux-ppc64 or linux-ppc64le. The script however was expecting linux64le, a result of its OpenSSL origins. This means we aren't obeying the ppc64le ABIv2 rules. Fix this by checking for linux-ppc64le. Fixes: 5ca55738201c ("crypto: vmx - comply with ABIs that specify vrsave as reserved.") Cc: stable@vger.kernel.org Signed-off-by: Anton Blanchard Signed-off-by: Herbert Xu

Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2016-05-30T22:20:18Z

Pull crypto fixes from Herbert Xu: "This fixes the following issues: - missing selection in public_key that may result in a build failure - Potential crash in error path in omap-sham - ccp AES XTS bug that affects requests larger than 4096" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ccp - Fix AES XTS error for request sizes above 4096 crypto: public_key: select CRYPTO_AKCIPHER crypto: omap-sham - potential Oops on error in probe

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11Z

Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann Cc: Andrzej Hajda Cc: Andrew Morton Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla # For nvmem part Signed-off-by: Linus Torvalds

crypto: ccp - Fix AES XTS error for request sizes above 4096

2016-05-25T10:33:47Z

The ccp-crypto module for AES XTS support has a bug that can allow requests greater than 4096 bytes in size to be passed to the CCP hardware. The CCP hardware does not support request sizes larger than 4096, resulting in incorrect output. The request should actually be handled by the fallback mechanism instantiated by the ccp-crypto module. Add a check to insure the request size is less than or equal to the maximum supported size and use the fallback mechanism if it is not. Cc: # 3.14.x- Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu

crypto: omap-sham - potential Oops on error in probe

2016-05-19T10:03:00Z

This if statement is reversed so we end up either leaking or Oopsing on error. Fixes: dbe246209bc1 ('crypto: omap-sham - Use dma_request_chan() for requesting DMA channel') Signed-off-by: Dan Carpenter Acked-by: Peter Ujfalusi Signed-off-by: Herbert Xu

crypto: qat - change the adf_ctl_stop_devices to void

2016-05-13T09:30:18Z

Change the adf_ctl_stop_devices to a void function. Signed-off-by: Tadeusz Struk Signed-off-by: Herbert Xu

crypto: caam - fix caam_jr_alloc() ret code

2016-05-10T09:49:21Z

caam_jr_alloc() used to return NULL if a JR device could not be allocated for a session. In turn, every user of this function used IS_ERR() function to verify if anything went wrong, which does NOT look for NULL values. This made the kernel crash if the sanity check failed, because the driver continued to think it had allocated a valid JR dev instance to the session and at some point it tries to do a caam_jr_free() on a NULL JR dev pointer. This patch is a fix for this issue. Cc: Signed-off-by: Catalin Vasile Signed-off-by: Herbert Xu