linux-kernel - Re: Re: [PATCH] cfi: fix deadloop in cfi_cmdset_0002.c do_write

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: <fd352fb2cdfd8f483c419217c7e3153b3265e8d9.camel@infinera.com>
Date:   Fri, 8 Feb 2019 08:45:52 +0000
From:   Joakim Tjernlund <Joakim.Tjernlund@...inera.com>
To:     "ikegami_to@...oo.co.jp" <ikegami_to@...oo.co.jp>,
        "psobon@...zon.com" <psobon@...zon.com>,
        "boris.brezillon@...labora.com" <boris.brezillon@...labora.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ikegami@...ied-telesis.co.jp" <ikegami@...ied-telesis.co.jp>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "liujian56@...wei.com" <liujian56@...wei.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "computersforpeace@...il.com" <computersforpeace@...il.com>,
        "richard@....at" <richard@....at>,
        "marek.vasut@...il.com" <marek.vasut@...il.com>
Subject: Re: Re: [PATCH] cfi: fix deadloop in cfi_cmdset_0002.c
 do_write_buffer

On Thu, 2019-02-07 at 23:50 +0000, Sobon, Przemyslaw wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Hi Ikegami,
> 
> I have seen a case myself where a value was written, chip changed
> state to "ready" but when I was reading the value was incorrect.
> This can happen as result of intermittent issue with flash. It is
> hard to fall into scenario when testing on limited number of devices
> but with large enough population you can see that. Another situation
> is when a flash chip reaches its maximum number of writes. So for
> example a chip is designed for 100k writes to a page. Once you
> reach that number of writes you can have invalid data written to
> flash but chip itself reports everything was good and switches to
> "ready" state.

This makes perfekt sense but the AMD flash control I/F does not. You will
find that trying to do advanced things with "toggle" bits is very hard.
Especially when you also need to scale it to interleaved flashes.

I think the odd delay when flash fails is quite OK. If you want to
fix this you need to move the other control I/F(which mimics what Intel has)

 Jocke