crypto: safexcel: fix AEAD DMA mapping and cleanup

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