- 15 May, 2020 8 commits
-
-
Longfang Liu authored
Misc fixes on coding style: 1.Merge pre-initialization and initialization of QM 2.Package the initialization of QM's PF and VF into a function Signed-off-by:
Longfang Liu <liulongfang@huawei.com> Signed-off-by:
Zaibo Xu <xuzaibo@huawei.com> Signed-off-by:
Shukun Tan <tanshukun1@huawei.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Longfang Liu authored
Adjust the position of SMMU status check and SEC queue initialization in SEC probe Signed-off-by:
Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
-
Rikard Falkeborn authored
sec_dfx_regs is never changed and can therefore be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 17982 7312 480 25774 64ae drivers/crypto/hisilicon/sec2/sec_main.o After: text data bss dec hex filename 18366 6928 480 25774 64ae drivers/crypto/hisilicon/sec2/sec_main.o Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Rikard Falkeborn authored
hzip_dfx_regs is never changed and can be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 15236 6160 480 21876 5574 drivers/crypto/hisilicon/zip/zip_main.o After: text data bss dec hex filename 15620 5776 480 21876 5574 drivers/crypto/hisilicon/zip/zip_main.o Signed-off-by:
-
Rikard Falkeborn authored
hpre_cluster_dfx_regs and hpre_com_dfx_regs are never changed and can therefore be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 16455 6288 480 23223 5ab7 drivers/crypto/hisilicon/hpre/hpre_main.o After: text data bss dec hex filename 16839 5904 480 23223 5ab7 drivers/crypto/hisilicon/hpre/hpre_main.o Signed-off-by:
-
Rikard Falkeborn authored
pid_cd_regs and debug_regs are never changed and can therefore be made const. This allows the compiler to put it in the text section instead of the data section. Before: text data bss dec hex filename 2871 2320 64 5255 1487 drivers/crypto/ccree/cc_debugfs.o After: text data bss dec hex filename 3255 1936 64 5255 1487 drivers/crypto/ccree/cc_debugfs.o Signed-off-by:
-
Arnd Bergmann authored
When building for ARMv7-M, clang-9 or higher tries to unroll some loops, which ends up confusing the register allocator to the point of generating rather bad code and using more than the warning limit for stack frames: warning: stack frame size of 1200 bytes in function 'blake2b_compress' [-Wframe-larger-than=] Forcing it to not unroll the final loop avoids this problem. Fixes: 91d68933 ("crypto: blake2b - add blake2b generic implementation") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Herbert Xu authored
This reverts commit 85fc78b8 as a different fix has already been applied in the sound-asoc tree and this patch is no longer required. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
- 08 May, 2020 32 commits
-
-
Eric Biggers authored
<linux/cryptohash.h> sounds very generic and important, like it's the header to include if you're doing cryptographic hashing in the kernel. But actually it only includes the library implementation of the SHA-1 compression function (not even the full SHA-1). This should basically never be used anymore; SHA-1 is no longer considered secure, and there are much better ways to do cryptographic hashing in the kernel. Remove this header and fold it into <crypto/sha.h> which already contains constants and functions for SHA-1 (along with SHA-2). Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
<linux/cryptohash.h> sounds very generic and important, like it's the header to include if you're doing cryptographic hashing in the kernel. But actually it only includes the library implementation of the SHA-1 compression function (not even the full SHA-1). This should basically never be used anymore; SHA-1 is no longer considered secure, and there are much better ways to do cryptographic hashing in the kernel. Most files that include this header don't actually need it. So in preparation for removing it, remove all these unneeded includes of it. Signed-off-by:
-
Eric Biggers authored
The library implementation of the SHA-1 compression function is confusingly called just "sha_transform()". Alongside it are some "SHA_" constants and "sha_init()". Presumably these are left over from a time when SHA just meant SHA-1. But now there are also SHA-2 and SHA-3, and moreover SHA-1 is now considered insecure and thus shouldn't be used. Therefore, rename these functions and constants to make it very clear that they are for SHA-1. Also add a comment to make it clear that these shouldn't be used. For the extra-misleadingly named "SHA_MESSAGE_BYTES", rename it to SHA1_BLOCK_SIZE and define it to just '64' rather than '(512/8)' so that it matches the same definition in <crypto/sha.h>. This prepares for merging <linux/cryptohash.h> into <crypto/sha.h>. Signed-off-by:
-
Eric Biggers authored
Prefix the s390 SHA-1 functions with "s390_sha1_" rather than "sha1_". This allows us to rename the library function sha_init() to sha1_init() without causing a naming collision. Cc: linux-s390@vger.kernel.org Signed-off-by:
-
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 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: -
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:
-
