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