[RFC PATCH 0/2] dma-mapping: DMA_RESTRICTED_POOL and encryption

[Mostafa Saleh <smostafa@google.com>]

I have been looking into DMA code with DMA_RESTRICTED_POOL and how it
interacts with the memory encryption API, mainly in the context of
protected KVM (pKVM) on Arm64.

While trying to extend force_dma_unencrypted() to be pKVM aware I
noticed some inconsistencies in direct-dma code which looks as bugs.
I am not sure if there are any architectures affected by this at the
moment as some of the logic of memory encryption is forwarded to the
hypervisor as hypercalls ore realm calls.

I have wrote some fixes from my simplistic understanding.

However, Future looking, I feel like we would need to have a more
solid API for memory encryption and decryption, that can be used
consistently from both SWIOTLB(so we can also not decrypt per-device
pools by default), DMA-direct and other subsystems.
That would be useful in cases (at least for pKVM) where a device would
need to have a private encrypted pool, (if it needs to bounce memory
for any reason with leaking information by decrypting the data).
I am not sure how other CCA solutions deals with in Linux, I am
assuming they won't to need to bounce at all?

I can send another series for this which adds a property to SWIOTLB
buffers to be decrypted by default if that makes sense.

Mostafa Saleh (2):
  dma-mapping: Avoid double decrypting with DMA_RESTRICTED_POOL
  dma-mapping: Use the correct phys_to_dma() for DMA_RESTRICTED_POOL

 kernel/dma/direct.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.53.0.473.g4a7958ca14-goog