- 01 Oct, 2019 2 commits
-
-
Ard Biesheuvel authored
The ARM accelerated AES driver depends on the new AES library for its non-SIMD fallback so express this in its Kconfig declaration. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
The NEON/Crypto Extensions based AES implementation for 32-bit ARM can be built in a kernel that targets ARMv6 CPUs and higher, even though the actual code will not be able to run on that generation, but it allows for a portable image to be generated that can will use the special instructions only when they are available. Since those instructions are part of a FPU profile rather than a CPU profile, we don't override the architecture in the assembler code, and most of the scalar code is simple enough to be ARMv6 compatible. However, that changes with commit c61b1607, which introduces calls to the movw/movt instructions, which are v7+ only. So override the architecture in the .S file to armv8-a, which matches the architecture specification in the crypto-neon-fp-armv8 FPU specificier that we already using. Note that using armv7-a here may trigger an issue with the upcoming Clang 10 release, which no longer permits .arch/.fpu combinations it views as incompatible. Reported-by:
kbuild test robot <lkp@intel.com> Fixes: c61b1607 ("crypto: arm/aes-ce - implement ciphertext stealing ...") Signed-off-by:
-
- 20 Sep, 2019 7 commits
-
-
Arnd Bergmann authored
The only caller of hisi_zip_vf_q_assign() is hidden in an #ifdef, so the function causes a warning when CONFIG_PCI_IOV is disabled: drivers/crypto/hisilicon/zip/zip_main.c:740:12: error: unused function 'hisi_zip_vf_q_assign' [-Werror,-Wunused-function] Replace the #ifdef with an IS_ENABLED() check that leads to the function being dropped based on the configuration. Fixes: 79e09f30 ("crypto: hisilicon - add SRIOV support for ZIP") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Laurent Vivier authored
add_early_randomness() is called by hwrng_register() when the hardware is added. If this hardware and its module are present at boot, and if there is no data available the boot hangs until data are available and can't be interrupted. For instance, in the case of virtio-rng, in some cases the host can be not able to provide enough entropy for all the guests. We can have two easy ways to reproduce the problem but they rely on misconfiguration of the hypervisor or the egd daemon: - if virtio-rng device is configured to connect to the egd daemon of the host but when the virtio-rng driver asks for data the daemon is not connected, - if virtio-rng device is configured to connect to the egd daemon of the host but the egd daemon doesn't provide data. The guest kernel will hang at boot until the virtio-rng driver provides enough data. To avoid that, call rng_get_data() in non-blocking mode (wait=0) from add_early_randomness(). Signed-off-by:
Laurent Vivier <lvivier@redhat.com> Fixes: d9e79726 ("hwrng: add randomness to system from rng...") Cc: <stable@vger.kernel.org> Reviewed-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Yunfeng Ye authored
The return valude of add_comp_head() is int, but @head_size is size_t, which is a unsigned type. size_t head_size; ... if (head_size < 0) // it will never work return -ENOMEM Modify the type of @head_size to int, then change the type to size_t when invoke hisi_zip_create_req() as a parameter. Fixes: 62c455ca ("crypto: hisilicon - add HiSilicon ZIP accelerator support") Signed-off-by:
Yunfeng Ye <yeyunfeng@huawei.com> Acked-by:
Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
-
Yunfeng Ye authored
When dma_pool_zalloc() fail in sec_alloc_and_fill_hw_sgl(), dma_pool_free() is invoked, but the parameters that sgl_current and sgl_current->next_sgl is not match. Using sec_free_hw_sgl() instead of the original free routine. Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver") Signed-off-by:
-
Yunfeng Ye authored
There are two problems in sec_free_hw_sgl(): First, when sgl_current->next is valid, @hw_sgl will be freed in the first loop, but it free again after the loop. Second, sgl_current and sgl_current->next_sgl is not match when dma_pool_free() is invoked, the third parameter should be the dma address of sgl_current, but sgl_current->next_sgl is the dma address of next chain, so use sgl_current->next_sgl is wrong. Fix this by deleting the last dma_pool_free() in sec_free_hw_sgl(), modifying the condition for while loop, and matching the address for dma_pool_free(). Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver") Signed-off-by:
-
Pascal van Leeuwen authored
This patch fixes an unused variable warning from the compiler when the driver is being compiled without PCI support in the kernel. Fixes: 625f269a ("crypto: inside-secure - add support for...") Signed-off-by:
Pascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Add missing break statement in order to prevent the code from falling through to case CRYPTO_ALG_TYPE_AHASH. Fixes: aeb4c132 ("crypto: talitos - Convert to new AEAD interface") Cc: stable@vger.kernel.org Reported-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
- 13 Sep, 2019 18 commits
-
-
Herbert Xu authored
While storing an int in a pointer is safe the compiler is not happy about it. So we need some extra casting in order to make this warning free. Fixes: 1d3f75bce123 ("crypto: caam - dispose of IRQ mapping only...") Signed-off-by:Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Uri Shir authored
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 <uri.shir@arm.com> Acked-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
-
Pascal van Leeuwen authored
This patch actually probes the transform record cache data and administration RAM sizes, instead of making assumptions, and then configures the TRC based on the actually probed values. This allows the driver to work with EIP197 HW that has TRC RAM sizes different from those of the Marvell EIP197B/D variants. Signed-off-by:
-
Pascal van Leeuwen authored
This patch derives the result descriptor fetch count from the actual FIFO size advertised by the hardware. Fetching result descriptors one at a time is a performance bottleneck for small blocks, especially on hardware with multiple pipes. Even moreso if the HW has few rings. Signed-off-by:
-
Pascal van Leeuwen authored
This patch derives the command descriptor fetch count from the actual FIFO size advertised by the hardware. Fetching command descriptors one at a time is a performance bottleneck for small blocks, especially on hardware with multiple pipes. Even moreso if the HW has few rings. Signed-off-by:
-
Pascal van Leeuwen authored
This patch enables algorithms that did not fit the original 32 bit FUNCTION_EN register anymore via the FUNCTION2_EN extension reg. Signed-off-by:
-
Pascal van Leeuwen authored
This patch corrects the configuration of the EIP197_PE_EIP96_TOKEN_CTRL register. Previous value was wrong and potentially dangerous. Signed-off-by:
-
Pascal van Leeuwen authored
This patch adds automatic EIP97/EIP197 detection, so it does not need to rely on any static value from the device table anymore. In particular, the static value from the table won't work for PCI devboards that cannot be further identified save from this direct hardware probing. The patch also adds automatic host xs endianness detection & correction. Signed-off-by:
-
Daniel Jordan authored
With the removal of the ENODATA case from padata_get_next, the cpu_index field is no longer useful, so it can go away. Signed-off-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Acked-by:
Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Daniel Jordan authored
Padata binds the parallel part of a job to a single CPU and round-robins over all CPUs in the system for each successive job. Though the serial parts rely on per-CPU queues for correct ordering, they're not necessary for parallel work, and it improves performance to run the job locally on NUMA machines and let the scheduler pick the CPU within a node on a busy system. So, make the parallel workqueue unbound. Update the parallel workqueue's cpumask when the instance's parallel cpumask changes. Now that parallel jobs no longer run on max_active=1 workqueues, two or more parallel works that hash to the same CPU may run simultaneously, finish out of order, and so be serialized out of order. Prevent this by keeping the works sorted on the reorder list by sequence number and checking that in the reordering logic. padata_get_next becomes padata_find_next so it can be reused for the end of padata_reorder, where it's used to avoid uselessly queueing work when the next job by sequence number isn't finished yet but a later job that hashed to the same CPU has. The ENODATA case in padata_find_next no longer makes sense because parallel jobs aren't bound to specific CPUs. The EINPROGRESS case takes care of the scenario where a parallel job is potentially running on the same CPU as padata_find_next, and with only one error code left, just use NULL instead. Signed-off-by:
-
Daniel Jordan authored
padata currently uses one per-CPU workqueue per instance for all work. Prepare for running parallel jobs on an unbound workqueue by introducing dedicated workqueues for parallel and serial work. Signed-off-by:
-
Daniel Jordan authored
With pcrypt's cpumask no longer used, take the CPU hotplug lock inside padata_alloc_possible. Useful later in the series for avoiding nested acquisition of the CPU hotplug lock in padata when padata_alloc_possible is allocating an unbound workqueue. Without this patch, this nested acquisition would happen later in the series: pcrypt_init_padata get_online_cpus alloc_padata_possible alloc_padata alloc_workqueue(WQ_UNBOUND) // later in the series alloc_and_link_pwqs apply_wqattrs_lock get_online_cpus // recursive rwsem acquisition Signed-off-by: -
Daniel Jordan authored
Now that padata_do_parallel takes care of finding an alternate callback CPU, there's no need for pcrypt's callback cpumask, so remove it and the notifier callback that keeps it in sync. Signed-off-by:
-
Daniel Jordan authored
padata_do_parallel currently returns -EINVAL if the callback CPU isn't in the callback cpumask. pcrypt tries to prevent this situation by keeping its own callback cpumask in sync with padata's and checks that the callback CPU it passes to padata is valid. Make padata handle this instead. padata_do_parallel now takes a pointer to the callback CPU and updates it for the caller if an alternate CPU is used. Overall behavior in terms of which callback CPUs are chosen stays the same. Prepares for removal of the padata cpumask notifier in pcrypt, which will fix a lockdep complaint about nested acquisition of the CPU hotplug lock later in the series. Signed-off-by:
-
Daniel Jordan authored
Change the calling convention for apply_workqueue_attrs to require CPU hotplug read exclusion. Avoids lockdep complaints about nested calls to get_online_cpus in a future patch where padata calls apply_workqueue_attrs when changing other CPU-hotplug-sensitive data structures with the CPU read lock already held. Signed-off-by:
Tejun Heo <tj@kernel.org> Acked-by:
-
Daniel Jordan authored
padata will use these these interfaces in a later patch, so unconfine them. Signed-off-by:
-
Daniel Jordan authored
Move workqueue allocation inside of padata to prepare for further changes to how padata uses workqueues. Guarantees the workqueue is created with max_active=1, which padata relies on to work correctly. No functional change. Signed-off-by:
-
Andrey Smirnov authored
Add node for CAAM - Cryptographic Acceleration and Assurance Module. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by:
Li Yang <leoyang.li@nxp.com> Signed-off-by:
-
- 09 Sep, 2019 13 commits
-
-
Stephen Boyd authored
Sebastian reports that after commit ff296293 ("random: Support freezable kthreads in add_hwgenerator_randomness()") we can call might_sleep() when the task state is TASK_INTERRUPTIBLE (state=1). This leads to the following warning. do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000349d1489>] prepare_to_wait_event+0x5a/0x180 WARNING: CPU: 0 PID: 828 at kernel/sched/core.c:6741 __might_sleep+0x6f/0x80 Modules linked in: CPU: 0 PID: 828 Comm: hwrng Not tainted 5.3.0-rc7-next-20190903+ #46 RIP: 0010:__might_sleep+0x6f/0x80 Call Trace: kthread_freezable_should_stop+0x1b/0x60 add_hwgenerator_randomness+0xdd/0x130 hwrng_fillfn+0xbf/0x120 kthread+0x10c/0x140 ret_from_fork+0x27/0x50 We shouldn't call kthread_freezable_should_stop() from deep within the wait_event code because the task state is still set as TASK_INTERRUPTIBLE instead of TASK_RUNNING and kthread_freezable_should_stop() will try to call into the freezer with the task in the wrong state. Use wait_event_freezable() instead so that it calls schedule() in the right place and tries to enter the freezer when the task state is TASK_RUNNING instead. Reported-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Herbert Xu authored
This patch fixes a number of warnings encountered when this driver is built on a 64-bit platform with COMPILE_TEST. Signed-off-by: -
Ard Biesheuvel authored
The RFC4106 key derivation code instantiates an AES cipher transform to encrypt only a single block before it is freed again. Switch to the new AES library which is more suitable for such use cases. Signed-off-by:
-
Wei Yongjun authored
When using single_open() for opening, single_release() should be used instead of seq_release(), otherwise there is a memory leak. Fixes: 09ae5d37 ("crypto: zip - Add Compression/Decompression statistics") Cc: <stable@vger.kernel.org> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
zhong jiang authored
Use kzfree instead of memset() + kfree(). Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
-
Andrey Smirnov authored
With IRQ requesting being managed by devres we need to make sure that we dispose of IRQ mapping after and not before it is free'd (otherwise we'll end up with a warning from the kernel). To achieve that simply convert IRQ mapping to rely on devres as well. Fixes: f314f12db65c ("crypto: caam - convert caam_jr_init() to use devres") Signed-off-by: -
Andrey Smirnov authored
Irq_of_parse_and_map will return zero in case of error, so add a error check for that. Signed-off-by:
-
Andrey Smirnov authored
Use devres to unmap memory and drop explicit de-initialization code. NOTE: There's no corresponding unmapping code in caam_jr_remove which seems like a resource leak. Signed-off-by:
-
Andrey Smirnov authored
In order to access IP block's registers we need to enable appropriate clocks first, otherwise we are risking hanging the CPU. The problem becomes very apparent when trying to use CAAM driver built as a kernel module. In that case caam_probe() gets called after clk_disable_unused() which means all of the necessary clocks are guaranteed to be disabled. Coincidentally, this change also fixes iomap leak introduced by early return (instead of "goto iounmap_ctrl") in commit 41fc54afae70 ("crypto: caam - simplfy clock initialization") Tested on ZII i.MX6Q+ RDU2 Fixes: 176435ad ("crypto: caam - defer probing until QMan is available") Fixes: 41fc54afae70 ("crypto: caam - simplfy clock initialization") Signed-off-by: -
Ard Biesheuvel authored
Instead of relying on the CTS template to wrap the accelerated CBC skcipher, implement the ciphertext stealing part directly. Signed-off-by:
-
Ard Biesheuvel authored
Update the AES-XTS implementation based on NEON instructions so that it can deal with inputs whose size is not a multiple of the cipher block size. This is part of the original XTS specification, but was never implemented before in the Linux kernel. Signed-off-by:
-
Ard Biesheuvel authored
Update the AES-XTS implementation based on AES instructions so that it can deal with inputs whose size is not a multiple of the cipher block size. This is part of the original XTS specification, but was never implemented before in the Linux kernel. Signed-off-by:
-
Ard Biesheuvel authored
Update the AES-XTS implementation based on NEON instructions so that it can deal with inputs whose size is not a multiple of the cipher block size. This is part of the original XTS specification, but was never implemented before in the Linux kernel. Since the bit slicing driver is only faster if it can operate on at least 7 blocks of input at the same time, let's reuse the alternate path we are adding for CTS to process any data tail whose size is not a multiple of 128 bytes. Signed-off-by:
-
