aboutsummaryrefslogtreecommitdiff
path: root/drivers/crypto/ccree/cc_cipher.c
AgeCommit message (Collapse)AuthorFilesLines
2024-05-31crypto: ccree - Remove unused struct 'tdes_keys'Dr. David Alan Gilbert1-6/+0
'tdes_keys' appears unused. Remove it. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Acked-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-12-08crypto: ccree - Remove ofbHerbert Xu1-35/+0
Remove the unused OFB implementation. Signed-off-by: Herbert Xu <[email protected]>
2023-11-17crypto: ccree - Silence gcc format-truncation false positive warningsHerbert Xu1-3/+7
The heuristics used by gcc triggers false positive truncation warnings in hifn_alg_alloc. The warning triggered by the strings here are clearly false positives (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95755). Add checks on snprintf calls to silence these warnings, including the one for cra_driver_name even though it does not currently trigger a gcc warning. Signed-off-by: Herbert Xu <[email protected]>
2023-01-06crypto: xts - drop xts_check_key()Vladis Dronov1-1/+1
xts_check_key() is obsoleted by xts_verify_key(). Over time XTS crypto drivers adopted the newer xts_verify_key() variant, but xts_check_key() is still used by a number of drivers. Switch drivers to use the newer xts_verify_key() and make a couple of cleanups. This allows us to drop xts_check_key() completely and avoid redundancy. Signed-off-by: Vladis Dronov <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Reviewed-by: Nicolai Stange <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2022-03-09crypto: ccree - Fix use after free in cc_cipher_exit()Jianglei Nie1-1/+1
kfree_sensitive(ctx_p->user.key) will free the ctx_p->user.key. But ctx_p->user.key is still used in the next line, which will lead to a use after free. We can call kfree_sensitive() after dev_dbg() to avoid the uaf. Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support") Signed-off-by: Jianglei Nie <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2021-02-05crypto: ccree - fix spelling typo of allocateddingsenjie1-1/+1
allocted -> allocated Signed-off-by: dingsenjie <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-11-27crypto: ccree - Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+3
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <[email protected]> Acked-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-08-21crypto: ccree - remove bitlocker cipherGilad Ben-Yossef1-46/+3
Remove the bitlocker cipher which is not supported by the kernel. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-08-21crypto: ccree - remove data unit size supportGilad Ben-Yossef1-232/+1
Remove the implementaion of automatic advancement of sector size in IV for storage ciphers as its use is not supproted by the kernel. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-08-07mm, treewide: rename kzfree() to kfree_sensitive()Waiman Long1-3/+3
As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or something. The "zero" part of the interface isn't even _relevant_. The main reason that kzfree() exists is to clear sensitive information that should not be leaked to other future users of the same memory objects. Rename kzfree() to kfree_sensitive() to follow the example of the recently added kvfree_sensitive() and make the intention of the API more explicit. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: git grep -w --name-only kzfree |\ xargs sed -i 's/kzfree/kfree_sensitive/' followed by some editing of the kfree_sensitive() kerneldoc and adding a kzfree backward compatibility macro in slab.h. [[email protected]: fs/crypto/inline_crypt.c needs linux/slab.h] [[email protected]: fix fs/crypto/inline_crypt.c some more] Suggested-by: Joe Perches <[email protected]> Signed-off-by: Waiman Long <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: David Howells <[email protected]> Acked-by: Michal Hocko <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: Jarkko Sakkinen <[email protected]> Cc: James Morris <[email protected]> Cc: "Serge E. Hallyn" <[email protected]> Cc: Joe Perches <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: David Rientjes <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Jason A . Donenfeld" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-06-26crypto: ccree - remove unused fieldGilad Ben-Yossef1-1/+0
Remove yet another unused field left over from times gone by. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-06-26crypto: ccree - adapt ccree essiv support to kcapiGilad Ben-Yossef1-31/+93
The ESSIV support in ccree was added before the kernel generic support and using a slightly different API. Brings the ccree essiv interface into compliance with kernel crypto api one. Since CryptoCell only support 256 bit AES key for ESSIV, also use a fallback if requested a smaller key size. Signed-off-by: Gilad Ben-Yossef <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Libo Wang <[email protected]> Cc: Markus Elfring <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-06-26crypto: ccree - fix resource leak on error pathGilad Ben-Yossef1-12/+18
Fix a small resource leak on the error path of cipher processing. Signed-off-by: Gilad Ben-Yossef <[email protected]> Fixes: 63ee04c8b491e ("crypto: ccree - add skcipher support") Cc: Markus Elfring <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-05-08crypto: ccree - use crypto_shash_tfm_digest()Eric Biggers1-6/+3
Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Gilad Ben-Yossef <[email protected]> Signed-off-by: Eric Biggers <[email protected]> Acked-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-03-12crypto: ccree - remove ancient TODO remarksGilad Ben-Yossef1-1/+0
Remove left over ancient and now misleading TODO remarks. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-22crypto: ccree - use devm_k[mz]alloc() for cipher dataGeert Uytterhoeven1-3/+1
As the lifetime of the cipher data matches the lifetime of the driver, cipher data can be allocated using the managed allocators. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-22crypto: ccree - use devm_k[mz]alloc() for AEAD dataGeert Uytterhoeven1-4/+4
As the lifetime of the AEAD data matches the lifetime of the driver, AEAD data can be allocated using the managed allocators. While at it, simplify cc_aead_free() by removing an unneeded cast, and an unneeded check (aead_handle is always valid here). Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-22crypto: ccree - remove struct cc_cipher_handleGeert Uytterhoeven1-25/+8
The cc_cipher_handle structure contains only a single member, and only one instance exists. Simplify the code and reduce memory consumption by moving this member to struct cc_drvdata. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-22crypto: ccree - use u32 for SRAM addressesGeert Uytterhoeven1-5/+5
SRAM addresses are small integer offsets into local SRAM. Currently they are stored using a mixture of cc_sram_addr_t (u64), u32, and dma_addr_t types. Settle on u32, and remove the cc_sram_addr_t typedefs. This allows to drop several casts. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-22crypto: ccree - remove unneeded castsGeert Uytterhoeven1-5/+5
Unneeded casts prevent the compiler from performing valuable checks. This is especially true for function pointers. Remove these casts, to prevent silently introducing bugs when a variable's type might be changed in the future. No change in generated code. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-13crypto: ccree - remove set but not used variable 'du_size'YueHaibing1-8/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/crypto/ccree/cc_cipher.c: In function 'cc_setup_state_desc': drivers/crypto/ccree/cc_cipher.c:536:15: warning: variable 'du_size' set but not used [-Wunused-but-set-variable] commit 5c83e8ec4d51 ("crypto: ccree - fix FDE descriptor sequence") involved this unused variable, so remove it. Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-13crypto: ccree - fix some reported cipher block sizesGilad Ben-Yossef1-2/+6
OFB and CTR modes block sizes were wrongfully reported as the underlying block sizes. Fix it to 1 bytes as they turn the block ciphers into stream ciphers. Also document why our XTS differes from the generic implementation. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-01-22crypto: ccree - fix FDE descriptor sequenceOfir Drang1-3/+45
In FDE mode (xts, essiv and bitlocker) the cryptocell hardware requires that the the XEX key will be loaded after Key1. Signed-off-by: Ofir Drang <[email protected]> Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]>
2020-01-22crypto: ccree - turn errors to debug msgsGilad Ben-Yossef1-3/+3
We have several loud error log messages that are already reported via the normal return code mechanism and produce a lot of noise when the new testmgr extra test are enabled. Turn these into debug only messages Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-01-09crypto: remove CRYPTO_TFM_RES_BAD_KEY_LENEric Biggers1-3/+0
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 <[email protected]> Reviewed-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-01-09crypto: remove CRYPTO_TFM_RES_BAD_BLOCK_LENEric Biggers1-1/+0
The flag CRYPTO_TFM_RES_BAD_BLOCK_LEN is never checked for, and it's only set by one driver. And even that single driver's use is wrong because the driver is setting the flag from ->encrypt() and ->decrypt() with no locking, which is unsafe because ->encrypt() and ->decrypt() can be executed by many threads in parallel on the same tfm. Just remove this flag. Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-11-17crypto: ccree - update a stale reference to ablkcipherArd Biesheuvel1-2/+2
The ccree driver does not use the ablkcipher interface but contains a rudimentary reference to it in the naming of an unrelated macro. Let's rename it to avoid confusion. Acked-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-09-13crypto: ccree - enable CTS support in AES-XTSUri Shir1-10/+6
In XTS encryption/decryption the plaintext byte size can be >= AES_BLOCK_SIZE. This patch enable the AES-XTS ciphertext stealing implementation in ccree driver. Signed-off-by: Uri Shir <[email protected]> Acked-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-08-22crypto: ccree/des - switch to new verification routinesArd Biesheuvel1-11/+4
Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-05-03crypto: ccree - remove set but not used variable 'du_size'YueHaibing1-8/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/crypto/ccree/cc_cipher.c: In function cc_setup_key_desc: drivers/crypto/ccree/cc_cipher.c:645:15: warning: variable du_size set but not used [-Wunused-but-set-variable] It is never used since introduction in commit dd8486c75085 ("crypto: ccree - move key load desc. before flow desc.") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-05-03crypto: ccree - fix spelling mistake "protedcted" -> "protected"Colin Ian King1-1/+1
There is a spelling mistake in a dev_dbg message, fix it. Signed-off-by: Colin Ian King <[email protected]> Acked-By: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - copyright header updateGilad Ben-Yossef1-1/+1
This sacrificial copyright header update is offered to the legal department as atonement for any changes made in this driver files in the course of the current year which have not been duly recorded as such. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - fix backlog notificationsGilad Ben-Yossef1-3/+7
We were doing backlog notification callbacks via a cipher/hash/aead request structure cast to the base structure, which may or may not work based on how the structure is laid in memory and is not safe. Fix it by delegating the backlog notification to the appropriate internal callbacks which are type aware. Signed-off-by: Gilad Ben-Yossef <[email protected]> Cc: [email protected] # v4.19+ Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - read next IV from HWGilad Ben-Yossef1-96/+83
We were computing the next IV in software instead of reading it from HW on the premise that this can be quicker due to the small size of IVs but this proved to be much more hassle and bug ridden than expected. Move to reading the next IV as computed by the HW. This fixes a number of issue with next IV being wrong for OFB, CTS-CBC and probably most of the other ciphers as well. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - adapt CPP descriptor to new HWGilad Ben-Yossef1-20/+22
Adapt the CPP descriptor to new HW interface. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - add SM4 protected keys supportGilad Ben-Yossef1-0/+36
Add the registration for the SM4 based policy protected keys ciphers. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - add remaining logic for CPPGilad Ben-Yossef1-51/+135
Add the missing logic to set usage policy protections for keys. This enables key policy protection for AES. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - add support for sec disabled modeGilad Ben-Yossef1-1/+16
Add support for the Security Disabled mode under which only pure cryptographic functionality is enabled and protected keys services are unavailable. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - move MLLI desc. before key loadGilad Ben-Yossef1-23/+35
Refactor to move the descriptor copying the MLLI line to SRAM to before the key loading descriptor in preparation to the introduction of CPP later on. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-04-25crypto: ccree - move key load desc. before flow desc.Gilad Ben-Yossef1-34/+73
Refactor the descriptor setup code in order to move the key loading descriptor to one before last position. This has no effect on current functionality but is needed for later support of Content Protection Policy keys. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-03-22crypto: ccree - reduce kernel stack usage with clangArnd Bergmann1-1/+1
Building with clang for a 32-bit architecture runs over the stack frame limit in the setkey function: drivers/crypto/ccree/cc_cipher.c:318:12: error: stack frame size of 1152 bytes in function 'cc_cipher_setkey' [-Werror,-Wframe-larger-than=] The problem is that there are two large variables: the temporary 'tmp' array and the SHASH_DESC_ON_STACK() declaration. Moving the first into the block in which it is used reduces the total frame size to 768 bytes, which seems more reasonable and is under the warning limit. Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support") Signed-off-by: Arnd Bergmann <[email protected]> Acked-By: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-02-22crypto: ccree - fix missing break in switch statementGustavo A. R. Silva1-0/+1
Add missing break statement in order to prevent the code from falling through to case S_DIN_to_DES. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support") Cc: [email protected] Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-01-25crypto: clarify name of WEAK_KEY request flagEric Biggers1-1/+2
CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak keys be forbidden (for algorithms that have the notion of "weak keys"; currently only DES and XTS do). Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which it can be easily confused. (This in fact happened in the UX500 driver, though just in some debugging messages.) Therefore, make the intent clear by renaming it to CRYPTO_TFM_REQ_FORBID_WEAK_KEYS. Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-01-25crypto: ccree - don't copy zero size ciphertextGilad Ben-Yossef1-1/+2
For decryption in CBC mode we need to save the last ciphertext block for use as the next IV. However, we were trying to do this also with zero sized ciphertext resulting in a panic. Fix this by only doing the copy if the ciphertext length is at least of IV size. Signed-off-by: Gilad Ben-Yossef <[email protected]> Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]>
2019-01-25crypto: ccree - unmap buffer before copying IVGilad Ben-Yossef1-1/+2
We were copying the last ciphertext block into the IV field for CBC before removing the DMA mapping of the output buffer with the result of the buffer sometime being out-of-sync cache wise and were getting intermittent cases of bad output IV. Fix it by moving the DMA buffer unmapping before the copy. Signed-off-by: Gilad Ben-Yossef <[email protected]> Fixes: 00904aa0cd59 ("crypto: ccree - fix iv handling") Cc: <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-12-07crypto: ccree - add support for CryptoCell 703Gilad Ben-Yossef1-1/+37
Add support for Arm TrustZone CryptoCell 703. The 703 is a variant of the CryptoCell 713 that supports only algorithms certified by the Chinesse Office of the State Commercial Cryptography Administration (OSCCA). Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-11-09crypto: ccree - add SM4 supportGilad Ben-Yossef1-0/+66
Add support for SM4 cipher in CryptoCell 713. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-08-03crypto: ccree - allow bigger than sector XTS opGilad Ben-Yossef1-4/+1
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 <[email protected]> Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-08-03crypto: ccree - zero all of request ctx before useGilad Ben-Yossef1-3/+3
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 <[email protected]> Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-08-03crypto: ccree - remove cipher ivgen left oversGilad Ben-Yossef1-11/+0
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 <[email protected]> Signed-off-by: Herbert Xu <[email protected]>