crypto: safexcel - Add error handling for dma_map_sg() calls

[ Upstream commit 87e02063d07708cac5bfe9fd3a6a242898758ac8 ]

Macro dma_map_sg() may return 0 on error. This patch enables
checks in case

crypto: safexcel - Add error handling for dma_map_sg() calls

[ Upstream commit 87e02063d07708cac5bfe9fd3a6a242898758ac8 ]

Macro dma_map_sg() may return 0 on error. This patch enables
checks in case of the macro failure and ensures unmapping of
previously mapped buffers with dma_unmap_sg().

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: 49186a7d9e46 ("crypto: inside_secure - Avoid dma map if size is zero")
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Reviewed-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

crypto: safexcel - Use crypto_wait_req

This patch replaces the custom crypto completion function with
crypto_req_done.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

crypto: inside-secure - Replace generic aes with libaes

Commit 363a90c2d517 ("crypto: safexcel/aes - switch to
library version of key expansion routine") removed
CRYPTO_AES in the config. However, s

crypto: inside-secure - Replace generic aes with libaes

Commit 363a90c2d517 ("crypto: safexcel/aes - switch to
library version of key expansion routine") removed
CRYPTO_AES in the config. However, some portions of codes
still rely on generic AES cipher (e.g. refer to
safexcel_aead_gcm_cra_init(), safexcel_xcbcmac_cra_init()).
This causes transform allocation failure for those algos,
if CRYPTO_AES is not manually enabled.

To resolve that, we replace all existing AES cipher
dependent codes with their AES library counterpart.

Fixes: 363a90c2d517 ("crypto: safexcel/aes - switch to library version of key expansion routine")
Signed-off-by: Peter Harliman Liem <pliem@maxlinear.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside_secure - Avoid dma map if size is zero

From commit d03c54419274 ("dma-mapping: disallow .map_sg
operations from returning zero on error"), dma_map_sg()
produces warning if size is 0.

crypto: inside_secure - Avoid dma map if size is zero

From commit d03c54419274 ("dma-mapping: disallow .map_sg
operations from returning zero on error"), dma_map_sg()
produces warning if size is 0. This results in visible
warnings if crypto length is zero.
To avoid that, we avoid calling dma_map_sg if size is zero.

Signed-off-by: Peter Harliman Liem <pliem@maxlinear.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: sha - split sha.h into sha1.h and sha2.h

Currently <crypto/sha.h> contains declarations for both SHA-1 and SHA-2,
and <crypto/sha3.h> contains declarations for SHA-3.

This organization is i

crypto: sha - split sha.h into sha1.h and sha2.h

Currently <crypto/sha.h> contains declarations for both SHA-1 and SHA-2,
and <crypto/sha3.h> contains declarations for SHA-3.

This organization is inconsistent, but more importantly SHA-1 is no
longer considered to be cryptographically secure. So to the extent
possible, SHA-1 shouldn't be grouped together with any of the other SHA
versions, and usage of it should be phased out.

Therefore, split <crypto/sha.h> into two headers <crypto/sha1.h> and
<crypto/sha2.h>, and make everyone explicitly specify whether they want
the declarations for SHA-1, SHA-2, or both.

This avoids making the SHA-1 declarations visible to files that don't
want anything to do with SHA-1. It also prepares for potentially moving
sha1.h into a new insecure/ or dangerous/ directory.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Reuse code in safexcel_hmac_alg_setkey

The code in the current implementation of safexcel_hmac_alg_setkey
can be reused by safexcel_cipher. This patch does just that by
rena

crypto: inside-secure - Reuse code in safexcel_hmac_alg_setkey

The code in the current implementation of safexcel_hmac_alg_setkey
can be reused by safexcel_cipher. This patch does just that by
renaming the previous safexcel_hmac_setkey to __safexcel_hmac_setkey.
The now-shared safexcel_hmac_alg_setkey becomes safexcel_hmac_setkey
and a new safexcel_hmac_alg_setkey has been added for use by ahash
transforms.

As a result safexcel_aead_setkey's stack frame has been reduced by
about half in size, or about 512 bytes.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Move ipad/opad into safexcel_context

As both safexcel_ahash_ctx and safexcel_cipher_ctx contain ipad
and opad buffers this patch moves them into the common struct
safexcel_co

crypto: inside-secure - Move ipad/opad into safexcel_context

As both safexcel_ahash_ctx and safexcel_cipher_ctx contain ipad
and opad buffers this patch moves them into the common struct
safexcel_context. It also adds a union so that they can be accessed
in the appropriate endian without crazy casts.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Move priv pointer into safexcel_context

This patch moves the priv pointer into struct safexcel_context
because both structs that extend safexcel_context have that pointer
as

crypto: inside-secure - Move priv pointer into safexcel_context

This patch moves the priv pointer into struct safexcel_context
because both structs that extend safexcel_context have that pointer
as well.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY

Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
allocate memory.

drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c: su

crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY

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 <mpatocka@redhat.com>
[EB: avoid overly-long lines]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: remove propagation of CRYPTO_TFM_RES_* flags

The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
->setkey() functions provide more information about errors. But these
flag

crypto: remove propagation of CRYPTO_TFM_RES_* flags

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 <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN

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 a

crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN

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 <ebiggers@google.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

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

This patch fixes another hang case on the EIP97 caused by sending
invalidation tokens to the hardware when doing basic (3)DES E

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

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 <pvanleeuwen@rambus.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

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

The EIP97 hardware cannot handle zero length input data and will (usually)
hang when presented with this anyway. This patch

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

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 <pvanleeuwen@rambus.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

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

Due to the additions of support for modes like AES-CCM and AES-GCM, which
require large command tokens, the size of the d

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

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 <pvanleeuwen@rambus.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

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

Fixes coccicheck warning:

drivers/crypto/inside-secure/safexcel_cipher.c:2534:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Reported-by:

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

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 <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

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

Fixed 2 copy-paste mistakes in the commit mentioned below that caused
authenc w/ (3)DES to consistently fail on Macchiatobin (bu

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

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 <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Fixed warnings on inconsistent byte order handling

This fixes a bunch of endianness related sparse warnings reported by the
kbuild test robot as well as Ben Dooks.

Credits f

crypto: inside-secure - Fixed warnings on inconsistent byte order handling

This fixes a bunch of endianness related sparse warnings reported by the
kbuild test robot as well as Ben Dooks.

Credits for the fix to safexcel.c go to Ben Dooks.

Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - fix spelling mistake "algorithmn" -> "algorithm"

There is a spelling mistake in a dev_err message. Fix it. Add in missing
newline.

Signed-off-by: Colin Ian King <colin.king@

crypto: inside-secure - fix spelling mistake "algorithmn" -> "algorithm"

There is a spelling mistake in a dev_err message. Fix it. Add in missing
newline.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Added support for the rfc4309(ccm(aes)) AEAD

This patch adds support for rfc4309(ccm(aes)) for use with IPsec ESP

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.c

crypto: inside-secure - Added support for the rfc4309(ccm(aes)) AEAD

This patch adds support for rfc4309(ccm(aes)) for use with IPsec ESP

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Added support for the rfc4543(gcm(aes)) "AEAD"

This patch adds support for rfc4543(gcm(aes)) - i.e. AES-GMAC - for use
with IPsec ESP

Signed-off-by: Pascal van Leeuwen <pvan

crypto: inside-secure - Added support for the rfc4543(gcm(aes)) "AEAD"

This patch adds support for rfc4543(gcm(aes)) - i.e. AES-GMAC - for use
with IPsec ESP

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Added support for the rfc4106(gcm(aes)) AEAD

This patch adds support for rfc4106(gcm(aes)) for use with IPsec ESP

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.c

crypto: inside-secure - Added support for the rfc4106(gcm(aes)) AEAD

This patch adds support for rfc4106(gcm(aes)) for use with IPsec ESP

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Added support for authenc HMAC-SHA2/DES-CBC

This patch adds support for the authenc(hmac(sha224),cbc(des)),
authenc(hmac(sha256),cbc(des)), authenc(hmac(sha384),cbc(des))
and

crypto: inside-secure - Added support for authenc HMAC-SHA2/DES-CBC

This patch adds support for the authenc(hmac(sha224),cbc(des)),
authenc(hmac(sha256),cbc(des)), authenc(hmac(sha384),cbc(des))
and authenc(hmac(sha512),cbc(des)) aead's

changes since v1:
- nothing

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Added support for authenc HMAC-SHA2/3DES-CBC

This patch adds support for the authenc(hmac(sha224),cbc(des3_ede)),
authenc(hmac(sha256),cbc(des3_ede)), authenc(hmac(sha384),cb

crypto: inside-secure - Added support for authenc HMAC-SHA2/3DES-CBC

This patch adds support for the authenc(hmac(sha224),cbc(des3_ede)),
authenc(hmac(sha256),cbc(des3_ede)), authenc(hmac(sha384),cbc(des3_ede))
and authenc(hmac(sha512),cbc(des3_ede)) aead's

changes since v1:
- nothing

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Added support for authenc HMAC-SHA1/DES-CBC

This patch adds support for the authenc(hmac(sha1),cbc(des)) aead

changes since v1:
- rebased on top of DES changes made to crypt

crypto: inside-secure - Added support for authenc HMAC-SHA1/DES-CBC

This patch adds support for the authenc(hmac(sha1),cbc(des)) aead

changes since v1:
- rebased on top of DES changes made to cryptodev/master

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...

crypto: inside-secure - Add SM4 based authenc AEAD ciphersuites

This patch adds support for the authenc(hmac(sha1),cbc(sm4)),
authenc(hmac(sm3),cbc(sm4)), authenc(hmac(sha1),rfc3686(ctr(sm4))),
and

crypto: inside-secure - Add SM4 based authenc AEAD ciphersuites

This patch adds support for the authenc(hmac(sha1),cbc(sm4)),
authenc(hmac(sm3),cbc(sm4)), authenc(hmac(sha1),rfc3686(ctr(sm4))),
and authenc(hmac(sm3),rfc3686(ctr(sm4))) aead ciphersuites.
These are necessary to support IPsec according to the Chinese standard
GM/T 022-1014 - IPsec VPN specification.

Note that there are no testvectors present in testmgr for these
ciphersuites. However, considering all building blocks have already been
verified elsewhere, it is fair to assume the generic implementation to be
correct-by-construction.
The hardware implementation has been fuzzed against this generic
implementation by means of a locally modified testmgr. The intention is
to upstream these testmgr changes but this is pending other testmgr changes
being made by Eric Biggers.

The patch has been tested with the eip197c_iewxkbc configuration on the
Xilinx VCU118 development board, using the abovementioned modified testmgr

This patch applies on top of "Add support for SM4 ciphers" and needs to
be applied before "Add (HMAC) SHA3 support".

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

show more ...