Re: [PATCH v8 15/23] dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
Aneesh Kumar K.V <[email protected]> Wed, 29 Jul 2026 14:39:08 +0530
| Newsgroups | dev.linux.lists.iommu,dev.linux.lists.linux-coco,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
Mostafa Saleh <[email protected]> writes: >> static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size, >> - bool is_ram) >> + bool is_ram, unsigned long attrs) >> { >> dma_addr_t end = addr + size - 1; >> >> if (addr == DMA_MAPPING_ERROR) >> return false; >> + /* >> + * The DMA address was derived from encrypted RAM, but this device >> + * requires unencrypted DMA addresses. Treat it as not DMA-capable >> + * so the caller can fall back to a suitable SWIOTLB pool. >> + */ >> + if (!(attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev)) >> + return false; >> + > > I guess it does not make sense to check the other way? I'd be worried if > some a confidential device uses shared memory which might leak info. > From the perspective of the dma_capable() check, this should be allowed; that is, a trusted device is permitted to access shared memory. -aneesh