summaryrefslogtreecommitdiff
path: root/drivers/crypto
AgeCommit message (Collapse)AuthorFilesLines
2024-04-13crypto: qat - resolve race condition during AER recoveryDamian Muszynski1-6/+16
[ Upstream commit 7d42e097607c4d246d99225bf2b195b6167a210c ] During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function. Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Cc: <stable@vger.kernel.org> Signed-off-by: Damian Muszynski <damian.muszynski@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13crypto: qat - fix double free during resetSvyatoslav Pankratov1-1/+2
[ Upstream commit 01aed663e6c421aeafc9c330bda630976b50a764 ] There is no need to free the reset_data structure if the recovery is unsuccessful and the reset is synchronous. The function adf_dev_aer_schedule_reset() handles the cleanup properly. Only asynchronous resets require such structure to be freed inside the reset worker. Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Signed-off-by: Svyatoslav Pankratov <svyatoslav.pankratov@intel.com> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27crypto: xilinx - call finalize with bh disabledQuanyang Wang1-0/+3
[ Upstream commit a853450bf4c752e664abab0b2fad395b7ad7701c ] When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : crypto_finalize_request+0xa0/0x118 lr : crypto_finalize_request+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0 hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90 softirqs last enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0 softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0 ---[ end trace 0000000000000000 ]--- Fixes: 4d96f7d48131 ("crypto: xilinx - Add Xilinx AES driver") Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-06crypto: virtio/akcipher - Fix stack overflow on memcpyzhenwei pi1-2/+3
[ Upstream commit c0ec2a712daf133d9996a8a1b7ee2d4996080363 ] sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o Fixes: 59ca6c93387d ("virtio-crypto: implement RSA algorithm") Link: https://lore.kernel.org/all/0a194a79-e3a3-45e7-be98-83abd3e1cb7e@roeck-us.net/ Cc: <stable@vger.kernel.org> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_lockedKim Phillips1-2/+8
commit ccb88e9549e7cfd8bcd511c538f437e20026e983 upstream. The SEV platform device can be shutdown with a null psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [ 137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [ 137.182693] ? asm_exc_general_protection+0x2b/0x30 [ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693] really_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.182693] ? __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10 [ 137.182693] ? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_register_driver+0x1d6/0x2a0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [ 137.182693] ? parameq+0x80/0xf0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] kernel_init_freeable+0xa64/0x1050 [ 137.182693] ? __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x10/0x10 [ 137.182693] ret_from_fork_asm+0x1b/0x30 [ 137.182693] </TASK> [ 137.182693] Modules linked in: [ 137.538483] ---[ end trace 0000000000000000 ]--- Fixes: 1b05ece0c931 ("crypto: ccp - During shutdown, check SEV data pointer before using") Cc: stable@vger.kernel.org Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Kim Phillips <kim.phillips@amd.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Acked-by: John Allen <john.allen@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-23crypto: stm32/crc32 - fix parsing list of devicesThomas Bourgoin1-1/+1
[ Upstream commit 0eaef675b94c746900dcea7f6c41b9a103ed5d53 ] smatch warnings: drivers/crypto/stm32/stm32-crc32.c:108 stm32_crc_get_next_crc() warn: can 'crc' even be NULL? Use list_first_entry_or_null instead of list_first_entry to retrieve the first device registered. The function list_first_entry always return a non NULL pointer even if the list is empty. Hence checking if the pointer returned is NULL does not tell if the list is empty or not. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()Wei Yongjun1-1/+2
commit b1d65f717cd6305a396a8738e022c6f7c65cfbe8 upstream. 'vc_ctrl_req' is alloced in virtio_crypto_alg_skcipher_close_session(), and should be freed in the invalid ctrl_status->status error handling case. Otherwise there is a memory leak. Fixes: 0756ad15b1fe ("virtio-crypto: use private buffer for control request") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Message-Id: <20221114110740.537276-1-weiyongjun@huaweicloud.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Acked-by: zhenwei pi<pizhenwei@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-26virtio-crypto: fix memory-leaklei he1-0/+4
commit 1bedcf22c081a6e9943f09937b2da8d3ef52d20d upstream. Fix memory-leak for virtio-crypto akcipher request, this problem is introduced by 59ca6c93387d3(virtio-crypto: implement RSA algorithm). The leak can be reproduced and tested with the following script inside virtual machine: #!/bin/bash LOOP_TIMES=10000 # required module: pkcs8_key_parser, virtio_crypto modprobe pkcs8_key_parser # if CONFIG_PKCS8_PRIVATE_KEY_PARSER=m modprobe virtio_crypto # if CONFIG_CRYPTO_DEV_VIRTIO=m rm -rf /tmp/data dd if=/dev/random of=/tmp/data count=1 bs=230 # generate private key and self-signed cert openssl req -nodes -x509 -newkey rsa:2048 -keyout key.pem \ -outform der -out cert.der \ -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=always.com/emailAddress=yy@always.com" # convert private key from pem to der openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER -out key.der # add key PRIV_KEY_ID=`cat key.der | keyctl padd asymmetric test_priv_key @s` echo "priv key id = "$PRIV_KEY_ID PUB_KEY_ID=`cat cert.der | keyctl padd asymmetric test_pub_key @s` echo "pub key id = "$PUB_KEY_ID # query key keyctl pkey_query $PRIV_KEY_ID 0 keyctl pkey_query $PUB_KEY_ID 0 # here we only run pkey_encrypt becasuse it is the fastest interface function bench_pub() { keyctl pkey_encrypt $PUB_KEY_ID 0 /tmp/data enc=pkcs1 >/tmp/enc.pub } # do bench_pub in loop to obtain the memory leak for (( i = 0; i < ${LOOP_TIMES}; ++i )); do bench_pub done Signed-off-by: lei he <helei.sig11@bytedance.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Message-Id: <20220919075158.3625-1-helei.sig11@bytedance.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-26crypto: sahara - do not resize req->src when doing hash operationsOvidiu Panait1-36/+2
[ Upstream commit a3c6f4f4d249cecaf2f34471aadbfb4f4ef57298 ] When testing sahara sha256 speed performance with tcrypt (mode=404) on imx53-qsrb board, multiple "Invalid numbers of src SG." errors are reported. This was traced to sahara_walk_and_recalc() resizing req->src and causing the subsequent dma_map_sg() call to fail. Now that the previous commit fixed sahara_sha_hw_links_create() to take into account the actual request size, rather than relying on sg->length values, the resize operation is no longer necessary. Therefore, remove sahara_walk_and_recalc() and simplify associated logic. Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - fix processing hash requests with req->nbytes < sg->lengthOvidiu Panait1-1/+4
[ Upstream commit 7bafa74d1ba35dcc173e1ce915e983d65905f77e ] It's not always the case that the entire sg entry needs to be processed. Currently, when nbytes is less than sg->length, "Descriptor length" errors are encountered. To fix this, take the actual request size into account when populating the hw links. Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - improve error handling in sahara_sha_process()Ovidiu Panait1-2/+8
[ Upstream commit 5deff027fca49a1eb3b20359333cf2ae562a2343 ] sahara_sha_hw_data_descriptor_create() returns negative error codes on failure, so make sure the errors are correctly handled / propagated. Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - fix wait_for_completion_timeout() error handlingOvidiu Panait1-8/+10
[ Upstream commit 2dba8e1d1a7957dcbe7888846268538847b471d1 ] The sg lists are not unmapped in case of timeout errors. Fix this. Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256") Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - fix ahash reqsizeOvidiu Panait1-2/+1
[ Upstream commit efcb50f41740ac55e6ccc4986c1a7740e21c62b4 ] Set the reqsize for sha algorithms to sizeof(struct sahara_sha_reqctx), the extra space is not needed. Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - handle zero-length aes requestsOvidiu Panait1-0/+3
[ Upstream commit d1d6351e37aac14b32a291731d0855996c459d11 ] In case of a zero-length input, exit gracefully from sahara_aes_crypt(). Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - avoid skcipher fallback code duplicationOvidiu Panait1-60/+25
[ Upstream commit 01d70a4bbff20ea05cadb4c208841985a7cc6596 ] Factor out duplicated skcipher fallback handling code to a helper function sahara_aes_fallback(). Also, keep a single check if fallback is required in sahara_aes_crypt(). Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: d1d6351e37aa ("crypto: sahara - handle zero-length aes requests") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: virtio - Wait for tasklet to complete on device removewangyangxin1-0/+3
[ Upstream commit 67cc511e8d436456cc98033e6d4ba83ebfc8e672 ] The scheduled tasklet needs to be executed on device remove. Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Signed-off-by: wangyangxin <wangyangxin1@huawei.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - fix error handling in sahara_hw_descriptor_create()Ovidiu Panait1-5/+3
[ Upstream commit ee6e6f0a7f5b39d50a5ef5fcc006f4f693db18a7 ] Do not call dma_unmap_sg() for scatterlists that were not mapped successfully. Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - fix processing requests with cryptlen < sg->lengthOvidiu Panait1-2/+7
[ Upstream commit 5b8668ce3452827d27f8c34ff6ba080a8f983ed0 ] It's not always the case that the entire sg entry needs to be processed. Currently, when cryptlen is less than sg->legth, "Descriptor length" errors are encountered. The error was noticed when testing xts(sahara-ecb-aes) with arbitrary sized input data. To fix this, take the actual request size into account when populating the hw links. Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - fix ahash selftest failureOvidiu Panait1-1/+1
[ Upstream commit afffcf3db98b9495114b79d5381f8cc3f69476fb ] update() calls should not modify the result buffer, so add an additional check for "rctx->last" to make sure that only the final hash value is copied into the buffer. Fixes the following selftest failure: alg: ahash: sahara-sha256 update() used result buffer on test vector 3, cfg="init+update+final aligned buffer" Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - fix cbc selftest failureOvidiu Panait1-2/+31
[ Upstream commit 9f10bc28c0fb676ae58aa3bfa358db8f5de124bb ] The kernel crypto API requires that all CBC implementations update the IV buffer to contain the last ciphertext block. This fixes the following cbc selftest error: alg: skcipher: sahara-cbc-aes encryption test failed (wrong output IV) on test vector 0, cfg="in-place (one sglist)" Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sahara - remove FLAGS_NEW_KEY logicOvidiu Panait1-21/+13
[ Upstream commit 8fd183435728b139248a77978ea3732039341779 ] Remove the FLAGS_NEW_KEY logic as it has the following issues: - the wrong key may end up being used when there are multiple data streams: t1 t2 setkey() encrypt() setkey() encrypt() encrypt() <--- key from t2 is used - switching between encryption and decryption with the same key is not possible, as the hdr flags are only updated when a new setkey() is performed With this change, the key is always sent along with the cryptdata when performing encryption/decryption operations. Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.") Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: ccp - fix memleak in ccp_init_dm_workareaDinghao Liu1-1/+4
[ Upstream commit a1c95dd5bc1d6a5d7a75a376c2107421b7d6240d ] When dma_map_single() fails, wa->address is supposed to be freed by the callers of ccp_init_dm_workarea() through ccp_dm_free(). However, many of the call spots don't expect to have to call ccp_dm_free() on failure of ccp_init_dm_workarea(), which may lead to a memleak. Let's free wa->address in ccp_init_dm_workarea() when dma_map_single() fails. Fixes: 63b945091a07 ("crypto: ccp - CCP device driver and interface support") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: sa2ul - Return crypto_aead_setkey to transfer the errorChen Ni1-2/+1
[ Upstream commit ce852f1308ac738e61c5b2502517deea593a1554 ] Return crypto_aead_setkey() in order to transfer the error if it fails. Fixes: d2c8ac187fc9 ("crypto: sa2ul - Add AEAD algorithm support") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26crypto: virtio - Handle dataq logic with taskletGonglei (Arei)2-10/+15
[ Upstream commit fed93fb62e05c38152b0fc1dc9609639e63eed76 ] Doing ipsec produces a spinlock recursion warning. This is due to crypto_finalize_request() being called in the upper half. Move virtual data queue processing of virtio-crypto driver to tasklet. Fixes: dbaf0624ffa57 ("crypto: add virtio-crypto driver") Reported-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: wangyangxin <wangyangxin1@huawei.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26virtio-crypto: wait ctrl queue instead of busy pollingzhenwei pi4-55/+64
[ Upstream commit 977231e8d45657871a86fe3c7bed94921d04e447 ] Originally, after submitting request into virtio crypto control queue, the guest side polls the result from the virt queue. This works like following: CPU0 CPU1 ... CPUx CPUy | | | | \ \ / / \--------spin_lock(&vcrypto->ctrl_lock)-------/ | virtqueue add & kick | busy poll virtqueue | spin_unlock(&vcrypto->ctrl_lock) ... There are two problems: 1, The queue depth is always 1, the performance of a virtio crypto device gets limited. Multi user processes share a single control queue, and hit spin lock race from control queue. Test on Intel Platinum 8260, a single worker gets ~35K/s create/close session operations, and 8 workers get ~40K/s operations with 800% CPU utilization. 2, The control request is supposed to get handled immediately, but in the current implementation of QEMU(v6.2), the vCPU thread kicks another thread to do this work, the latency also gets unstable. Tracking latency of virtio_crypto_alg_akcipher_close_session in 5s: usecs : count distribution 0 -> 1 : 0 | | 2 -> 3 : 7 | | 4 -> 7 : 72 | | 8 -> 15 : 186485 |************************| 16 -> 31 : 687 | | 32 -> 63 : 5 | | 64 -> 127 : 3 | | 128 -> 255 : 1 | | 256 -> 511 : 0 | | 512 -> 1023 : 0 | | 1024 -> 2047 : 0 | | 2048 -> 4095 : 0 | | 4096 -> 8191 : 0 | | 8192 -> 16383 : 2 | | This means that a CPU may hold vcrypto->ctrl_lock as long as 8192~16383us. To improve the performance of control queue, a request on control queue waits completion instead of busy polling to reduce lock racing, and gets completed by control queue callback. CPU0 CPU1 ... CPUx CPUy | | | | \ \ / / \--------spin_lock(&vcrypto->ctrl_lock)-------/ | virtqueue add & kick | ---------spin_unlock(&vcrypto->ctrl_lock)------ / / \ \ | | | | wait wait wait wait Test this patch, the guest side get ~200K/s operations with 300% CPU utilization. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20220506131627.180784-4-pizhenwei@bytedance.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26virtio-crypto: use private buffer for control requestzhenwei pi3-45/+79
[ Upstream commit 0756ad15b1fef287d4d8fa11bc36ea77a5c42e4a ] Originally, all of the control requests share a single buffer( ctrl & input & ctrl_status fields in struct virtio_crypto), this allows queue depth 1 only, the performance of control queue gets limited by this design. In this patch, each request allocates request buffer dynamically, and free buffer after request, so the scope protected by ctrl_lock also get optimized here. It's possible to optimize control queue depth in the next step. A necessary comment is already in code, still describe it again: /* * Note: there are padding fields in request, clear them to zero before * sending to host to avoid to divulge any information. * Ex, virtio_crypto_ctrl_request::ctrl::u::destroy_session::padding[48] */ So use kzalloc to allocate buffer of struct virtio_crypto_ctrl_request. Potentially dereferencing uninitialized variables: Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20220506131627.180784-3-pizhenwei@bytedance.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26virtio-crypto: change code stylezhenwei pi2-53/+59
[ Upstream commit 6fd763d155860eb7ea3a93c8b3bf926940ffa3fb ] Use temporary variable to make code easy to read and maintain. /* Pad cipher's parameters */ vcrypto->ctrl.u.sym_create_session.op_type = cpu_to_le32(VIRTIO_CRYPTO_SYM_OP_CIPHER); vcrypto->ctrl.u.sym_create_session.u.cipher.para.algo = vcrypto->ctrl.header.algo; vcrypto->ctrl.u.sym_create_session.u.cipher.para.keylen = cpu_to_le32(keylen); vcrypto->ctrl.u.sym_create_session.u.cipher.para.op = cpu_to_le32(op); --> sym_create_session = &ctrl->u.sym_create_session; sym_create_session->op_type = cpu_to_le32(VIRTIO_CRYPTO_SYM_OP_CIPHER); sym_create_session->u.cipher.para.algo = ctrl->header.algo; sym_create_session->u.cipher.para.keylen = cpu_to_le32(keylen); sym_create_session->u.cipher.para.op = cpu_to_le32(op); The new style shows more obviously: - the variable we want to operate. - an assignment statement in a single line. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20220506131627.180784-2-pizhenwei@bytedance.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26virtio-crypto: implement RSA algorithmzhenwei pi6-1/+608
[ Upstream commit 59ca6c93387d325e96577d8bd4c23c78c1491c11 ] Support rsa & pkcs1pad(rsa,sha1) with priority 150. Test with QEMU built-in backend, it works fine. 1, The self-test framework of crypto layer works fine in guest kernel 2, Test with Linux guest(with asym support), the following script test(note that pkey_XXX is supported only in a newer version of keyutils): - both public key & private key - create/close session - encrypt/decrypt/sign/verify basic driver operation - also test with kernel crypto layer(pkey add/query) All the cases work fine. rm -rf *.der *.pem *.pfx modprobe pkcs8_key_parser # if CONFIG_PKCS8_PRIVATE_KEY_PARSER=m rm -rf /tmp/data dd if=/dev/random of=/tmp/data count=1 bs=226 openssl req -nodes -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -subj "/C=CN/ST=BJ/L=HD/O=qemu/OU=dev/CN=qemu/emailAddress=qemu@qemu.org" openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER -out key.der openssl x509 -in cert.pem -inform PEM -outform DER -out cert.der PRIV_KEY_ID=`cat key.der | keyctl padd asymmetric test_priv_key @s` echo "priv key id = "$PRIV_KEY_ID PUB_KEY_ID=`cat cert.der | keyctl padd asymmetric test_pub_key @s` echo "pub key id = "$PUB_KEY_ID keyctl pkey_query $PRIV_KEY_ID 0 keyctl pkey_query $PUB_KEY_ID 0 echo "Enc with priv key..." keyctl pkey_encrypt $PRIV_KEY_ID 0 /tmp/data enc=pkcs1 >/tmp/enc.priv echo "Dec with pub key..." keyctl pkey_decrypt $PRIV_KEY_ID 0 /tmp/enc.priv enc=pkcs1 >/tmp/dec cmp /tmp/data /tmp/dec echo "Sign with priv key..." keyctl pkey_sign $PRIV_KEY_ID 0 /tmp/data enc=pkcs1 hash=sha1 > /tmp/sig echo "Verify with pub key..." keyctl pkey_verify $PRIV_KEY_ID 0 /tmp/data /tmp/sig enc=pkcs1 hash=sha1 echo "Enc with pub key..." keyctl pkey_encrypt $PUB_KEY_ID 0 /tmp/data enc=pkcs1 >/tmp/enc.pub echo "Dec with priv key..." keyctl pkey_decrypt $PRIV_KEY_ID 0 /tmp/enc.pub enc=pkcs1 >/tmp/dec cmp /tmp/data /tmp/dec echo "Verify with pub key..." keyctl pkey_verify $PUB_KEY_ID 0 /tmp/data /tmp/sig enc=pkcs1 hash=sha1 [1 compiling warning during development] Reported-by: kernel test robot <lkp@intel.com> Co-developed-by: lei he <helei.sig11@bytedance.com> Signed-off-by: lei he <helei.sig11@bytedance.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Link: https://lore.kernel.org/r/20220302033917.1295334-4-pizhenwei@bytedance.com Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> #Kconfig tweaks Link: https://lore.kernel.org/r/20220308205309.2192502-1-nathan@kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20crypto: qat - increase size of buffersGiovanni Cabiddu2-3/+3
[ Upstream commit 4e4e2ed22d505c5bacf65c6a39bfb6d120d24785 ] Increase the size of the buffers used for composing the names used for the transport debugfs entries and the vector name to avoid a potential truncation. This resolves the following errors when compiling the driver with W=1 and KCFLAGS=-Werror on GCC 12.3.1: drivers/crypto/intel/qat/qat_common/adf_transport_debug.c: In function ‘adf_ring_debugfs_add’: drivers/crypto/intel/qat/qat_common/adf_transport_debug.c:100:60: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] drivers/crypto/intel/qat/qat_common/adf_isr.c: In function ‘adf_isr_resource_alloc’: drivers/crypto/intel/qat/qat_common/adf_isr.c:197:47: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 5 [-Werror=format-truncation=] Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Damian Muszynski <damian.muszynski@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20crypto: qat - mask device capabilities with soft strapsGiovanni Cabiddu16-53/+109
[ Upstream commit 7b07ed5042c5d21467af5aa055f2b49b2e661a83 ] Enable acceleration engines (AEs) and accelerators based on soft straps and fuses. When looping with a number of AEs or accelerators, ignore the ones that are disabled. This patch is based on earlier work done by Conor McLoughlin. Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Fiona Trahe <fiona.trahe@intel.com> Reviewed-by: Wojciech Ziemba <wojciech.ziemba@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: 4e4e2ed22d50 ("crypto: qat - increase size of buffers") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20crypto: caam/jr - fix Chacha20 + Poly1305 self test failureGaurav Jain1-1/+2
[ Upstream commit a8d3cdcc092fb2f2882acb6c20473a1be0ef4484 ] key buffer is not copied in chachapoly_setkey function, results in wrong output for encryption/decryption operation. fix this by memcpy the key in caam_ctx key arrary Fixes: d6bbd4eea243 ("crypto: caam/jr - add support for Chacha20 + Poly1305") Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20crypto: caam/qi2 - fix Chacha20 + Poly1305 self test failureGaurav Jain1-1/+2
[ Upstream commit 7b8c6aee0d5b864e70c0da82583f9862e374eaf3 ] key buffer is not copied in chachapoly_setkey function, results in wrong output for encryption/decryption operation. fix this by memcpy the key in caam_ctx key arrary Fixes: c10a53367901 ("crypto: caam/qi2 - add support for Chacha20 + Poly1305") Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20crypto: hisilicon/hpre - Fix a erroneous check after snprintf()Christophe JAILLET1-1/+1
[ Upstream commit c977950146720abff14e46d8c53f5638b06a9182 ] This error handling looks really strange. Check if the string has been truncated instead. Fixes: 02ab994635eb ("crypto: hisilicon - Fixed some tiny bugs of HPRE") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19crypto: stm32 - fix loop iterating through scatterlist for DMAThomas Bourgoin1-1/+1
commit d9c83f71eeceed2cb54bb78be84f2d4055fd9a1f upstream. We were reading the length of the scatterlist sg after copying value of tsg inside. So we are using the size of the previous scatterlist and for the first one we are using an unitialised value. Fix this by copying tsg in sg[0] before reading the size. Fixes : 8a1012d3f2ab ("crypto: stm32 - Support for STM32 HASH module") Cc: stable@vger.kernel.org Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19crypto: caam - fix unchecked return value errorGaurav Jain1-1/+3
[ Upstream commit e30685204711a6be40dec2622606950ccd37dafe ] error: Unchecked return value (CHECKED_RETURN) check_return: Calling sg_miter_next without checking return value fix: added check if(!sg_miter_next) Fixes: 8a2a0dd35f2e ("crypto: caam - strip input zeros from RSA input buffer") Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19crypto: stm32 - Properly handle pm_runtime_get failingUwe Kleine-König1-4/+3
[ Upstream commit aec48805163338f8413118796c1dd035661b9140 ] If pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, this means the clk wasn't prepared and enabled. Returning early in this case however is wrong as then the following resource frees are skipped and this is never catched up. So do all the cleanups but clk_disable_unprepare(). Also don't emit a warning, as stm32_hash_runtime_resume() already emitted one. Note that the return value of stm32_hash_remove() is mostly ignored by the device core. The only effect of returning zero instead of an error value is to suppress another warning in platform_remove(). So return 0 even if pm_runtime_resume_and_get() failed. Fixes: 8b4d566de6a5 ("crypto: stm32/hash - Add power management support") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-27crypto: marvell/cesa - Fix type mismatch warningArnd Bergmann1-1/+1
[ Upstream commit efbc7764c4446566edb76ca05e903b5905673d2e ] Commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3") uncovered a type mismatch in cesa 3des support that leads to a memcpy beyond the end of a structure: In function 'fortify_memcpy_chk', inlined from 'mv_cesa_des3_ede_setkey' at drivers/crypto/marvell/cesa/cipher.c:307:2: include/linux/fortify-string.h:583:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is probably harmless as the actual data that is copied has the correct type, but clearly worth fixing nonetheless. Fixes: 4ada48397823 ("crypto: marvell/cesa - add Triple-DES support") Cc: Kees Cook <keescook@chromium.org> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-27crypto: nx - fix build warnings when DEBUG_FS is not enabledRandy Dunlap2-3/+3
[ Upstream commit b04b076fb56560b39d695ac3744db457e12278fd ] Fix build warnings when DEBUG_FS is not enabled by using an empty do-while loop instead of a value: In file included from ../drivers/crypto/nx/nx.c:27: ../drivers/crypto/nx/nx.c: In function 'nx_register_algs': ../drivers/crypto/nx/nx.h:173:33: warning: statement with no effect [-Wunused-value] 173 | #define NX_DEBUGFS_INIT(drv) (0) ../drivers/crypto/nx/nx.c:573:9: note: in expansion of macro 'NX_DEBUGFS_INIT' 573 | NX_DEBUGFS_INIT(&nx_driver); ../drivers/crypto/nx/nx.c: In function 'nx_remove': ../drivers/crypto/nx/nx.h:174:33: warning: statement with no effect [-Wunused-value] 174 | #define NX_DEBUGFS_FINI(drv) (0) ../drivers/crypto/nx/nx.c:793:17: note: in expansion of macro 'NX_DEBUGFS_FINI' 793 | NX_DEBUGFS_FINI(&nx_driver); Also, there is no need to build nx_debugfs.o when DEBUG_FS is not enabled, so change the Makefile to accommodate that. Fixes: ae0222b7289d ("powerpc/crypto: nx driver code supporting nx encryption") Fixes: aef7b31c8833 ("powerpc/crypto: Build files for the nx device driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Breno Leitão <leitao@debian.org> Cc: Nayna Jain <nayna@linux.ibm.com> Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-09crypto: ccp: Play nice with vmalloc'd memory for SEV command structsSean Christopherson2-5/+25
commit 8347b99473a313be6549a5b940bc3c56a71be81c upstream. Copy the incoming @data comman to an internal buffer so that callers can put SEV command buffers on the stack without running afoul of CONFIG_VMAP_STACK=y, i.e. without bombing on vmalloc'd pointers. As of today, the largest supported command takes a 68 byte buffer, i.e. pretty much every command can be put on the stack. Because sev_cmd_mutex is held for the entirety of a transaction, only a single bounce buffer is required. Use the internal buffer unconditionally, as the majority of in-kernel users will soon switch to using the stack. At that point, checking virt_addr_valid() becomes (negligible) overhead in most cases, and supporting both paths slightly increases complexity. Since the commands are all quite small, the cost of the copies is insignificant compared to the latency of communicating with the PSP. Allocate a full page for the buffer as opportunistic preparation for SEV-SNP, which requires the command buffer to be in firmware state for commands that trigger memory writes from the PSP firmware. Using a full page now will allow SEV-SNP support to simply transition the page as needed. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20210406224952.4177376-5-seanjc@google.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Ben Hutchings <benh@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-09crypto: ccp: Reject SEV commands with mismatching command bufferSean Christopherson1-2/+7
commit d5760dee127bf6f390b05e747369d7c37ae1a7b8 upstream. WARN on and reject SEV commands that provide a valid data pointer, but do not have a known, non-zero length. And conversely, reject commands that take a command buffer but none is provided (data is null). Aside from sanity checking input, disallowing a non-null pointer without a non-zero size will allow a future patch to cleanly handle vmalloc'd data by copying the data to an internal __pa() friendly buffer. Note, this also effectively prevents callers from using commands that have a non-zero length and are not known to the kernel. This is not an explicit goal, but arguably the side effect is a good thing from the kernel's perspective. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20210406224952.4177376-4-seanjc@google.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Ben Hutchings <benh@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-17crypto: sun8i-ss - Fix a test in sun8i_ss_setup_ivs()Christophe JAILLET1-1/+1
[ Upstream commit 8fd91151ebcb21b3f2f2bf158ac6092192550b2b ] SS_ENCRYPTION is (0 << 7 = 0), so the test can never be true. Use a direct comparison to SS_ENCRYPTION instead. The same king of test is already done the same way in sun8i_ss_run_task(). Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17crypto: ccp - Clear PSP interrupt status register before calling handlerJeremi Piotrowski1-3/+3
[ Upstream commit 45121ad4a1750ca47ce3f32bd434bdb0cdbf0043 ] The PSP IRQ is edge-triggered (MSI or MSI-X) in all cases supported by the psp module so clear the interrupt status register early in the handler to prevent missed interrupts. sev_irq_handler() calls wake_up() on a wait queue, which can result in a new command being submitted from a different CPU. This then races with the clearing of isr and can result in missed interrupts. A missed interrupt results in a command waiting until it times out, which results in the psp being declared dead. This is unlikely on bare metal, but has been observed when running virtualized. In the cases where this is observed, sev->cmdresp_reg has PSP_CMDRESP_RESP set which indicates that the command was processed correctly but no interrupt was asserted. The full sequence of events looks like this: CPU 1: submits SEV cmd #1 CPU 1: calls wait_event_timeout() CPU 0: enters psp_irq_handler() CPU 0: calls sev_handler()->wake_up() CPU 1: wakes up; finishes processing cmd #1 CPU 1: submits SEV cmd #2 CPU 1: calls wait_event_timeout() PSP: finishes processing cmd #2; interrupt status is still set; no interrupt CPU 0: clears intsts CPU 0: exits psp_irq_handler() CPU 1: wait_event_timeout() times out; psp_dead=true Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Cc: stable@vger.kernel.org Signed-off-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17crypto: sa2ul - Select CRYPTO_DESSuman Anna1-0/+1
[ Upstream commit 8832023efd20966e29944dac92118dfbf1fa1bc0 ] The SA2UL Crypto driver provides support for couple of DES3 algos "cbc(des3_ede)" and "ecb(des3_ede)", and enabling the crypto selftest throws the following errors (as seen on K3 J721E SoCs): saul-crypto 4e00000.crypto: Error allocating fallback algo cbc(des3_ede) alg: skcipher: failed to allocate transform for cbc-des3-sa2ul: -2 saul-crypto 4e00000.crypto: Error allocating fallback algo ecb(des3_ede) alg: skcipher: failed to allocate transform for ecb-des3-sa2ul: -2 Fix this by selecting CRYPTO_DES which was missed while adding base driver support. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17crypto: caam - Clear some memory in instantiate_rngChristophe JAILLET1-2/+4
[ Upstream commit 9c19fb86a8cb2ee82a832c95e139f29ea05c4d08 ] According to the comment at the end of the 'for' loop just a few lines below, it looks needed to clear 'desc'. So it should also be cleared for the first iteration. Move the memset() to the beginning of the loop to be safe. Fixes: 281922a1d4f5 ("crypto: caam - add support for SEC v5.x RNG4") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17crypto: safexcel - Cleanup ring IRQ workqueues on load failureJonathan McDowell1-10/+27
commit ca25c00ccbc5f942c63897ed23584cfc66e8ec81 upstream. A failure loading the safexcel driver results in the following warning on boot, because the IRQ affinity has not been correctly cleaned up. Ensure we clean up the affinity and workqueues on a failure to load the driver. crypto-safexcel: probe of f2800000.crypto failed with error -2 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340 Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4 CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3 Hardware name: MikroTik RB5009 (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : free_irq+0x300/0x340 lr : free_irq+0x2e0/0x340 sp : ffff800008fa3890 x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000 x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50 x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80 x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040 x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370 x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18 x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188 x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0 Call trace: free_irq+0x300/0x340 devm_irq_release+0x14/0x20 devres_release_all+0xa0/0x100 device_unbind_cleanup+0x14/0x60 really_probe+0x198/0x2d4 __driver_probe_device+0x74/0xdc driver_probe_device+0x3c/0x110 __driver_attach+0x8c/0x190 bus_for_each_dev+0x6c/0xc0 driver_attach+0x20/0x30 bus_add_driver+0x148/0x1fc driver_register+0x74/0x120 __platform_driver_register+0x24/0x30 safexcel_init+0x48/0x1000 [crypto_safexcel] do_one_initcall+0x4c/0x1b0 do_init_module+0x44/0x1cc load_module+0x1724/0x1be4 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x1c/0x24 invoke_syscall+0x44/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x20/0x80 el0_svc+0x14/0x4c el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x148/0x14c ---[ end trace 0000000000000000 ]--- Fixes: 1b44c5a60c13 ("inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: Jonathan McDowell <noodles@earth.li> Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-11crypto: hisilicon: Wipe entire pool on errorKees Cook1-2/+1
[ Upstream commit aa85923a954e7704bc9d3847dabeb8540aa98d13 ] To work around a Clang __builtin_object_size bug that shows up under CONFIG_FORTIFY_SOURCE and UBSAN_BOUNDS, move the per-loop-iteration mem_block wipe into a single wipe of the entire pool structure after the loop. Reported-by: Nathan Chancellor <nathan@kernel.org> Link: https://github.com/ClangBuiltLinux/linux/issues/1780 Cc: Weili Qian <qianweili@huawei.com> Cc: Zhou Wang <wangzhou1@hisilicon.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Link: https://lore.kernel.org/r/20230106041945.never.831-kees@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11crypto: crypto4xx - Call dma_unmap_page when doneHerbert Xu1-6/+4
[ Upstream commit bcdda4301bdc4955d45f7e1ffefb6207967b067e ] In crypto4xx_cipher_done, we should be unmapping the dst page, not mapping it. This was flagged by a sparse warning about the unused addr variable. While we're at it, also fix a sparse warning regarding the unused ctx variable in crypto4xx_ahash_done (by actually using it). Fixes: 049359d65527 ("crypto: amcc - Add crypt4xx driver") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11crypto: ccp - Flush the SEV-ES TMR memory before giving it to firmwareTom Lendacky1-1/+5
[ Upstream commit 46a334a98f585ef78d51d8f5736596887bdd7f54 ] Perform a cache flush on the SEV-ES TMR memory after allocation to prevent any possibility of the firmware encountering an error should dirty cache lines be present. Use clflush_cache_range() to flush the SEV-ES TMR memory. Fixes: 97f9ac3db661 ("crypto: ccp - Add support for SEV-ES to the PSP driver") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11crypto: ccp - Refactor out sev_fw_alloc()Peter Gonda1-7/+13
[ Upstream commit cc17982d58d1e67eab831e7023ede999dda56173 ] Create a helper function sev_fw_alloc() which can be used to allocate aligned memory regions for use by the PSP firmware. Currently only used for the SEV-ES TMR region but will be used for the SEV_INIT_EX NV memory region. Signed-off-by: Peter Gonda <pgonda@google.com> Reviewed-by: Marc Orr <marcorr@google.com> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Brijesh Singh <brijesh.singh@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Marc Orr <marcorr@google.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: David Rientjes <rientjes@google.com> Cc: John Allen <john.allen@amd.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: 46a334a98f58 ("crypto: ccp - Flush the SEV-ES TMR memory before giving it to firmware") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11crypto: ccp - Failure on re-initialization due to duplicate sysfs filenameKoba Ko1-4/+17
[ Upstream commit 299bf602b3f92f1456aef59c6413591fb02e762a ] The following warning appears during the CCP module re-initialization: [ 140.965403] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:07.1/0000:03:00.2/dma/dma0chan0' [ 140.975736] CPU: 0 PID: 388 Comm: kworker/0:2 Kdump: loaded Not tainted 6.2.0-0.rc2.18.eln124.x86_64 #1 [ 140.985185] Hardware name: HPE ProLiant DL325 Gen10/ProLiant DL325 Gen10, BIOS A41 07/17/2020 [ 140.993761] Workqueue: events work_for_cpu_fn [ 140.998151] Call Trace: [ 141.000613] <TASK> [ 141.002726] dump_stack_lvl+0x33/0x46 [ 141.006415] sysfs_warn_dup.cold+0x17/0x23 [ 141.010542] sysfs_create_dir_ns+0xba/0xd0 [ 141.014670] kobject_add_internal+0xba/0x260 [ 141.018970] kobject_add+0x81/0xb0 [ 141.022395] device_add+0xdc/0x7e0 [ 141.025822] ? complete_all+0x20/0x90 [ 141.029510] __dma_async_device_channel_register+0xc9/0x130 [ 141.035119] dma_async_device_register+0x19e/0x3b0 [ 141.039943] ccp_dmaengine_register+0x334/0x3f0 [ccp] [ 141.045042] ccp5_init+0x662/0x6a0 [ccp] [ 141.049000] ? devm_kmalloc+0x40/0xd0 [ 141.052688] ccp_dev_init+0xbb/0xf0 [ccp] [ 141.056732] ? __pci_set_master+0x56/0xd0 [ 141.060768] sp_init+0x70/0x90 [ccp] [ 141.064377] sp_pci_probe+0x186/0x1b0 [ccp] [ 141.068596] local_pci_probe+0x41/0x80 [ 141.072374] work_for_cpu_fn+0x16/0x20 [ 141.076145] process_one_work+0x1c8/0x380 [ 141.080181] worker_thread+0x1ab/0x380 [ 141.083953] ? __pfx_worker_thread+0x10/0x10 [ 141.088250] kthread+0xda/0x100 [ 141.091413] ? __pfx_kthread+0x10/0x10 [ 141.095185] ret_from_fork+0x2c/0x50 [ 141.098788] </TASK> [ 141.100996] kobject_add_internal failed for dma0chan0 with -EEXIST, don't try to register things with the same name in the same directory. [ 141.113703] ccp 0000:03:00.2: ccp initialization failed The /dma/dma0chan0 sysfs file is not removed since dma_chan object has been released in ccp_dma_release() before releasing dma device. A correct procedure would be: release dma channels first => unregister dma device => release ccp dma object. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216888 Fixes: 68dbe80f5b51 ("crypto: ccp - Release dma channels before dmaengine unrgister") Tested-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Koba Ko <koba.ko@canonical.com> Reviewed-by: Vladis Dronov <vdronov@redhat.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-18 18:59:47 +0300