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 for Android: free password hash cracker in your pocket

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

Message-ID: <877elkpaoq.fsf@notabene.neil.brown.name>
Date:   Wed, 25 Jul 2018 07:48:21 +1000
From:   NeilBrown <neilb@...e.com>
To:     Brian Norris <computersforpeace@...il.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

On Tue, Jul 24 2018, Brian Norris wrote:

> 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.

That is how the Winbond W25Q256FV appears to behave in my experiments.
Any time you use a 4-byte address, the high byte is saved.  Any time you
use a 3-byte address, the saved high-byte is used.
The data sheet seems to support this understanding, as detailed in

Commit: f134fbbb4ff8 ("mtd: spi-nor: clear Winbond Extended Address Reg on switch to 3-byte addressing.")


>
>> >> 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'm not sure exactly what you encompass by the term "properly-designed",
but with the SOC that I have (mt7621) and the flash chip (Winbond
W25Q256FV) it is not possible to wire them up in any way that will work
reliably without software support for leaving 3-byte mode.

The SOC does not have an out-going reset line that signals a general
system reset - it only has one that signals watchdog reset.
The flash chip has an incoming reset line, but it shares a pin with
"hold", and that is the default use.  So we would need to program the
flash to listen for reset, and it would only catch a watchdog reset.
For any other reset, the CPU is (should be) in complete control (even
after a panic!) and it needs to reprogram the flash chip before
resetting the system.
But maybe you think either the SOC and/or the flash chip is not
"properly-designed" - and you may be correct..

Thanks,
NeilBrown


>
>> 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

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)