kernel/linux.git/drivers/crypto/caam, branch v5.4.50

crypto: caam - fix the address of the last entry of S/G

2020-05-06T06:15:07+00:00

commit 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d upstream. For skcipher algorithms, the input, output HW S/G tables look like this: [IV, src][dst, IV] Now, we can have 2 conditions here: - there is no IV; - src and dst are equal (in-place encryption) and scattered and the error is an "off-by-one" in the HW S/G table. This issue was seen with KASAN: BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018 Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321 CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted 5.6.0-rc1-00165-ge4ef8383-dirty #4 Hardware name: LS1046A RDB Board (DT) Call trace: dump_backtrace+0x0/0x260 show_stack+0x14/0x20 dump_stack+0xe8/0x144 print_address_description.isra.11+0x64/0x348 __kasan_report+0x11c/0x230 kasan_report+0xc/0x18 __asan_load4+0x90/0xb0 skcipher_edesc_alloc+0x95c/0x1018 skcipher_encrypt+0x84/0x150 crypto_skcipher_encrypt+0x50/0x68 test_skcipher_vec_cfg+0x4d4/0xc10 test_skcipher_vec+0x178/0x1d8 alg_test_skcipher+0xec/0x230 alg_test.part.44+0x114/0x4a0 alg_test+0x1c/0x60 cryptomgr_test+0x34/0x58 kthread+0x1b8/0x1c0 ret_from_fork+0x10/0x18 Allocated by task 321: save_stack+0x24/0xb0 __kasan_kmalloc.isra.10+0xc4/0xe0 kasan_kmalloc+0xc/0x18 __kmalloc+0x178/0x2b8 skcipher_edesc_alloc+0x21c/0x1018 skcipher_encrypt+0x84/0x150 crypto_skcipher_encrypt+0x50/0x68 test_skcipher_vec_cfg+0x4d4/0xc10 test_skcipher_vec+0x178/0x1d8 alg_test_skcipher+0xec/0x230 alg_test.part.44+0x114/0x4a0 alg_test+0x1c/0x60 cryptomgr_test+0x34/0x58 kthread+0x1b8/0x1c0 ret_from_fork+0x10/0x18 Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff000022a02800 which belongs to the cache dma-kmalloc-512 of size 512 The buggy address is located 344 bytes inside of 512-byte region [ffff000022a02800, ffff000022a02a00) The buggy address belongs to the page: page:fffffe00006a8000 refcount:1 mapcount:0 mapping:ffff00093200c400 index:0x0 compound_mapcount: 0 flags: 0xffff00000010200(slab|head) raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff000022a02800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff000022a02880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff000022a02900: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc ^ ffff000022a02980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff000022a02a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support") Cc: # v5.3+ Signed-off-by: Iuliana Prodan Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - update xts sector size for large input length

2020-04-17T08:50:18+00:00

commit 3f142b6a7b573bde6cff926f246da05652c61eb4 upstream. Since in the software implementation of XTS-AES there is no notion of sector every input length is processed the same way. CAAM implementation has the notion of sector which causes different results between the software implementation and the one in CAAM for input lengths bigger than 512 bytes. Increase sector size to maximum value on 16 bits. Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)") Cc: # v4.12+ Signed-off-by: Andrei Botila Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam/qi2 - fix chacha20 data size error

2020-04-17T08:50:18+00:00

commit 3a5a9e1ef37b030b836d92df8264f840988f4a38 upstream. HW generates a Data Size error for chacha20 requests that are not a multiple of 64B, since algorithm state (AS) does not have the FINAL bit set. Since updating req->iv (for chaining) is not required, modify skcipher descriptors to set the FINAL bit for chacha20. [Note that for skcipher decryption we know that ctx1_iv_off is 0, which allows for an optimization by not checking algorithm type, since append_dec_op1() sets FINAL bit for all algorithms except AES.] Also drop the descriptor operations that save the IV. However, in order to keep code logic simple, things like S/G tables generation etc. are not touched. Cc: # v5.3+ Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support") Signed-off-by: Horia Geantă Tested-by: Valentin Ciocoi Radulescu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam/qi2 - fix typo in algorithm's driver name

2020-02-14T21:34:18+00:00

commit 53146d152510584c2034c62778a7cbca25743ce9 upstream. Fixes: 8d818c105501 ("crypto: caam/qi2 - add DPAA2-CAAM driver") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - do not reset pointer size from MCFGR register

2020-02-01T09:34:52+00:00

commit 7278fa25aa0ebcc0e62c39b12071069df13f7e77 upstream. In commit 'a1cf573ee95 ("crypto: caam - select DMA address size at runtime")' CAAM pointer size (caam_ptr_size) is changed from sizeof(dma_addr_t) to runtime value computed from MCFGR register. Therefore, do not reset MCFGR[PS]. Fixes: a1cf573ee95 ("crypto: caam - select DMA address size at runtime") Signed-off-by: Iuliana Prodan Cc: Cc: Andrey Smirnov Cc: Alison Wang Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - Cast to long first before pointer conversion

2019-09-13T11:20:47+00:00

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: Herbert Xu Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - dispose of IRQ mapping only after IRQ is freed

2019-09-09T13:48:22+00:00

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 Cc: Chris Healy Cc: Lucas Stach Cc: Horia Geantă Cc: Herbert Xu Cc: Iuliana Prodan Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - check irq_of_parse_and_map for errors

2019-09-09T13:48:22+00:00

Irq_of_parse_and_map will return zero in case of error, so add a error check for that. Signed-off-by: Andrey Smirnov Cc: Chris Healy Cc: Lucas Stach Cc: Horia Geantă Cc: Herbert Xu Cc: Iuliana Prodan Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - use devres to unmap JR's registers

2019-09-09T13:48:22+00:00

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 Cc: Chris Healy Cc: Lucas Stach Cc: Horia Geantă Cc: Herbert Xu Cc: Iuliana Prodan Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - make sure clocks are enabled first

2019-09-09T07:49:51+00:00

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: 176435ad2ac7 ("crypto: caam - defer probing until QMan is available") Fixes: 41fc54afae70 ("crypto: caam - simplfy clock initialization") Signed-off-by: Andrey Smirnov Cc: Chris Healy Cc: Lucas Stach Cc: Horia Geantă Cc: Herbert Xu Cc: Iuliana Prodan Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Tested-by: Horia Geantă Signed-off-by: Herbert Xu