linux-kernel - Re: [PATCH v1] mtd: spinand: micron: correct parameters

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: <20230817095354.3df2f7f9@xps-13>
Date:   Thu, 17 Aug 2023 09:53:54 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Frieder Schrempf <frieder.schrempf@...tron.de>
Cc:     Martin Kurbanov <mmkurbanov@...rdevices.ru>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
        kernel@...rdevices.ru
Subject: Re: [PATCH v1] mtd: spinand: micron: correct parameters

Hi Frieder,

frieder.schrempf@...tron.de wrote on Wed, 16 Aug 2023 17:35:56 +0200:

> On 16.08.23 17:28, Martin Kurbanov wrote:
> > Hi Frieder.
> > 
> > On 16.08.2023 10:21, Frieder Schrempf wrote:  
> >> I'm okay with 1. and with adjusting region->offset to 4. But I don't
> >> really get why we want to restrict the free oob data to the
> >> non-ECC-protected area only. Is this specific to Micron? Other SPI NAND
> >> drivers also spread the free area over both, the ECC-protected and the
> >> non-protected bytes. Why do it differently here?  
> > 
> > We encountered a problem with the JFFS2 file system: JFFS2 marks erased
> > blocks with a marker to avoid re-erasing them. To do this, it writes
> > a special marker (cleanmarker) in the free OOB area. And if this OOB
> > area is protected by ECC, the ECC will be written. However, during
> > the next write to the main area of the same block, the ECC will be
> > incorrect because it's necessary to program both the main area and
> > the OOB area at one programming time, so that the ECC parity code can
> > be calculated properly. Other SPI NAND flash also susceptible to
> > this problem.  
> 
> Thanks for the explanation. As this is a generic issue, we need to fix
> it in the core and not in the Micron driver.

It's not the first time we face this issue and the first approach we
used was to "fix" the OOB layout to include all free bytes (not only
protected bytes), which had the nice side-effect of allowing to write
the cleanmarker in an ECC-free area and allow that chip to be used with
JFFS2. This is indeed not a proper solution and I agree we should have
a system-wide solution.

> Also I wonder if JFFS2 should instead write the cleanmarker with ECC
> being turned of explicitly.

The real question is, why would you still want to use JFFS2 on
SPI-NAND? UBI is meant for that. JFFS2 was designed with NORs in mind,
it can be used on small NAND chips because UBI is a bit glutton wrt,
but I doubt we still have "small" SPI-NANDs on the market which require
JFFS2 anymore. Do we?

Anyhow, if people want JFFS2 on NANDs, I agree we should maybe change
how JFFS2 works and force raw accesses when it comes to writing the
cleanmarker, because there is no knowledge of what is ECC protected or
not in the current OOB layouts. I however have no idea of the possible
side-effects, I've never looked into JFFS2 so deeply.

> I don't know enough about NAND and JFFS2 to point out a correct fix, but
> I hope Miquel and Richard have some ideas.

Thanks,
Miquèl