Re: [PATCH crypto 2/2] crypto: safexcel - Map AEAD buffers with accurate DMA directions

[Ralf Lici]

On Mon, 28 Sep 2026 15:12:48 +1000, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Sep 23, 2026 at 11:13:17AM +0200, Ralf Lici wrote:
> >
> > There is no caller to identify for that particular single-entry layout,
> > it was only a hypothetical example in response to your question. Even
> > for out-of-place AEAD, the destination starts with space reserved for
> > the associated data (as documented in the comment at the top of
> > include/crypto/aead.h). A single linear destination entry can therefore
> > contain both that reserved prefix, which the device does not write, and
> > the ciphertext and tag, which it does write. Because the DMA direction
> > applies to the whole entry, such a mixed entry is mapped
> > DMA_BIDIRECTIONAL.
>
> So why is it a problem if the dst SG list entries aren't pointing
> to memory that's also occupied by the SG list entries?
>
> Even if the hardware doesn't write to the data, it should be OK to
> map them.
>
> The only issue that I can see is if the same memory is present in
> both the src SG list and the dst SG list, but that is expressly
> forbidden for out-of-place operations, and indeed would be a grave
> security issue.
>

I think the missing point is that DMA_FROM_DEVICE is not neutral for
bytes which the device does not write.

For an out-of-place request, the caller may have already populated the
reserved destination AAD area. The AEAD API says that this area will not
be written by the cipher operation:

  Even in the out-of-place case, space must be reserved in the
  destination for the associated data, even though it won't be written
  to.

With SWIOTLB, however, mapping it as DMA_FROM_DEVICE may leave the
corresponding bounce-buffer bytes uninitialized, and unmapping then
copies those untouched bytes back over the caller's AAD.

The API also explicitly permits the source and destination AAD entries
to describe the exact same byte range (and users do this in practice,
for example nitrox_rfc4106_set_aead_rctx_sglist):

  It is permissible for the "destination" associated data to alias
  the "source" associated data.

Therefore, this is a valid out-of-place request:

  src: [ AAD X ] [ plaintext P ]
  dst: [ AAD X ] [ ciphertext C ] [ tag T ]

P and C use separate storage. Only the two AAD entries point to the same
addresses X.

Safexcel currently maps the source list as DMA_TO_DEVICE and the whole
destination list as DMA_FROM_DEVICE. Consequently, X is mapped as device
output even though the accelerator deliberately does not write it. On a
non-coherent system or with SWIOTLB, unmapping the destination can then
overwrite X with stale data.

Thanks for following up.

-- 
Ralf Lici
Mandelbit Srl