[PATCH 0/2] crypto: fix RSA results corrupted by non-coherent DMA

[Stephane Debusne]

On i.MX8M Mini with the CAAM (rsa-caam, caam_jr loaded), PKCS#1 v1.5
signature verification fails almost every time: cfg80211 rejects
regulatory.db ("loaded regulatory.db is malformed or signature is
missing/invalid"), and a valid self-signed X.509 certificate cannot be
added to a keyring (EINVAL). Seen with the NXP BSP lf-6.18.37 and stable
updates up to 6.18.57; the code involved is identical in mainline.

crypto_akcipher_sync_prep() and rsassa_pkcs1_verify() place the data
buffer right after the request context, in the same allocation. caampkc
writes req_ctx->edesc and req_ctx->akcipher_op_done after mapping the
destination, so the cache line shared by the end of the context and the
start of the buffer is dirty while the device writes the result. On
arm64, dma_unmap_sg(DMA_FROM_DEVICE) cleans and invalidates that partial
line, and the stale CPU copy overwrites the first bytes of the result.
The self-tests pass because testmgr uses separate buffers.

A test module comparing rsa-caam with rsa-generic (2048-bit key, 200
public-key operations per case, CAAM era 9, non-coherent DMA) gives:

  destination buffer                        wrong results
  separate kmalloc() buffers                0/200
  in place, own kmalloc() buffer            0/200
  separate source, dst after req. context   200/200
  in place, after req. context (rsassa)     200/200
  crypto_akcipher_sync_encrypt()            199/200 (patch 1: 0/200)
  pkcs1(rsa-caam,sha256) verification       398/400 (patch 2: 0/200)

In the wrong results reported, bytes 0 to 23 always hold the previous
content of the buffer: the buffer starts 168 bytes into the allocation,
at offset 40 of the 64-byte line that also holds edesc and
akcipher_op_done. The rare correct results are consistent with that
line being evicted before the device writes.

Both patches give the data buffer its own allocation, as rsa-pkcs1pad
did before 6.13. The driver could instead avoid writing its request
context while the buffers are mapped, but any DMA-based akcipher on a
non-coherent platform could hit the same problem, so fixing the callers
seemed more robust. rsassa_pkcs1_verify() could also use the fixed sync
helper instead of its own allocation; I kept the change minimal, and
will gladly rework the series in either direction.

Tested on i.MX8M Mini with 6.18.57: with caam_jr loaded, regulatory.db
loads again, and the test module reports no wrong result through the
sync helper and the pkcs1 template. The test module is available if
useful.

Stephane Debusne (2):
  crypto: akcipher - use a separate buffer in the sync helpers
  crypto: rsassa-pkcs1 - use a separate buffer for the RSA output

 crypto/akcipher.c     | 21 ++++++++++++++-------
 crypto/rsassa-pkcs1.c | 16 +++++++++++++---
 2 files changed, 27 insertions(+), 10 deletions(-)

-- 
2.43.0