- 08 Aug, 2019 1 commit
-
-
Stephen Rothwell authored
Fixes: 3e75241b ("hwrng: drivers - Use device-managed registration API") Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 02 Aug, 2019 13 commits
-
-
Herbert Xu authored
Now that simd.h is in include/asm-generic/Kbuild we don't need the arch-specific Kbuild rules for them. Reported-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by:
Arnd Bergmann <arnd@arndb.de>
-
Horia Geantă authored
When QI (Queue Interface) support is enabled on DPAA 1.x platforms, defer probing if dependencies (QMan drivers) are not available yet. Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Masahiro Yamada authored
Add a header include guard just in case. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Thomas Gleixner authored
While looking at CONFIG_PREEMPT dependencies treewide the #ifdef in crypto_yield() matched. CONFIG_PREEMPT and CONFIG_PREEMPT_VOLUNTARY are mutually exclusive so the extra !CONFIG_PREEMPT conditional is redundant. cond_resched() has only an effect when CONFIG_PREEMPT_VOLUNTARY is set, otherwise it's a stub which the compiler optimizes out. Remove the whole conditional. No functional change. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: linux-crypto@vger.kernel.org Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Chuhong Yuan authored
Use devm_hwrng_register to simplify the implementation. Manual unregistration and some remove functions can be removed now. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Acked-by:
Łukasz Stelmach <l.stelmach@samsung.com> Acked-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
-
Arnd Bergmann authored
Recent clang-9 snapshots double the kernel stack usage when building this file with -O0 -fsanitize=kernel-hwaddress, compared to clang-8 and older snapshots, this changed between commits svn364966 and svn366056: crypto/jitterentropy.c:516:5: error: stack frame size of 2640 bytes in function 'jent_entropy_init' [-Werror,-Wframe-larger-than=] int jent_entropy_init(void) ^ crypto/jitterentropy.c:185:14: error: stack frame size of 2224 bytes in function 'jent_lfsr_time' [-Werror,-Wframe-larger-than=] static __u64 jent_lfsr_time(struct rand_data *ec, __u64 time, __u64 loop_cnt) ^ I prepared a reduced test case in case any clang developers want to take a closer look, but from looking at the earlier output it seems that even with clang-8, something was very wrong here. Turn off any KASAN and UBSAN sanitizing for this file, as that likely clashes with -O0 anyway. Turning off just KASAN avoids the warning already, but I suspect both of these have undesired side-effects for jitterentropy. Link: https://godbolt.org/z/fDcwZ5Signed-off-by: -
Nishka Dasgupta authored
Each iteration of for_each_compatible_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Add an of_node_put before the return. Issue found with Coccinelle. Acked-by:
Stewart Smith <stewart@linux.ibm.com> Signed-off-by:
Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by:
-
Masahiro Yamada authored
Function definitions in headers are usually marked as 'static inline'. Since 'inline' is missing for crypto_reportstat(), if it were not referenced from a .c file that includes this header, it would produce a warning. Also, 'struct crypto_user_alg' is not declared in this header. I included <linux/crytouser.h> instead of adding the forward declaration as suggested [1]. Detected by compile-testing this header as a standalone unit: ./include/crypto/internal/cryptouser.h:6:44: warning: ‘struct crypto_user_alg’ declared inside parameter list will not be visible outside of this definition or declaration struct crypto_alg *crypto_alg_match(struct crypto_user_alg *p, int exact); ^~~~~~~~~~~~~~~ ./include/crypto/internal/cryptouser.h:11:12: warning: ‘crypto_reportstat’ defined but not used [-Wunused-function] static int crypto_reportstat(struct sk_buff *in_skb, struct nlmsghdr *in_nlh, struct nlattr **attrs) ^~~~~~~~~~~~~~~~~ [1] https://lkml.org/lkml/2019/6/13/1121Signed-off-by: -
Masahiro Yamada authored
Add header include guards in case they are included multiple times. Signed-off-by:
-
Vakul Garg authored
Add support of printing the dpseci frame queue statistics using debugfs. Signed-off-by:
Vakul Garg <vakul.garg@nxp.com> Reviewed-by:
-
Alexander Sverdlin authored
It seems that smp_processor_id() is only used for a best-effort load-balancing, refer to qat_crypto_get_instance_node(). It's not feasible to disable preemption for the duration of the crypto requests. Therefore, just silence the warning. This commit is similar to e7a9b05c ("crypto: cavium - Fix smp_processor_id() warnings"). Silences the following splat: BUG: using smp_processor_id() in preemptible [00000000] code: cryptomgr_test/2904 caller is qat_alg_ablkcipher_setkey+0x300/0x4a0 [intel_qat] CPU: 1 PID: 2904 Comm: cryptomgr_test Tainted: P O 4.14.69 #1 ... Call Trace: dump_stack+0x5f/0x86 check_preemption_disabled+0xd3/0xe0 qat_alg_ablkcipher_setkey+0x300/0x4a0 [intel_qat] skcipher_setkey_ablkcipher+0x2b/0x40 __test_skcipher+0x1f3/0xb20 ? cpumask_next_and+0x26/0x40 ? find_busiest_group+0x10e/0x9d0 ? preempt_count_add+0x49/0xa0 ? try_module_get+0x61/0xf0 ? crypto_mod_get+0x15/0x30 ? __kmalloc+0x1df/0x1f0 ? __crypto_alloc_tfm+0x116/0x180 ? crypto_skcipher_init_tfm+0xa6/0x180 ? crypto_create_tfm+0x4b/0xf0 test_skcipher+0x21/0xa0 alg_test_skcipher+0x3f/0xa0 alg_test.part.6+0x126/0x2a0 ? finish_task_switch+0x21b/0x260 ? __schedule+0x1e9/0x800 ? __wake_up_common+0x8d/0x140 cryptomgr_test+0x40/0x50 kthread+0xff/0x130 ? cryptomgr_notify+0x540/0x540 ? kthread_create_on_node+0x70/0x70 ret_from_fork+0x24/0x50 Fixes: ed8ccaef ("crypto: qat - Add support for SRIOV") Cc: stable@vger.kernel.org Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
-
Chuhong Yuan authored
Use devm_hwrng_register to get rid of manual unregistration. Signed-off-by:
-
Herbert Xu authored
This reverts commit ecc8bc81 ("crypto: aegis128 - provide a SIMD implementation based on NEON intrinsics") and commit 7cdc0ddb ("crypto: aegis128 - add support for SIMD acceleration"). They cause compile errors on platforms other than ARM because the mechanism to selectively compile the SIMD code is broken. Repoted-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Reported-by:
-
- 31 Jul, 2019 2 commits
-
-
Ard Biesheuvel authored
The generic aegis128 software crypto driver recently gained support for using SIMD intrinsics to increase performance, for which it uncondionally #include's the <asm/simd.h> header. Unfortunately, this header does not exist on many architectures, resulting in build failures. Since asm-generic already has a version of simd.h, let's make it a mandatory header so that it gets instantiated on all architectures that don't provide their own version. Signed-off-by:
-
Ard Biesheuvel authored
The newly introduced AES library exposes aes_encrypt/aes_decrypt routines so rename existing occurrences of those identifiers in the s390 driver. Signed-off-by:
-
- 27 Jul, 2019 11 commits
-
-
Eric Biggers authored
To help avoid confusion, add a comment to ghash-generic.c which explains the convention that the kernel's implementation of GHASH uses. Also update the Kconfig help text and module descriptions to call GHASH a "hash function" rather than a "message digest", since the latter normally means a real cryptographic hash function, which GHASH is not. Cc: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by:
-
Daniel Jordan authored
With the removal of the padata timer, padata_do_serial no longer needs special CPU handling, so remove it. Signed-off-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Iuliana Prodan authored
Validated assoclen for RFC4543 which expects an assoclen of 16 or 20, the same as RFC4106. Based on seqiv, IPsec ESP and RFC4543/RFC4106 the assoclen is sizeof IP Header (spi, seq_no, extended seq_no) and IV len. This can be 16 or 20 bytes. Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by:
-
Iuliana Prodan authored
Check assoclen to solve the extra tests that expect -EINVAL to be returned when the associated data size is not valid. Validated assoclen for RFC4543 which expects an assoclen of 16 or 20, the same as RFC4106. Based on seqiv, IPsec ESP and RFC4543/RFC4106 the assoclen is sizeof IP Header (spi, seq_no, extended seq_no) and IV len. This can be 16 or 20 bytes. Signed-off-by:
-
Herbert Xu authored
The function padata_reorder will use a timer when it cannot progress while completed jobs are outstanding (pd->reorder_objects > 0). This is suboptimal as if we do end up using the timer then it would have introduced a gratuitous delay of one second. In fact we can easily distinguish between whether completed jobs are outstanding and whether we can make progress. All we have to do is look at the next pqueue list. This patch does that by replacing pd->processed with pd->cpu so that the next pqueue is more accessible. A work queue is used instead of the original try_again to avoid hogging the CPU. Note that we don't bother removing the work queue in padata_flush_queues because the whole premise is broken. You cannot flush async crypto requests so it makes no sense to even try. A subsequent patch will fix it by replacing it with a ref counting scheme. Signed-off-by: -
Arnd Bergmann authored
Clang sometimes makes very different inlining decisions from gcc. In case of the aegis crypto algorithms, it decides to turn the innermost primitives (and, xor, ...) into separate functions but inline most of the rest. This results in a huge amount of variables spilled on the stack, leading to rather slow execution as well as kernel stack usage beyond the 32-bit warning limit when CONFIG_KASAN is enabled: crypto/aegis256.c:123:13: warning: stack frame size of 648 bytes in function 'crypto_aegis256_encrypt_chunk' [-Wframe-larger-than=] crypto/aegis256.c:366:13: warning: stack frame size of 1264 bytes in function 'crypto_aegis256_crypt' [-Wframe-larger-than=] crypto/aegis256.c:187:13: warning: stack frame size of 656 bytes in function 'crypto_aegis256_decrypt_chunk' [-Wframe-larger-than=] crypto/aegis128l.c:135:13: warning: stack frame size of 832 bytes in function 'crypto_aegis128l_encrypt_chunk' [-Wframe-larger-than=] crypto/aegis128l.c:415:13: warning: stack frame size of 1480 bytes in function 'crypto_aegis128l_crypt' [-Wframe-larger-than=] crypto/aegis128l.c:218:13: warning: stack frame size of 848 bytes in function 'crypto_aegis128l_decrypt_chunk' [-Wframe-larger-than=] crypto/aegis128.c:116:13: warning: stack frame size of 584 bytes in function 'crypto_aegis128_encrypt_chunk' [-Wframe-larger-than=] crypto/aegis128.c:351:13: warning: stack frame size of 1064 bytes in function 'crypto_aegis128_crypt' [-Wframe-larger-than=] crypto/aegis128.c:177:13: warning: stack frame size of 592 bytes in function 'crypto_aegis128_decrypt_chunk' [-Wframe-larger-than=] Forcing the primitives to all get inlined avoids the issue and the resulting code is similar to what gcc produces. Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Chuhong Yuan authored
Use dma_pool_zalloc instead of using dma_pool_alloc to allocate memory and then zeroing it with memset 0. This simplifies the code. Signed-off-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
-
Vakul Garg authored
While running ipsec processing for traffic through multiple network interfaces, it is observed that caam driver gets less time to poll responses from caam block compared to ethernet driver. This is because ethernet driver has as many napi instances per cpu as the number of ethernet interfaces in system. Therefore, caam driver's napi executes lesser than the ethernet driver's napi instances. This results in situation that we end up submitting more requests to caam (which it is able to finish off quite fast), but don't dequeue the responses at same rate. This makes caam response FQs bloat with large number of frames. In some situations, it makes kernel crash due to out-of-memory. To prevent it We increase the napi budget of dpseci driver to a big value so that caam driver is able to drain its response queues at enough rate. Signed-off-by:
-
Anson Huang authored
Use the new helper devm_platform_ioremap_resource() which wraps the platform_get_resource() and devm_ioremap_resource() together, to simplify the code. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
Anson Huang authored
Use the new helper devm_platform_ioremap_resource() which wraps the platform_get_resource() and devm_ioremap_resource() together, to simplify the code. Signed-off-by:
-
Arnd Bergmann authored
Each of the operations in ccp_run_cmd() needs several hundred bytes of kernel stack. Depending on the inlining, these may need separate stack slots that add up to more than the warning limit, as shown in this clang based build: drivers/crypto/ccp/ccp-ops.c:871:12: error: stack frame size of 1164 bytes in function 'ccp_run_aes_cmd' [-Werror,-Wframe-larger-than=] static int ccp_run_aes_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd) The problem may also happen when there is no warning, e.g. in the ccp_run_cmd()->ccp_run_aes_cmd()->ccp_run_aes_gcm_cmd() call chain with over 2000 bytes. Mark each individual function as 'noinline_for_stack' to prevent this from happening, and move the calls to the two special cases for aes into the top-level function. This will keep the actual combined stack usage to the mimimum: 828 bytes for ccp_run_aes_gcm_cmd() and at most 524 bytes for each of the other cases. Fixes: 63b94509 ("crypto: ccp - CCP device driver and interface support") Signed-off-by:
-
- 26 Jul, 2019 13 commits
-
-
Hook, Gary authored
Redefine pr_fmt so that the module name is prefixed to every log message produced by the ccp-crypto module Signed-off-by:
-
Herbert Xu authored
The directory tools/crypto and the only file under it never gets built anywhere. This program should instead be incorporated into one of the existing user-space projects, crconf or libkcapi. Signed-off-by: -
Phani Kiran Hemadri authored
This patch adds support to load Asymmetric crypto firmware on AE cores of CNN55XX device. Firmware is stored on UCD block 2 and all available AE cores are tagged to group 0. Signed-off-by:
Phani Kiran Hemadri <phemadri@marvell.com> Reviewed-by:
Srikanth Jampala <jsrikanth@marvell.com> Signed-off-by:
-
Hook, Gary authored
The CCP driver is able to act as a DMA engine. Add a module parameter that allows this feature to be enabled/disabled. Signed-off-by:
-
Hook, Gary authored
Provide the ability to constrain the total number of enabled devices in the system. Once max_devs devices have been configured, subsequently probed devices are ignored. The max_devs parameter may be zero, in which case all CCPs are disabled. PSPs are always enabled and active. Disabling the CCPs also disables DMA and RNG registration. Signed-off-by:
-
Hook, Gary authored
Add a module parameter to limit the number of queues per CCP. The default value (nqueues=0) is to set up every available queue on each device. The count of queues starts from the first one found on the device (which varies based on the device ID). Signed-off-by:
-
Hook, Gary authored
Add a config option to exclude DebugFS support in the CCP driver. Signed-off-by:
-
Ondrej Mosnacek authored
Currently, NETLINK_CRYPTO works only in the init network namespace. It doesn't make much sense to cut it out of the other network namespaces, so do the minor plumbing work necessary to make it work in any network namespace. Code inspired by net/core/sock_diag.c. Tested using kcapi-dgst from libkcapi [1]: Before: # unshare -n kcapi-dgst -c sha256 </dev/null | wc -c libkcapi - Error: Netlink error: sendmsg failed libkcapi - Error: Netlink error: sendmsg failed libkcapi - Error: NETLINK_CRYPTO: cannot obtain cipher information for hmac(sha512) (is required crypto_user.c patch missing? see documentation) 0 After: # unshare -n kcapi-dgst -c sha256 </dev/null | wc -c 32 [1] https://github.com/smuellerDD/libkcapiSigned-off-by:Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by:
-
Pascal van Leeuwen authored
This patch recognises the fact that the hardware cannot ever process more than 2,199,023,386,111 bytes of hash or HMAC payload, so there is no point in maintaining 128 bit wide byte counters, 64 bits is more than sufficient Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds support for the following AEAD ciphersuites: - authenc(hmac(sha1),rfc3686(ctr(aes))) - authenc(hmac(sha224),rfc3686(ctr(aes))) - authenc(hmac(sha256),rfc3686(ctr(aes))) - authenc(hmac(sha384),rfc3686(ctr(aes))) - authenc(hmac(sha512),rfc3686(ctr(aes))) Signed-off-by:
-
Pascal van Leeuwen authored
Signed-off-by:
-
Pascal van Leeuwen authored
Signed-off-by:
-
Sebastian Andrzej Siewior authored
For spinlocks the type spinlock_t should be used instead of "struct spinlock". Use spinlock_t for spinlock's definition. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
