Re: [PATCH for 5.10.x 2/2] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"

From: Greg KH <gregkh@linuxfoundation.org>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: stable@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Doug Gilbert <dgilbert@interlog.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Thiago Jung Bauermann <bauerman@linux.ibm.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH for 5.10.x 2/2] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
Date: Tue, 22 Mar 2022 11:28:12 +0100	[thread overview]
Message-ID: <YjmkvPFTOkxiP29k@kroah.com> (raw)
In-Reply-To: <20220322100218.2158138-3-pasic@linux.ibm.com>

On Tue, Mar 22, 2022 at 11:02:18AM +0100, Halil Pasic wrote:
> Unfortunately, we ended up merging an old version of the patch "fix info
> leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph
> (the swiotlb maintainer), he asked me to create an incremental fix
> (after I have pointed this out the mix up, and asked him for guidance).
> So here we go.
> 
> The main differences between what we got and what was agreed are:
> * swiotlb_sync_single_for_device is also required to do an extra bounce
> * We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters
> * The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE
>   must take precedence over DMA_ATTR_SKIP_CPU_SYNC
> 
> Thus this patch removes DMA_ATTR_OVERWRITE, and makes
> swiotlb_sync_single_for_device() bounce unconditionally (that is, also
> when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale
> data from the swiotlb buffer.
> 
> Let me note, that if the size used with dma_sync_* API is less than the
> size used with dma_[un]map_*, under certain circumstances we may still
> end up with swiotlb not being transparent. In that sense, this is no
> perfect fix either.
> 
> To get this bullet proof, we would have to bounce the entire
> mapping/bounce buffer. For that we would have to figure out the starting
> address, and the size of the mapping in
> swiotlb_sync_single_for_device(). While this does seem possible, there
> seems to be no firm consensus on how things are supposed to work.
> 
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE")
> Cc: stable@vger.kernel.org
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> [pasic@linux.ibm.com: adapted for 5.10]
> ---
>  Documentation/core-api/dma-attributes.rst |  8 --------
>  include/linux/dma-mapping.h               |  8 --------
>  kernel/dma/swiotlb.c                      | 25 +++++++++++++++--------
>  3 files changed, 16 insertions(+), 25 deletions(-)

What is the git commit id of this commit in Linus's tree?

thanks,

greg k-h