[PATCH crypto 0/2] crypto: safexcel: fix AEAD DMA mapping and cleanup

[Ralf Lici <ralf@mandelbit.com>]

Hi,

This series fixes a couple of bugs that affect the safexcel driver with
the first one targeting a double unmap path and the second one (more
important) mapping AEAD buffers with finer granularity.

While testing ovpn (the OpenVPN data channel offload kernel module) on
two GL.iNet GL-MT6000 routers (using the MT7986 EIP97 on a non-coherent
Cortex-A53 system), once the kernel selects the hardware AES-GCM
provider, traffic became unreliable in ways that were difficult to
explain from the ovpn side. This is not the first such report: OpenWrt
users had described tunnels that stopped passing traffic when kernel
ovpn or ipsec and safexcel were loaded together.

During the tests I noticed that the stock driver reported successful
crypto completion, yet the reproducer found damaged output. At data
offsets 0, 32 and 66 modulo 128, respectively, the first 40, 8 and 38
payload bytes were wrong. Those lengths match the part of the payload
sharing a 64-byte cache line with the small AAD mapping. Fragmented
out-of-place encryption also failed with only one request in flight.

The problem is that safexcel describes too much of an AEAD request as
device output. It maps every entry of an in-place request as
DMA_BIDIRECTIONAL and every entry of an out-of-place destination as
DMA_FROM_DEVICE, even though AAD is read-only and a decrypt tag is
input-only. On these routers, an unaligned, small entry can be bounced
by SWIOTLB. Unmapping that entry as device output copies unchanged
bounce contents back; cache maintenance on the neighboring payload
mapping can then write stale CPU bytes over ciphertext or plaintext
which the EIP97 had produced correctly. The fixed SWIOTLB pool is only 1
MiB, with 512 slots of 2 KiB each, so these tiny entries also have a
disproportionate bounce cost under network load.

Thus, the second patch in this series gives each AEAD entry the
direction its contents require: input-only entries use DMA_TO_DEVICE,
pure out-of-place output uses DMA_FROM_DEVICE, and mixed or in-place
output uses DMA_BIDIRECTIONAL.

I also checked whether other network users of the accelerator behaved
the same way. With the corrected driver, RFC 4106 AES-128-GCM ESP passed
transport-mode tests with one, two and four SA pairs, without
authentication or replay errors.

kTLS revealed a different limit. Sustained TLS 1.2 AES-128-GCM still
corrupts when multiple 16 KiB records are live concurrently, both with
stock safexcel and with the corrected prototype. Serializing records
made 256 MiB transfers pass. I think the remaining issue is of the same
class: kTLS can place neighboring records in regions of shared pages,
making concurrent cache-line-sharing DMA mappings the leading
explanation, although I have not captured an exact cache-line trace.
These patches do not claim to fix that separate kTLS failure.

Cheers!

Ralf Lici
Mandelbit Srl

---
Ralf Lici (2):
  crypto: safexcel - Avoid unmapping failed DMA mappings
  crypto: safexcel - Map AEAD buffers with accurate DMA directions

 .../crypto/inside-secure/safexcel_cipher.c    | 173 +++++++++++++++---
 1 file changed, 150 insertions(+), 23 deletions(-)


base-commit: 60892a384aa1e65d0e703e1c513417bdf0c80777
-- 
2.55.0