kernel/linux.git/drivers/crypto/ccree, branch linux-4.20.y

crypto: ccree - add missing inline qualifier

2019-03-05T16:59:44+00:00

commit f1071c3e2473ae19a7f5d892a187c4cab1a61f2e upstream. Commit 1358c13a48c4 ("crypto: ccree - fix resume race condition on init") was missing a "inline" qualifier for stub function used when CONFIG_PM is not set causing a build warning. Fixes: 1358c13a48c4 ("crypto: ccree - fix resume race condition on init") Cc: stable@kernel.org # v4.20 Signed-off-by: Gilad Ben-Yossef Acked-by: Geert Uytterhoeven Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - fix resume race condition on init

2019-02-20T09:29:14+00:00

commit 1358c13a48c43f5e4de0c1835291837a27b9720c upstream. We were enabling autosuspend, which is using data set by the hash module, prior to the hash module being inited, casuing a crash on resume as part of the startup sequence if the race was lost. This was never a real problem because the PM infra was using low res timers so we were always winning the race, until commit 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") changed that :-) Fix this by seperating the PM setup and enablement and doing the latter only at the end of the init sequence. Signed-off-by: Gilad Ben-Yossef Cc: Vincent Guittot Cc: stable@kernel.org # v4.20 Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - convert to use crypto_authenc_extractkeys()

2019-01-22T20:09:50+00:00

commit dc95b5350a8f07d73d6bde3a79ef87289698451d upstream. Convert the ccree crypto driver to use crypto_authenc_extractkeys() so that it picks up the fix for broken validation of rtattr::rta_len. Fixes: ff27e85a85bb ("crypto: ccree - add AEAD support") Cc: # v4.17+ Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - avoid implicit enum conversion

2018-10-17T06:16:18+00:00

Clang warns when one enumerated type is implicitly converted to another and this happens in several locations in this driver, ultimately related to the set_cipher_{mode,config0} functions. set_cipher_mode expects a mode of type drv_cipher_mode and set_cipher_config0 expects a mode of type drv_crypto_direction. drivers/crypto/ccree/cc_ivgen.c:58:35: warning: implicit conversion from enumeration type 'enum cc_desc_direction' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(&iv_seq[idx], DESC_DIRECTION_ENCRYPT_ENCRYPT); drivers/crypto/ccree/cc_hash.c:99:28: warning: implicit conversion from enumeration type 'enum cc_hash_conf_pad' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(desc, HASH_DIGEST_RESULT_LITTLE_ENDIAN); drivers/crypto/ccree/cc_aead.c:1643:30: warning: implicit conversion from enumeration type 'enum drv_hash_hw_mode' to different enumeration type 'enum drv_cipher_mode' [-Wenum-conversion] set_cipher_mode(&desc[idx], DRV_HASH_HW_GHASH); Since this fundamentally isn't a problem because these values just represent simple integers for a shift operation, make it clear to Clang that this is okay by making the mode parameter in both functions an int. Link: https://github.com/ClangBuiltLinux/linux/issues/46 Signed-off-by: Nathan Chancellor Acked-by: Gilad Ben-Yossef Reviewed-by: Nick Desaulniers Signed-off-by: Herbert Xu

crypto: ccree - allow bigger than sector XTS op

2018-08-03T10:06:05+00:00

The ccree driver had a sanity check that we are not asked to encrypt an XTS buffer bigger than a sane sector size since XTS IV needs to include the sector number in the IV so this is not expected in any real use case. Unfortunately, this breaks cryptsetup benchmark test which has a synthetic performance test using 64k buffer of data with the same IV. Remove the sanity check and allow the user to hang themselves and/or run benchmarks if they so wish. Reported-by: Geert Uytterhoeven Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - zero all of request ctx before use

2018-08-03T10:06:05+00:00

In certain error path req_ctx->iv was being freed despite not being allocated because it was not initialized to NULL. Rather than play whack a mole with the structure various field, zero it before use. This fixes a kernel panic that may occur if an invalid buffer size was requested triggering the bug above. Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support") Reported-by: Geert Uytterhoeven Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - remove cipher ivgen left overs

2018-08-03T10:06:05+00:00

IV generation is not available via the skcipher interface. Remove the left over support of it from the ablkcipher days. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - drop useless type flag during reg

2018-08-03T10:06:05+00:00

Drop the explicit setting of CRYPTO_ALG_TYPE_AEAD or CRYPTO_ALG_TYPE_SKCIPHER flags during alg registration as they are set anyway by the framework. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - rate limit debug print

2018-07-08T16:33:36+00:00

A debug print about register status post interrupt can happen quite often. Rate limit it to avoid cluttering the log. Signed-off-by: Gilad Ben-Yossef Reported-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Herbert Xu

crypto: ccree - use CBC-CS3 CTS mode

2018-07-08T16:33:36+00:00

The ccree driver implemented NIST 800-38A CBC-CS2 ciphertext format, which only reverses the last two blocks if the stolen ciphertext amount are none zero. Move it to the kernel chosen format of CBC-CS3 which swaps the final blocks unconditionally and rename it to "cts" now that it complies with the kernel format and passes the self tests. Ironically, the CryptoCell REE HW does just that, so the fix is dropping the code that forced it to use plain CBC if the ciphertext was block aligned. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu