linux-kernel - Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI

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]

Message-ID: <1514405711.26695.67.camel@impinj.com>
Date:   Wed, 27 Dec 2017 20:15:11 +0000
From:   Trent Piepho <tpiepho@...inj.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "radu.pirea@...rochip.com" <radu.pirea@...rochip.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "robh@...nel.org" <robh@...nel.org>,
        "cyrille.pitchen@...ev4u.fr" <cyrille.pitchen@...ev4u.fr>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "computersforpeace@...il.com" <computersforpeace@...il.com>,
        "vigneshr@...com" <vigneshr@...com>,
        "boris.brezillon@...e-electrons.com" 
        <boris.brezillon@...e-electrons.com>,
        "richard@....at" <richard@....at>,
        "marek.vasut@...il.com" <marek.vasut@...il.com>
Subject: Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD
 and SPI

On Wed, 2017-12-27 at 10:36 +0000, Mark Brown wrote:
> On Tue, Dec 26, 2017 at 06:45:28PM +0000, Trent Piepho wrote:
> 
> > Or, since this only fixes instances of DMA-unsafe buffers used in
> > access to SPI NOR flash chips, and since there are other SPI master
> > interface users, those chip specific fixes in some/all spi master
> > drivers are still needed to fix transfers not originated via spi-nor? 
> 
> SPI client drivers are *supposed* to use DMA safe memory already.  How
> often that happens in cases where it matters is a separate question, we
> definitely have users with smaller transfers that don't do the right
> thing but they're normally done using PIO anyway.

I wonder what the end goal is here?

A random collection of spi master drivers will accept DMA-unsafe
buffers in some way.  In some cases a framework like spi-nor provides
the fixup to spi-nor master drivers (none so far) and in other cases
(atmel-quadspi), the spi-nor master driver has its own fixes.

Generic spi masters like spi-atmel, spi-ti-qspi, and spi-davinci will
have their fixes for certain cases.

Perhaps spi flash drivers like m25p80 will have fixes too?

Some spi clients, like spidev, will have internal bounce buffers,
rather than userspace addresses or commands in stack variables, so that
they follow the rules about DMA safe buffers.

What exactly is caught as DMA unsafe and what is not will of course
vary greatly from driver to driver.  Some drivers will catch highmem
memory while other drivers will only detect vmalloc memory.  Some will
only catch an unsafe buffer if a specific SoC known to the driver to
have an aliasing cache is enabled.  Some will check buffers that arrive
via the spi_flash_read interface but not via generic spi transfers,
while others will check all spi transfer buffers.

Obviously, I don't think this path will lead to a desirable end.  Maybe
the basic assumption, that clients should provide DMA safe buffers,
should be revisited.  Experience has shown that it's too much to ask
for and spi clients will never get it right.  It would be better to try
to fix this at some common point between the clients and masters so it
can be done once and for all.