linux-kernel - RE: [REGRESSION] Recent swiotlb DMA_FROM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 26 Mar 2022 22:38:27 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Toke Høiland-Jørgensen <toke@...e.dk>
CC:     Halil Pasic <pasic@...ux.ibm.com>,
        Robin Murphy <robin.murphy@....com>,
        Maxime Bizon <mbizon@...ebox.fr>,
        Netdev <netdev@...r.kernel.org>, Kalle Valo <kvalo@...nel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Oleksandr Natalenko <oleksandr@...alenko.name>,
        stable <stable@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        iommu <iommu@...ts.linux-foundation.org>,
        Olha Cherevyk <olha.cherevyk@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Christoph Hellwig <hch@....de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break
 ath9k-based AP

From: Linus Torvalds
> Sent: 26 March 2022 18:39
> 
> On Sat, Mar 26, 2022 at 9:06 AM Toke Høiland-Jørgensen <toke@...e.dk> wrote:
> >
> > I was also toying with the idea of having a copy-based peek helper like:
> >
> > u32 data = dma_peek_word(buf, offset)
> 
> I really don't think you can or want to have a word-based one.
> 
> That said, I like the *name* of that thing.
> 
> I think a lot of confusion comes from the very subtle naming of
> fundamentally having a lot of odd conditions with
> 
>  - two different "directions of the sync" - ie who it is that cares:
> 
>        dma_sync_single_for_{cpu,device}
> 
>  - three different "direction of the data" - ie who it is that writes the data:
> 
>         DMA_FROM_DEVICE / DMA_TO_DEVICE / DMA_BIDIRECTIONAL
> 
> so you have six possible combinations, three of which seem insane and
> not useful, and of the three that are actually possible, some are very
> unusual (it exactly that "device is the one writing, but we want to
> sync the dma area for the device").

Another 2c :-)

Is the idea of 'buffer ownership' even a good one?
Perhaps the whole thing would be better described in terms of
what happens when bounce buffers are used.
So there are notionally two buffers.
One accessed by the cpu, the other by the device.

There are then just 3 things that happen:
1) Dirty data may get moved to the other buffer at any time.
   So the driver must not dirty buffers (cache lines) that the
   device might write to.
2) The cpu has to request data be copied to the device buffer
   after updating the cpu buffer.
   This makes the cpu buffer 'not dirty' so copies (1) can no
   longer happen.
3) The cpu has to request data be copied from the device buffer
   before looking at the data.
All copies affect a dma-cache-line sized block of data (which
might be device dependant).
An optimised version of (2) that doesn't actually do the copy
can be implemented for use prior to read requests.

For cache-coherent memory only (1) happens and (2) and (3)
are no operations.
For non-coherent memory (2) is write-back-and-invalidate and
(3) might just be an invalidate.
For bounce buffers all are actual copies - and additional
operations might be needed for device access to the bounce
buffer itself.

For security reasons bounce buffers may need initialising.
But this would be done when they are allocated.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)