linux-stable.git/drivers/crypto/ccp, branch v6.2.3 Linux kernel stable tree crypto: ccp - Flush the SEV-ES TMR memory before giving it to firmware 2023-03-10T08:28:12+00:00 Tom Lendacky thomas.lendacky@amd.com 2023-01-23T22:53:08+00:00 e48ea40782634a82026d592651d4c2e0edb92bae [ 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> 
[ 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>
crypto: ccp - Failure on re-initialization due to duplicate sysfs filename 2023-03-10T08:28:09+00:00 Koba Ko koba.taiwan@gmail.com 2023-01-09T02:15:02+00:00 3fea4acff6583886cde1b87f8aaa14e2bccb8bbf [ 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> 
[ 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>
crypto: ccp - Avoid page allocation failure warning for SEV_GET_ID2 2023-03-10T08:28:05+00:00 David Rientjes rientjes@google.com 2022-12-30T22:18:46+00:00 0b2519474352ac93fa9911ff4ee7d32e54a1b331 [ Upstream commit 91dfd98216d817ec5f1c55890bacb7b4fe9b068a ] For SEV_GET_ID2, the user provided length does not have a specified limitation because the length of the ID may change in the future. The kernel memory allocation, however, is implicitly limited to 4MB on x86 by the page allocator, otherwise the kzalloc() will fail. When this happens, it is best not to spam the kernel log with the warning. Simply fail the allocation and return ENOMEM to the user. Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command") Reported-by: Andy Nguyen <theflow@google.com> Reported-by: Peter Gonda <pgonda@google.com> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David Rientjes <rientjes@google.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> 
[ Upstream commit 91dfd98216d817ec5f1c55890bacb7b4fe9b068a ]

For SEV_GET_ID2, the user provided length does not have a specified
limitation because the length of the ID may change in the future.  The
kernel memory allocation, however, is implicitly limited to 4MB on x86 by
the page allocator, otherwise the kzalloc() will fail.

When this happens, it is best not to spam the kernel log with the warning.
Simply fail the allocation and return ENOMEM to the user.

Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command")
Reported-by: Andy Nguyen <theflow@google.com>
Reported-by: Peter Gonda <pgonda@google.com>
Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David Rientjes <rientjes@google.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>
crypto: ccp - Set DMA alignment explicitly 2022-12-09T10:45:00+00:00 Herbert Xu herbert@gondor.apana.org.au 2022-12-02T09:20:49+00:00 99c6b20edfc031610240afca97ba9be5ec6f5750 This driver has been implicitly relying on kmalloc alignment to be sufficient for DMA. This may no longer be the case with upcoming arm64 changes. This patch changes it to explicitly request DMA alignment from the Crypto API. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
This driver has been implicitly relying on kmalloc alignment
to be sufficient for DMA.  This may no longer be the case with
upcoming arm64 changes.

This patch changes it to explicitly request DMA alignment from
the Crypto API.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp - Add support for TEE for PCI ID 0x14CA 2022-10-21T11:15:35+00:00 Mario Limonciello mario.limonciello@amd.com 2022-09-28T18:45:05+00:00 10da230a4df1dfe32a58eb09246f5ffe82346f27 SoCs containing 0x14CA are present both in datacenter parts that support SEV as well as client parts that support TEE. Cc: stable@vger.kernel.org # 5.15+ Tested-by: Rijo-john Thomas <Rijo-john.Thomas@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
SoCs containing 0x14CA are present both in datacenter parts that
support SEV as well as client parts that support TEE.

Cc: stable@vger.kernel.org # 5.15+
Tested-by: Rijo-john Thomas <Rijo-john.Thomas@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp - Remove unused struct ccp_crypto_cpu 2022-10-21T11:05:24+00:00 Yuan Can yuancan@huawei.com 2022-09-27T13:39:55+00:00 375de984a3cb691a0bbaf9756e8595e0b54e27e0 After commit bc3854476f36("crypto: ccp - Use a single queue for proper ordering of tfm requests"), no one use struct ccp_crypto_cpu, so remove it. Signed-off-by: Yuan Can <yuancan@huawei.com> Acked-by: John Allen <john.allen@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
After commit bc3854476f36("crypto: ccp - Use a single queue for proper ordering
of tfm requests"), no one use struct ccp_crypto_cpu, so remove it.

Signed-off-by: Yuan Can <yuancan@huawei.com>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp - Add __init/__exit annotations to module init/exit funcs 2022-10-21T11:05:24+00:00 ruanjinjie ruanjinjie@huawei.com 2022-09-26T09:27:11+00:00 237f9eceb2f3c888c1a26a4209243607d3cc0c7c Add missing __init/__exit annotations to module init/exit funcs Signed-off-by: ruanjinjie <ruanjinjie@huawei.com> Acked-by: John Allen <john.allen@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Add missing __init/__exit annotations to module init/exit funcs

Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp - Remove the unneeded result variable 2022-09-30T05:57:50+00:00 ye xingchen ye.xingchen@zte.com.cn 2022-09-20T06:32:52+00:00 6a40fb0d9db15f95b9ea884fbaedf8f82c51399f Return the value ccp_crypto_enqueue_request() directly instead of storing it in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn> Acked-by: John Allen <john.allen@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Return the value ccp_crypto_enqueue_request() directly instead of storing
it in another redundant variable.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp - Release dma channels before dmaengine unrgister 2022-09-09T08:18:33+00:00 Koba Ko koba.ko@canonical.com 2022-09-01T14:47:12+00:00 68dbe80f5b510c66c800b9e8055235c5b07e37d1 A warning is shown during shutdown, __dma_async_device_channel_unregister called while 2 clients hold a reference WARNING: CPU: 15 PID: 1 at drivers/dma/dmaengine.c:1110 __dma_async_device_channel_unregister+0xb7/0xc0 Call dma_release_channel for occupied channles before dma_async_device_unregister. Fixes: 54cce8ecb925 ("crypto: ccp - ccp_dmaengine_unregister release dma channels") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
A warning is shown during shutdown,

__dma_async_device_channel_unregister called while 2 clients hold a reference
WARNING: CPU: 15 PID: 1 at drivers/dma/dmaengine.c:1110 __dma_async_device_channel_unregister+0xb7/0xc0

Call dma_release_channel for occupied channles before dma_async_device_unregister.

Fixes: 54cce8ecb925 ("crypto: ccp - ccp_dmaengine_unregister release dma channels")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Koba Ko <koba.ko@canonical.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp - Fail the PSP initialization when writing psp data file failed 2022-08-26T10:50:07+00:00 Jacky Li jackyli@google.com 2022-08-16T19:32:09+00:00 efb4b01c1c993d245e6608076684ff2162cf9dc6 Currently the OS continues the PSP initialization when there is a write failure to the init_ex_file. Therefore, the userspace would be told that SEV is properly INIT'd even though the psp data file is not updated. This is problematic because later when asked for the SEV data, the OS won't be able to provide it. Fixes: 3d725965f836 ("crypto: ccp - Add SEV_INIT_EX support") Reported-by: Peter Gonda <pgonda@google.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jacky Li <jackyli@google.com> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Currently the OS continues the PSP initialization when there is a write
failure to the init_ex_file. Therefore, the userspace would be told that
SEV is properly INIT'd even though the psp data file is not updated.
This is problematic because later when asked for the SEV data, the OS
won't be able to provide it.

Fixes: 3d725965f836 ("crypto: ccp - Add SEV_INIT_EX support")
Reported-by: Peter Gonda <pgonda@google.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jacky Li <jackyli@google.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>