kernel/linux.git/drivers/crypto/stm32, branch v5.9.12

crypto: stm32/crc32 - Avoid lock if hardware is already used

2020-10-29T09:11:08+00:00

[ Upstream commit bbf2cb1ea1e1428589d7f4d652bed15b265ce92d ] If STM32 CRC device is already in use, calculate CRC by software. This will release CPU constraint for a concurrent access to the hardware, and avoid masking irqs during the whole block processing. Fixes: 7795c0baf5ac ("crypto: stm32/crc32 - protect from concurrent accesses") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: stm32/crc32 - protect from concurrent accesses

2020-05-22T14:08:21+00:00

Protect STM32 CRC device from concurrent accesses. As we create a spinlocked section that increase with buffer size, we provide a module parameter to release the pressure by splitting critical section in chunks. Size of each chunk is defined in burst_size module parameter. By default burst_size=0, i.e. don't split incoming buffer. Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu

crypto: stm32/crc32 - don't sleep in runtime pm

2020-05-22T14:08:21+00:00

Ensure stm32_crc_update() and stm32_crc_init() can be called in atomic context and can't sleep. Add pm_runtime_irq_safe() to make pm_runtime_get_sync() atomic. Change runtime pm to call clk_enable()/clk_disable() and change system pm to unprepare/prepare the clock and force runtime pm suspend/resume. Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu

crypto: stm32/crc32 - fix multi-instance

2020-05-22T14:08:20+00:00

Ensure CRC algorithm is registered only once in crypto framework when there are several instances of CRC devices. Update the CRC device list management to avoid that only the first CRC instance is used. Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu

crypto: stm32/crc32 - fix run-time self test issue.

2020-05-22T14:08:20+00:00

Fix wrong crc32 initialisation value: "alg: shash: stm32_crc32 test failed (wrong result) on test vector 0, cfg="init+update+final aligned buffer" cra_name="crc32c" expects an init value of 0XFFFFFFFF, cra_name="crc32" expects an init value of 0. Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu

crypto: stm32/crc32 - fix ext4 chksum BUG_ON()

2020-05-22T14:08:20+00:00

Allow use of crc_update without prior call to crc_init. And change (and fix) driver to use CRC device even on unaligned buffers. Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module") Signed-off-by: Nicolas Toromanoff Signed-off-by: Herbert Xu

crypto: stm32/hash - don't print error on probe deferral

2020-05-08T05:30:39+00:00

Change driver to not print an error message when the device probe is deferred for a clock resource. Signed-off-by: Lionel Debieve Signed-off-by: Herbert Xu

crypto: stm32/hash - defer probe for dma device

2020-05-08T05:30:39+00:00

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 Reviewed-by: Lionel DEBIEVE Signed-off-by: Herbert Xu

crypto: stm32/hash - defer probe for reset controller

2020-05-08T05:30:39+00:00

Change stm32 HASH driver to defer its probe operation when reset controller device is registered but has not been probed yet. Signed-off-by: Etienne Carriere Reviewed-by: Lionel DEBIEVE Signed-off-by: Herbert Xu

crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN

2020-01-09T03:30:53+00:00

The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. Also, many algorithms fail to set this flag when given a bad length key. Reviewing just the generic implementations, this is the case for aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably many more in arch/*/crypto/ and drivers/crypto/. Some algorithms can even set this flag when the key is the correct length. For example, authenc and authencesn set it when the key payload is malformed in any way (not just a bad length), the atmel-sha and ccree drivers can set it if a memory allocation fails, and the chelsio driver sets it for bad auth tag lengths, not just bad key lengths. So even if someone actually wanted to start checking this flag (which seems unlikely, since it's been unused for a long time), there would be a lot of work needed to get it working correctly. But it would probably be much better to go back to the drawing board and just define different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by: Eric Biggers Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu