- 20 May, 2022 10 commits
-
-
Giovanni Cabiddu authored
If a request has the flag CRYPTO_TFM_REQ_MAY_SLEEP set, allocate memory using the flag GFP_KERNEL otherwise use GFP_ATOMIC. Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by:
Adam Guerin <adam.guerin@intel.com> Reviewed-by:
Wojciech Ziemba <wojciech.ziemba@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Giovanni Cabiddu authored
Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. Cc: stable@vger.kernel.org Signed-off-by:
-
Giovanni Cabiddu authored
Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. Cc: stable@vger.kernel.org Signed-off-by:
-
Giovanni Cabiddu authored
The functions qat_dh_compute_value() allocates memory with dma_alloc_coherent() if the source or the destination buffers are made of multiple flat buffers or of a size that is not compatible with the hardware. This memory is then freed with dma_free_coherent() in the context of a tasklet invoked to handle the response for the corresponding request. According to Documentation/core-api/dma-api-howto.rst, the function dma_free_coherent() cannot be called in an interrupt context. Replace allocations with dma_alloc_coherent() in the function qat_dh_compute_value() with kmalloc() + dma_map_single(). Cc: stable@vger.kernel.org Fixes: c9839143 ("crypto: qat - Add DH support") Signed-off-by:
-
Giovanni Cabiddu authored
After commit f5ff79fd ("dma-mapping: remove CONFIG_DMA_REMAP"), if the algorithms are enabled, the driver crashes with a BUG_ON while executing vunmap() in the context of a tasklet. This is due to the fact that the function dma_free_coherent() cannot be called in an interrupt context (see Documentation/core-api/dma-api-howto.rst). The functions qat_rsa_enc() and qat_rsa_dec() allocate memory with dma_alloc_coherent() if the source or the destination buffers are made of multiple flat buffers or of a size that is not compatible with the hardware. This memory is then freed with dma_free_coherent() in the context of a tasklet invoked to handle the response for the corresponding request. Replace allocations with dma_alloc_coherent() in the functions qat_rsa_enc() and qat_rsa_dec() with kmalloc() + dma_map_single(). Cc: stable@vger.kernel.org Fixes: a9905320 ("crypto: qat - Add support for RSA algorithm") Signed-off-by:
-
Giovanni Cabiddu authored
When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is used, some components of the private key persist even after the TFM is released. Replace the explicit calls to free the buffers in qat_rsa_exit_tfm() with a call to qat_rsa_clear_ctx() which frees all buffers referenced in the TFM context. Cc: stable@vger.kernel.org Fixes: 879f77e9 ("crypto: qat - Add RSA CRT mode") Signed-off-by:
-
Giovanni Cabiddu authored
The implementations of the crypto algorithms (aead, skcipher, etc) in the QAT driver do not properly support requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set. If the HW queue is full, the driver returns -EBUSY but does not enqueue the request. This can result in applications like dm-crypt waiting indefinitely for the completion of a request that was never submitted to the hardware. Fix this by adding a software backlog queue: if the ring buffer is more than eighty percent full, then the request is enqueued to a backlog list and the error code -EBUSY is returned back to the caller. Requests in the backlog queue are resubmitted at a later time, in the context of the callback of a previously submitted request. The request for which -EBUSY is returned is then marked as -EINPROGRESS once submitted to the HW queues. The submission loop inside the function qat_alg_send_message() has been modified to decide which submission policy to use based on the request flags. If the request does not have the CRYPTO_TFM_REQ_MAY_BACKLOG set, the previous behaviour has been preserved. Based on a patch by Vishnu Das Ramachandran <vishnu.dasx.ramachandran@intel.com> Cc: stable@vger.kernel.org Fixes: d370cec3 ("crypto: qat - Intel(R) QAT crypto interface") Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Reported-by:
Kyle Sanderson <kyle.leet@gmail.com> Signed-off-by:
Marco Chiappero <marco.chiappero@intel.com> Signed-off-by:
-
Giovanni Cabiddu authored
All the algorithms in qat_algs.c and qat_asym_algs.c use the same pattern to submit messages to the HW queues. Move the submission loop to a new function, qat_alg_send_message(), and share it between the symmetric and the asymmetric algorithms. As part of this rework, since the number of retries before returning an error is inconsistent between the symmetric and asymmetric implementations, set it to a value that works for both (i.e. 20, was 10 in qat_algs.c and 100 in qat_asym_algs.c) In addition fix the return code reported when the HW queues are full. In that case return -ENOSPC instead of -EBUSY. Including stable in CC since (1) the error code returned if the HW queues are full is incorrect and (2) to facilitate the backport of the next fix "crypto: qat - add backlog mechanism". Cc: stable@vger.kernel.org Signed-off-by:
-
Giovanni Cabiddu authored
In order to do DMAs, the QAT device requires that the scatterlist structures are mapped and translated into a format that the firmware can understand. This is defined as the composition of a scatter gather list (SGL) descriptor header, the struct qat_alg_buf_list, plus a variable number of flat buffer descriptors, the struct qat_alg_buf. The allocation and mapping of these data structures is done each time a request is received from the skcipher and aead APIs. In an OOM situation, this behaviour might lead to a dead-lock if an allocation fails. Based on the conversation in [1], increase the size of the aead and skcipher request contexts to include an SGL descriptor that can handle a maximum of 4 flat buffers. If requests exceed 4 entries buffers, memory is allocated dynamically. [1] https://lore.kernel.org/linux-crypto/20200722072932.GA27544@gondor.apana.org.au/ Cc: stable@vger.kernel.org Fixes: d370cec3 ("crypto: qat - Intel(R) QAT crypto interface") Reported-by:
-
Giovanni Cabiddu authored
Set to zero the context buffers containing the DH key before they are freed. This is a defense in depth measure that avoids keys to be recovered from memory in case the system is compromised between the free of the buffer and when that area of memory (containing keys) gets overwritten. Cc: stable@vger.kernel.org Fixes: c9839143 ("crypto: qat - Add DH support") Signed-off-by:
-
- 13 May, 2022 23 commits
-
-
Vladis Dronov authored
Implement a crypto library interface for the s390-native ChaCha20 cipher algorithm. This allows us to stop to select CRYPTO_CHACHA20 and instead select CRYPTO_ARCH_HAVE_LIB_CHACHA. This allows BIG_KEYS=y not to build a whole ChaCha20 crypto infrastructure as a built-in, but build a smaller CRYPTO_LIB_CHACHA instead. Make CRYPTO_CHACHA_S390 config entry to look like similar ones on other architectures. Remove CRYPTO_ALGAPI select as anyway it is selected by CRYPTO_SKCIPHER. Add a new test module and a test script for ChaCha20 cipher and its interfaces. Here are test results on an idle z15 machine: Data | Generic crypto TFM | s390 crypto TFM | s390 lib size | enc dec | enc dec | enc dec -----+--------------------+------------------+---------------- 512b | 1545ns 1295ns | 604ns 446ns | 430ns 407ns 4k | 9536ns 9463ns | 2329ns 2174ns | 2170ns 2154ns 64k | 149.6us 149.3us | 34.4us 34.5us | 33.9us 33.1us 6M | 23.61ms 23.11ms | 4223us 4160us | 3951us 4008us 60M | 143.9ms 143.9ms | 33.5ms 33.2ms | 32.2ms 32.1ms Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Reviewed-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
-
jianchunfu authored
Use the defined variable "desc" to uniform coding style. Signed-off-by:
jianchunfu <jianchunfu@cmss.chinamobile.com> Signed-off-by:
-
Minghao Chi authored
Simplify the return expression. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The access to cryptd_queue::cpu_queue is synchronized by disabling preemption in cryptd_enqueue_request() and disabling BH in cryptd_queue_worker(). This implies that access is allowed from BH. If cryptd_enqueue_request() is invoked from preemptible context _and_ soft interrupt then this can lead to list corruption since cryptd_enqueue_request() is not protected against access from soft interrupt. Replace get_cpu() in cryptd_enqueue_request() with local_bh_disable() to ensure BH is always disabled. Remove preempt_disable() from cryptd_queue_worker() since it is not needed because local_bh_disable() ensures synchronisation. Fixes: 254eff77 ("crypto: cryptd - Per-CPU thread implementation...") Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Corentin Labbe authored
The sg length could be more than remaining data on it. So check the length requirement against the minimum between those two values. Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Signed-off-by:
-
Corentin Labbe authored
The "Fallback for xxx" message is annoying, remove it and store the information in the debugfs. Let's add more precise fallback stats and display it better. Signed-off-by:
-
Corentin Labbe authored
When testing with some large SG list, the sun8i-ce drivers always fallback even if it can handle it. So use sg_nents_for_len() which permits to see less SGs than needed. Signed-off-by:
-
Corentin Labbe authored
Move all padding work to a dedicated function. Signed-off-by:
-
Corentin Labbe authored
The sg length could be more than remaining data on it. So check the length requirement against the minimum between those two values. Signed-off-by:
-
Corentin Labbe authored
Even if sun8i-ss does not handle hmac(sha1) directly, we can provide one which use the already supported acceleration of sha1. Signed-off-by:
-
Corentin Labbe authored
Move all padding work to a dedicated function. Signed-off-by:
-
Corentin Labbe authored
The "Fallback for xxx" message is annoying, remove it and store the information in the debugfs. In the same time, reports more fallback statistics. Signed-off-by:
-
Corentin Labbe authored
The current sun8i-ss handle only requests with all SG length being modulo 64. But the last SG could be always handled by copying it on the pad buffer. Signed-off-by:
-
Corentin Labbe authored
Instead of memset all pad buffer, it is faster to only put 0 where needed. Signed-off-by:
-
Corentin Labbe authored
Instead of allocate memory on each requests, it is easier to pre-allocate buffers. This made error path easier. Signed-off-by:
-
Corentin Labbe authored
When testing with some large SG list, the sun8i-ss drivers always fallback even if it can handle it. So use sg_nents_for_len() which permits to see less SGs than needed. Signed-off-by:
-
Corentin Labbe authored
The first thing we should do after dma_map_single() is to test the result. Signed-off-by:
-
Corentin Labbe authored
Some fallback tests were redundant with what sun8i_ss_hash_need_fallback() already do. Signed-off-by:
-
Corentin Labbe authored
sun8i-ss does not handle well the possible zero sized sg. Fixes: d9b45418 ("crypto: sun8i-ss - support hash algorithms") Signed-off-by:
-
Corentin Labbe authored
sun8i-ss fail handling IVs when doing decryption of multiple SGs in-place. It should backup the last block of each SG source for using it later as IVs. In the same time remove allocation on requests path for storing all IVs. Fixes: f08fcced ("crypto: allwinner - Add sun8i-ss cryptographic offloader") Signed-off-by:
-
Corentin Labbe authored
Instead of allocate memory on each requests, it is easier to pre-allocate buffer for backup IV. This made error path easier. Signed-off-by:
-
Corentin Labbe authored
Instead of allocate memory on each requests, it is easier to pre-allocate buffer for IV. This made error path easier. Signed-off-by:
-
Corentin Labbe authored
This patch remove a double blank line. Signed-off-by:
-
- 10 May, 2022 1 commit
-
-
Masahiro Yamada authored
When I refactored this Makefile, I accidentally changed the CONFIG option. Fixes: b52455a7 ("crypto: vmx - Align the short log with Makefile cleanups") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
- 06 May, 2022 6 commits
-
-
Masahiro Yamada authored
I notieced the log is not properly aligned: PERL drivers/crypto/vmx/aesp8-ppc.S CC [M] fs/xfs/xfs_reflink.o PERL drivers/crypto/vmx/ghashp8-ppc.S CC [M] drivers/crypto/vmx/aes.o Add some spaces after 'PERL'. While I was here, I cleaned up the Makefile: - Merge the two similar rules - Remove redundant 'clean-files' (Having 'targets' is enough) - Move the flavour into the build command This still avoids the build failures fixed by commit 4ee812f6 ("crypto: vmx - Avoid weird build failures"). Signed-off-by:
-
Tetsuo Handa authored
Flushing system-wide workqueues is dangerous and will be forbidden. Replace system_wq with local atmel_wq. If CONFIG_CRYPTO_DEV_ATMEL_{I2C,ECC,SHA204A}=y, the ordering in Makefile guarantees that module_init() for atmel-i2c runs before module_init() for atmel-ecc and atmel-sha204a runs. Link: https://lkml.kernel.org/r/49925af7-78a8-a3dd-bce6-cfc02e1a9236@I-love.SAKURA.ne.jpSigned-off-by:Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
Uwe Kleine-König authored
There is no semantical change introduced by this change. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
-
Meenakshi Aggarwal authored
Add support for random number generation using PRNG mode of CAAM and expose the interface through crypto API. According to the RM, the HW implementation of the DRBG follows NIST SP 800-90A specification for DRBG_Hash SHA-256 function Signed-off-by:
Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> Reviewed-by:
Horia Geant <horia.geanta@nxp.com> Signed-off-by:
-
Herbert Xu authored
This patch enables COMPILE_TEST for cn10k. Signed-off-by: -
Uwe Kleine-König authored
Returning an error value in an i2c remove callback results in an error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. As atmel_sha204a_remove already emits an error message ant the additional error message by the i2c core doesn't add any useful information, change the return value to zero to suppress this error message. Note that after atmel_sha204a_remove() returns *i2c_priv is freed, so there is trouble ahead because atmel_sha204a_rng_done() might be called after that freeing. So make the error message a bit more frightening. Signed-off-by:
-
