linux/drivers/crypto/inside-secure, branch v5.9

crypto: inside-secure - irq balance

2020-07-31T08:08:59Z

Balance the irqs of the inside secure driver over all available cpus. Currently all interrupts are handled by the first CPU. From my testing with IPSec AES-GCM 256 on my MCbin with 4 Cores I get a 50% speed increase: Before the patch: 99.73 Kpps With the patch: 151.25 Kpps Signed-off-by: Sven Auhagen Signed-off-by: Herbert Xu

crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY

2020-07-16T11:49:10Z

Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that allocate memory. drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c: sun8i_ce_cipher drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c: sun8i_ss_cipher drivers/crypto/amlogic/amlogic-gxl-core.c: meson_cipher drivers/crypto/axis/artpec6_crypto.c: artpec6_crypto_common_init drivers/crypto/bcm/cipher.c: spu_skcipher_rx_sg_create drivers/crypto/caam/caamalg.c: aead_edesc_alloc drivers/crypto/caam/caamalg_qi.c: aead_edesc_alloc drivers/crypto/caam/caamalg_qi2.c: aead_edesc_alloc drivers/crypto/caam/caamhash.c: hash_digest_key drivers/crypto/cavium/cpt/cptvf_algs.c: process_request drivers/crypto/cavium/nitrox/nitrox_aead.c: nitrox_process_se_request drivers/crypto/cavium/nitrox/nitrox_skcipher.c: nitrox_process_se_request drivers/crypto/ccp/ccp-crypto-aes-cmac.c: ccp_do_cmac_update drivers/crypto/ccp/ccp-crypto-aes-galois.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-aes-xts.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-aes.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-des3.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-sha.c: ccp_crypto_enqueue_request drivers/crypto/chelsio/chcr_algo.c: create_cipher_wr drivers/crypto/hisilicon/sec/sec_algs.c: sec_alloc_and_fill_hw_sgl drivers/crypto/hisilicon/sec2/sec_crypto.c: sec_alloc_req_id drivers/crypto/inside-secure/safexcel_cipher.c: safexcel_queue_req drivers/crypto/inside-secure/safexcel_hash.c: safexcel_ahash_enqueue drivers/crypto/ixp4xx_crypto.c: ablk_perform drivers/crypto/marvell/cesa/cipher.c: mv_cesa_skcipher_dma_req_init drivers/crypto/marvell/cesa/hash.c: mv_cesa_ahash_dma_req_init drivers/crypto/marvell/octeontx/otx_cptvf_algs.c: create_ctx_hdr drivers/crypto/n2_core.c: n2_compute_chunks drivers/crypto/picoxcell_crypto.c: spacc_sg_to_ddt drivers/crypto/qat/qat_common/qat_algs.c: qat_alg_skcipher_encrypt drivers/crypto/qce/skcipher.c: qce_skcipher_async_req_handle drivers/crypto/talitos.c : talitos_edesc_alloc drivers/crypto/virtio/virtio_crypto_algs.c: __virtio_crypto_skcipher_do_req drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher Signed-off-by: Mikulas Patocka [EB: avoid overly-long lines] Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: remove propagation of CRYPTO_TFM_RES_* flags

2020-01-09T03:30:53Z

The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the ->setkey() functions provide more information about errors. But these flags weren't actually being used or tested, and in many cases they weren't being set correctly anyway. So they've now been removed. Also, if someone ever actually needs to start better distinguishing ->setkey() errors (which is somewhat unlikely, as this has been unneeded for a long time), we'd be much better off just defining different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that propagates these flags around. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN

2020-01-09T03:30:53Z

The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. Also, many algorithms fail to set this flag when given a bad length key. Reviewing just the generic implementations, this is the case for aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably many more in arch/*/crypto/ and drivers/crypto/. Some algorithms can even set this flag when the key is the correct length. For example, authenc and authencesn set it when the key payload is malformed in any way (not just a bad length), the atmel-sha and ccree drivers can set it if a memory allocation fails, and the chelsio driver sets it for bad auth tag lengths, not just bad key lengths. So even if someone actually wanted to start checking this flag (which seems unlikely, since it's been unused for a long time), there would be a lot of work needed to get it working correctly. But it would probably be much better to go back to the drawing board and just define different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by: Eric Biggers Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: inside-secure - Fix hang case on EIP97 with basic DES/3DES ops

2019-12-20T06:58:34Z

This patch fixes another hang case on the EIP97 caused by sending invalidation tokens to the hardware when doing basic (3)DES ECB/CBC operations. Invalidation tokens are an EIP197 feature and needed nor supported by the EIP97. So they should not be sent for that device. Signed-off-by: Pascal van Leeuwen Signed-off-by: Herbert Xu

crypto: inside-secure - Fix hang case on EIP97 with zero length input data

2019-12-20T06:58:34Z

The EIP97 hardware cannot handle zero length input data and will (usually) hang when presented with this anyway. This patch converts any zero length input to a 1 byte dummy input to prevent this hanging. Signed-off-by: Pascal van Leeuwen Signed-off-by: Herbert Xu

crypto: inside-secure - Fix Unable to fit even 1 command desc error w/ EIP97

2019-12-20T06:58:33Z

Due to the additions of support for modes like AES-CCM and AES-GCM, which require large command tokens, the size of the descriptor has grown such that it now does not fit into the descriptor cache of a standard EIP97 anymore. This means that the driver no longer works on the Marvell Armada 3700LP chip (as used on e.g. Espressobin) that it has always supported. Additionally, performance on EIP197's like Marvell A8K may also degrade due to being able to fit less descriptors in the on-chip cache. Putting these tokens into the descriptor was really a hack and not how the design was supposed to be used - resource allocation did not account for it. So what this patch does, is move the command token out of the descriptor. To avoid having to allocate buffers on the fly for these command tokens, they are stuffed in a "shadow ring", which is a circular buffer of fixed size blocks that runs in lock-step with the descriptor ring. i.e. there is one token block per descriptor. The descriptor ring itself is then pre- populated with the pointers to these token blocks so these do not need to be filled in when building the descriptors later. Signed-off-by: Pascal van Leeuwen Signed-off-by: Herbert Xu

crypto: inside-secure - Use PTR_ERR_OR_ZERO() to simplify code

2019-12-11T08:34:44Z

Fixes coccicheck warning: drivers/crypto/inside-secure/safexcel_cipher.c:2534:1-3: WARNING: PTR_ERR_OR_ZERO can be used Reported-by: Hulk Robot Signed-off-by: zhengbin Signed-off-by: Herbert Xu

crypto: inside-secure - Fixed authenc w/ (3)DES fails on Macchiatobin

2019-11-17T01:02:38Z

Fixed 2 copy-paste mistakes in the commit mentioned below that caused authenc w/ (3)DES to consistently fail on Macchiatobin (but strangely work fine on x86+FPGA??). Now fully tested on both platforms. Fixes: 13a1bb93f7b1c9 ("crypto: inside-secure - Fixed warnings...") Signed-off-by: Pascal van Leeuwen Signed-off-by: Herbert Xu

crypto: inside-secure - Fix hangup during probing for EIP97 engine

2019-11-17T00:37:29Z

Fixed mask used for CFSIZE and RFSIZE fields of HIA_OPTIONS register, these were all 1 bit too wide. Which caused the probing of a standard EIP97 to actually hang due to assume way too large descriptor FIFO's. Signed-off-by: Pascal van Leeuwen Signed-off-by: Herbert Xu