Re: [PATCH v24 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
Eric Biggers <[email protected]> Thu, 23 Jul 2026 10:27:28 -0700
| Newsgroups | org.kernel.vger.linux-crypto,org.infradead.lists.linux-arm-kernel,org.kernel.vger.dmaengine,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260723172728.GA93534@quark> |
On Thu, Jul 23, 2026 at 07:09:06PM +0200, Bartosz Golaszewski wrote: > Currently the QCE crypto driver accesses the crypto engine registers > directly via CPU. Trust Zone may perform crypto operations simultaneously > resulting in a race condition. You've claimed elsewhere that this isn't actually a problem currently (since the problem will be introduced by a future TrustZone software update). If true, shouldn't the cover letter and commit messages be corrected accordingly? However, what if someone runs a LTS kernel on a system that has this TrustZone update? None of these patches have Cc stable, so LTS kernels won't get them. Also, won't these changes further exacerbate the performance issues with this driver? This series adds a lot of additional overhead, for example by replacing fast MMIO writes with DMA transactions using highly fragmented scatterlists (see qce_write()). There are also new dynamic memory allocations, which can fail. In addition, there can now be an additional delay to wait for TrustZone to stop using the hardware. > Tested with tcrypt.ko, kcapi and cryptsetup. Did this include testing that this patch series solves the problem it claims to -- synchronizing between Linux and TrustZone? - Eric