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: <53a4fe26-3a6a-47ce-8532-be60da674aca@kontron.de>
Date:   Wed, 16 Aug 2023 17:35:56 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Martin Kurbanov <mmkurbanov@...rdevices.ru>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>
Cc:     linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
        kernel@...rdevices.ru
Subject: Re: [PATCH v1] mtd: spinand: micron: correct parameters

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.

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

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