Re: [PATCH v8 15/23] dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks

Aneesh Kumar K.V <[email protected]>
Newsgroups gmane.linux.ports.ppc.embedded,gmane.linux.ports.arm.kernel,gmane.linux.kernel
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.