- May 08, 2020
-
-
Eric Biggers authored
Prefix the PowerPC SHA-1 functions with "powerpc_sha1_" rather than "sha1_". This allows us to rename the library function sha_init() to sha1_init() without causing a naming collision. Cc: linuxppc-dev@lists.ozlabs.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Eric Biggers authored
The PowerPC implementation of SHA-1 doesn't actually use the 16-word temporary array that's passed to the assembly code. This was probably meant to correspond to the 'W' array that lib/sha1.c uses. However, in sha1-powerpc-asm.S these values are actually stored in GPRs 16-31. Referencing SHA_WORKSPACE_WORDS from this code also isn't appropriate, since it's an implementation detail of lib/sha1.c. Therefore, just remove this unneeded array. Tested with: export ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- make mpc85xx_defconfig cat >> .config << EOF # CONFIG_MODULES is not set # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_DEBUG_KERNEL=y CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y CONFIG_CRYPTO_SHA1_PPC=y EOF make olddefconfig make -j32 qemu-system-ppc -M mpc8544ds -cpu e500 -nographic \ -kernel arch/powerpc/boot/zImage \ -append "cryptomgr.fuzz_iterations=1000 cryptomgr.panic_on_fail=1" Cc: linuxppc-dev@lists.ozlabs.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Eric Biggers authored
In preparation for naming the SHA-1 stuff in <linux/cryptohash.h> properly and moving it to a more appropriate header, fix the HMAC-SHA256 code in mptcp_crypto_hmac_sha() to use SHA256_BLOCK_SIZE instead of "SHA_MESSAGE_BYTES" which is actually the SHA-1 block size. (Fortunately these are both 64 bytes, so this wasn't a "real" bug...) Cc: Paolo Abeni <pabeni@redhat.com> Cc: mptcp@lists.01.org Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Eric Biggers authored
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: Cheng-Yi Chiang <cychiang@chromium.org> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
Eric Biggers authored
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: keyrings@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
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: linux-sctp@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
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: linux-bluetooth@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
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: linux-mtd@lists.infradead.org Signed-off-by:
-
Eric Biggers authored
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: linux-nfs@vger.kernel.org Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Eric Biggers authored
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: ecryptfs@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
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. Signed-off-by:
-
Eric Biggers authored
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: Robert Baldyga <r.baldyga@samsung.com> Cc: Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by:
-
Eric Biggers authored
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: Krzysztof Kozlowski <krzk@kernel.org> Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Kamil Konieczny <k.konieczny@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Eric Biggers authored
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. Signed-off-by:
-
Eric Biggers authored
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. Signed-off-by:
-
Eric Biggers authored
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. Signed-off-by:
-
Eric Biggers authored
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: Zaibo Xu <xuzaibo@huawei.com> Signed-off-by:
-
Eric Biggers authored
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 <gilad@benyossef.com> Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
-
Eric Biggers authored
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: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Eric Biggers authored
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: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Signed-off-by:
-
Eric Biggers authored
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. Signed-off-by:
-
Eric Biggers authored
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. Signed-off-by:
-
Eric Biggers authored
Currently the simplest use of the shash API is to use crypto_shash_digest() to digest a whole buffer. However, this still requires allocating a hash descriptor (struct shash_desc). Many users don't really want to preallocate one and instead just use a one-off descriptor on the stack like the following: { SHASH_DESC_ON_STACK(desc, tfm); int err; desc->tfm = tfm; err = crypto_shash_digest(desc, data, len, out); shash_desc_zero(desc); } Wrap this in a new helper function crypto_shash_tfm_digest() that can be used instead of the above. Signed-off-by: -
Eric Biggers authored
The SHA-256 / SHA-224 library functions can't fail, so remove the useless return value. Also long as the declarations are being changed anyway, also fix some parameter names in the declarations to match the definitions. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Arnd Bergmann authored
gcc-10 complains about using the name of a standard library function in the kernel, as we are not building with -ffreestanding: crypto/xts.c:325:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch] 325 | static void free(struct skcipher_instance *inst) | ^~~~ crypto/lrw.c:290:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch] 290 | static void free(struct skcipher_instance *inst) | ^~~~ crypto/lrw.c:27:1: note: 'free' is declared in header '<stdlib.h>' The xts and lrw cipher implementations run into this because they do not use the conventional namespaced function names. It might be better to rename all local functions in those files to help with things like 'ctags' and 'grep', but just renaming these two avoids the build issue. I picked the more verbose crypto_xts_free() and crypto_lrw_free() names for consistency with several other drivers that do use namespaced function names. Fixes: f1c131b4 ("crypto: xts - Convert to skcipher") Fixes: 700cb3f5 ("crypto: lrw - Convert to skcipher") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Wei Yongjun authored
Fix to return negative error code -ENOMEM from the kzalloc error handling case instead of 0, as done elsewhere in this function. Reported-by:
Xiumei Mu <xmu@redhat.com> Fixes: db07cd26 ("crypto: drbg - add FIPS 140-2 CTRNG for noise source") Cc: <stable@vger.kernel.org> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Barry Song authored
users may call crypto_has_acomp to confirm the existence of acomp before using crypto_acomp APIs. Right now, many acomp have scomp backend, for example, lz4, lzo, deflate etc. crypto_has_acomp will return false for them even though they support acomp APIs. Signed-off-by:
Barry Song <song.bao.hua@hisilicon.com> Signed-off-by:
-
Iuliana Prodan authored
Added support for batch requests, per crypto engine. A new callback is added, do_batch_requests, which executes a batch of requests. This has the crypto_engine structure as argument (for cases when more than one crypto-engine is used). The crypto_engine_alloc_init_and_set function, initializes crypto-engine, but also, sets the do_batch_requests callback. On crypto_pump_requests, if do_batch_requests callback is implemented in a driver, this will be executed. The link between the requests will be done in driver, if possible. do_batch_requests is available only if the hardware has support for multiple request. Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by:
-
Iuliana Prodan authored
Added support for executing multiple requests, in parallel, for crypto engine based on a retry mechanism. If hardware was unable to execute a backlog request, enqueue it back in front of crypto-engine queue, to keep the order of requests. A new variable is added, retry_support (this is to keep the backward compatibility of crypto-engine) , which keeps track whether the hardware has support for retry mechanism and, also, if can run multiple requests. If do_one_request() returns: >= 0: hardware executed the request successfully; < 0: this is the old error path. If hardware has support for retry mechanism, the request is put back in front of crypto-engine queue. For backwards compatibility, if the retry support is not available, the crypto-engine will work as before. If hardware queue is full (-ENOSPC), requeue request regardless of MAY_BACKLOG flag. If hardware throws any other error code (like -EIO, -EINVAL, -ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into crypto-engine's queue, since the others can be dropped. The new crypto_engine_alloc_init_and_set function, initializes crypto-engine, sets the maximum size for crypto-engine software queue (not hardcoded anymore) and the retry_support variable is set, by default, to false. On crypto_pump_requests(), if do_one_request() returns >= 0, a new request is send to hardware, until there is no space in hardware and do_one_request() returns < 0. By default, retry_support is false and crypto-engine will work as before - will send requests to hardware, one-by-one, on crypto_pump_requests(), and complete it, on crypto_finalize_request(), and so on. To support multiple requests, in each driver, retry_support must be set on true, and if do_one_request() returns an error the request must not be freed, since it will be enqueued back into crypto-engine's queue. When all drivers, that use crypto-engine now, will be updated for retry mechanism, the retry_support variable can be removed. Signed-off-by:
-
Iuliana Prodan authored
Add crypto_enqueue_request_head function that enqueues a request in front of queue. This will be used in crypto-engine, on error path. In case a request was not executed by hardware, enqueue it back in front of queue (to keep the order of requests). Signed-off-by:
-
Hadar Gat authored
Improved the HW_RANDOM_CCTRNG help description. Signed-off-by:
Hadar Gat <hadar.gat@arm.com> Signed-off-by:
-
Hadar Gat authored
For many users, the Arm CryptoCell HW is not available, so the default for HW_RANDOM_CCTRNG should to n. Remove the line to follow the convention - 'n' is the default anyway so no need to state it explicitly. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Hadar Gat authored
The cctrng is unusable on non-DT systems so we should depend on it. Signed-off-by:
-
Tang Bin authored
Use the defined variable "dev" to make the code cleaner. Signed-off-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Signed-off-by:
-
Lionel Debieve authored
Change driver to not print an error message when the device probe is deferred for a clock resource. Signed-off-by:
Lionel Debieve <lionel.debieve@st.com> Signed-off-by:
-
Etienne Carriere authored
Change stm32 HASH driver to defer its probe operation when DMA channel device is registered but has not been probed yet. Signed-off-by:
Etienne Carriere <etienne.carriere@st.com> Reviewed-by:
-
Etienne Carriere authored
Change stm32 HASH driver to defer its probe operation when reset controller device is registered but has not been probed yet. Signed-off-by:
-
- Apr 30, 2020
-
-
Tang Bin authored
Delete unused initialized value in cipher.c file. Signed-off-by:
-
Tang Bin authored
It's not necessary to specify 'int' casting for PTR_ERR(). Signed-off-by:
-
Corentin Labbe authored
if CRYPTO_DRBG_CTR is builtin and CTR is module, allocating such algo will fail. DRBG: could not allocate CTR cipher TFM handle: ctr(aes) alg: drbg: Failed to reset rng alg: drbg: Test 0 failed for drbg_pr_ctr_aes128 DRBG: could not allocate CTR cipher TFM handle: ctr(aes) alg: drbg: Failed to reset rng alg: drbg: Test 0 failed for drbg_nopr_ctr_aes128 DRBG: could not allocate CTR cipher TFM handle: ctr(aes) alg: drbg: Failed to reset rng alg: drbg: Test 0 failed for drbg_nopr_ctr_aes192 DRBG: could not allocate CTR cipher TFM handle: ctr(aes) alg: drbg: Failed to reset rng alg: drbg: Test 0 failed for drbg_nopr_ctr_aes256 So let's select CTR instead of just depend on it. Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Signed-off-by:
-
