linux-kernel - Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

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:   Tue, 24 Jul 2018 12:41:10 -0700
From:   Brian Norris <computersforpeace@...il.com>
To:     NeilBrown <neilb@...e.com>
Cc:     Boris Brezillon <boris.brezillon@...tlin.com>,
        Zhiqiang Hou <Zhiqiang.Hou@....com>,
        linux-mtd@...ts.infradead.org,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Boris BREZILLON <boris.brezillon@...e-electrons.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Richard Weinberger <richard@....at>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>
Subject: Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when
 exiting

Hi,

On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
> On Tue, Jul 24 2018, Boris Brezillon wrote:
> > On Tue, 24 Jul 2018 08:46:33 +1000
> > NeilBrown <neilb@...e.com> wrote:
> >> One possibility that occurred to me when I was exploring this issue is
> >> to revert to 3-byte mode whenever 4-byte was not actively in use.
> >> So any access beyond 16Meg is:
> >>  switch-to-4-byte ; perform IO ; switch to 3-byte
> >> or similar.  On my hardware it would be more efficient to
> >> use the 4-byte opcode to perform the IO, then reset the cached
> >> 4th address byte that the NOR chip transparently remembered.

Do these chips cache the last 4th-byte used? I don't recall reading
that, but that would be interesting. It also sounds like that would make
things even more difficult to do robustly.

> >> This adds a little overhead, but should be fairly robust.
> >> It doesn't help if something goes terribly wrong while IO is happening,
> >> but I don't think any other software solution does either.
> >> 
> >> How would you see that approach?
> >
> > I think the problem stands: people that have proper HW mitigation for
> > this problem (NOR chip is reset when the Processor is reset) don't want
> > to pay the overhead. So, even if we go for this approach, we probably
> > want to only do that for broken HW.

If it actually saves bytes on the wire to stay in 3-byte mode more
often, then that could be helpful to all systems. But otherwise, yes, it
doesn't really belong on a properly-designed system.

> I agree that a "my-hardware-is-suboptimal" flag is appropriate.
> I was addressing the suggestion that the current approach doesn't handle
> all corner cases and was suggesting a different approach that might
> handle more corner-cases.  I should have been more explicit about that.

If you want to talk about optimizing the broken-hardware hack, then
fine. That's not my interest at all.

Brian