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

[Jeff Barnes <jeffbarnes@linux.microsoft.com>]

Hi Stephane,

Thanks for posting this. While investigating CAAM RSA on another arm64
non-coherent system, I found a separate DMA issue affecting the same
in-place request shape.

Your patches move the synchronous-helper and RSASSA-PKCS1 buffers into
separate allocations, while intentionally retaining src == dst. That
addresses cache-line sharing between the payload and mutable request
context. The issue I observed is in rsa-caam's ownership of that
exact-alias SG.

On an NXP LX2160A with CAAM Era 10 behind an ARM SMMUv2 translated DMA
domain, rsa-caam mapped the same effective SG twice:

- first with DMA_TO_DEVICE, producing mapping A;
- then with DMA_FROM_DEVICE, producing a different mapping B.

Because dma_map_sg() writes DMA metadata into the SG, the second map
replaced the metadata describing A. Completion subsequently unmapped B
as the destination and then consumed the same overwritten metadata when
unmapping the source. The second teardown attempted to remove B again,
while the SG no longer retained the metadata needed to release A.

The public completion warning included:

    __arm_lpae_unmap
    arm_lpae_unmap_pages
    arm_smmu_unmap_pages
    __iommu_unmap
    iommu_unmap_fast
    __iommu_dma_unmap
    iommu_dma_unmap_sg
    dma_unmap_sg_attrs
    rsa_io_unmap
    rsa_pub_done
    caam_jr_dequeue

A corresponding private RSA case reached rsa_io_unmap() through
rsa_priv_f_done(). Certificate verification reproduced the public path
with a 512-byte operand.

I tested a narrow downstream prototype that, after source normalization,
maps an exact effective-head alias once with DMA_BIDIRECTIONAL over the
larger of the source and destination extents. The observed public 256/256
and certificate-verification 512/512 requests each had one original SG
entry and returned one DMA segment. They then used one BIDIRECTIONAL map
and one matching unmap with the original entry count.

With that prototype, the system booted successfully and the tested logs
contained no matches for __arm_lpae_unmap, __arm_lpae_map,
__iommu_dma_unmap, RSA algorithm failures, invalid output, RSA self-test
failures, or rsa-caam failures. These are downstream results for the
observed one-entry mappings, not validation of arbitrary multi-entry
exact aliases or a current upstream patch.

Changwei's pending unaligned-destination bounce-buffer patch appears
complementary:

https://lore.kernel.org/linux-crypto/20261004210200.290119-3-changwei.zou@canonical.com/

For an unaligned destination, bounce substitution would make the
effective source and destination distinct, allowing separate TO/FROM
ownership. For an aligned exact alias, the original SG would remain
shared and would still need one BIDIRECTIONAL mapping. If combined,
destination substitution appears to need to happen before effective-head
alias classification.

The unresolved case is a shared mapping that returns more than one DMA
segment. Using the union mapping's returned count for both logical
hardware views can change existing SEC4 source-table selection,
particularly for a shorter source. I do not yet have hardware evidence
for that case.

Would the preferred direction be:

1. an initial narrowly bounded CAAM RFC demonstrating the one-owner
   BIDIRECTIONAL correction and explicitly rejecting unresolved
   multi-segment aliases;
2. coordination with the pending destination-bounce work for problematic
   aliases; or
3. constructing separately bounded source and destination SEC4 views
   over one shared mapping?

I wanted to raise this here before posting a separate RFC because your
series confirms that exact-alias requests remain intentional, and the two
DMA issues are independent but affect the same callers.

Thanks,
Jeff