linux-kernel - Re: [PATCH v6 0/5] Micron SLC NAND filling block

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: <20200602090550.2e6403f3@xps13>
Date:   Tue, 2 Jun 2020 09:05:50 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Bean Huo <huobean@...il.com>
Cc:     vigneshr@...com, s.hauer@...gutronix.de,
        boris.brezillon@...labora.com, derosier@...il.com,
        Richard Weinberger <richard@....at>,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Bean Huo <beanhuo@...ron.com>
Subject: Re: [PATCH v6 0/5] Micron SLC NAND filling block

Hello

Bean Huo <huobean@...il.com> wrote on Mon, 01 Jun 2020 23:10:43 +0200:

> Hi Richard 
> would you please help us confirm below question??
> 
> Thanks,
> Bean
> 
> On Thu, 2020-05-28 at 16:14 +0200, Bean Huo wrote:
> > hi, Richard
> > 
> > 
> > On Mon, 2020-05-25 at 14:18 +0200, Bean Huo wrote:  
> > > After submission of patch V1 [1] and V2 [2], we stopped its update
> > > since we get
> > > stuck in the solution on how to avoid the power-loss issue in case
> > > power-cut
> > > hits the block filling. In the v1 and v2, to avoid this issue, we
> > > always damaged
> > > page0, page1, this's based on the hypothesis that NAND FS is UBIFS.
> > > This
> > > FS-specifical code is unacceptable in the MTD layer. Also, it
> > > cannot
> > > cover all
> > > NAND based file system. Based on the current discussion, seems that
> > > re-write all
> > > first 15 page from page0 is a satisfactory solution.  
> >   
> 
> > This patch has overwrite page0~page14, damage EC and VID header
> > boths.
> > I know this is safe for UBIFS, even fastmap is enabled (you fixed
> > this in (ubi: fastmap: Correctly handle interrupted erasures in
> > EBA)).
> > Now, how about jffs2? 
> > 
> > 
> > Thanks,
> > Bean
> >   
> 

FYI, Bean already askes me privately and here was my answer. Feel free
to comment.

---8<---
I'm not sure we are synced on this issue, because it is clearly
not addressed in your patchset.

Quoting Richard, the ubifs log uses a fixed range of LEBs. It replays
them upon mount and checks whether they are empty, new or outdated refs
it assumes that interrupted erase got detecred by UBI and such a LEB
will just contain 0xFF bytes. Rewriting the page before erase basically
fails this assumption.

For JFFS2, the problem is the clean marker. You cannot destroy the
payload while keeping the clean marker which says "this block is fine
and contain data".

Also, if you destroy the clean marker, you need to take care of not
turning the block being discovered as "bad" at reboot time if a power
cut happens before the erasure.

All of this is not impossible but:
- we need to write specific code for each user
- we don't want to create more problems that we already have

I cannot give you more details because this is not something that I
master. Ask Richard directly if you need more details on this.
--->8---

Cheers,
Miquèl