linux-kernel - Re: [RFC] mtd: ubi: skip programming unused bits in ubi headers

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] [day] [month] [year] [list]

Message-ID: <CAAyq3SZT67uwggdNX99qEc4bwSkUw2U=sCc6mon064D=f7oH=w@mail.gmail.com>
Date: Fri, 5 Sep 2025 11:21:15 +0800
From: Cheng Ming Lin <linchengming884@...il.com>
To: Richard Weinberger <richard@....at>
Cc: chengzhihao1 <chengzhihao1@...wei.com>, Miquel Raynal <miquel.raynal@...tlin.com>, 
	Vignesh Raghavendra <vigneshr@...com>, linux-mtd <linux-mtd@...ts.infradead.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>, Alvin Zhou <alvinzhou@...c.com.tw>, 
	leoyu <leoyu@...c.com.tw>, Cheng Ming Lin <chengminglin@...c.com.tw>
Subject: Re: [RFC] mtd: ubi: skip programming unused bits in ubi headers

Hi Richard,

Richard Weinberger <richard@....at> 於 2025年8月14日 週四 下午7:30寫道：
>
> ----- Ursprüngliche Mail -----
> > Von: "Cheng Ming Lin" <linchengming884@...il.com>
> >> I have been told that writing 0xFF bytes to NAND should be avoided.
> >> This is also why UBI initializes them to 0x00.
> >
> > Normally, after a NAND flash block is erased, all bits are in the 0xFF
> > state. Programming 0xFF in this case will not actually change the NAND
> > cells, as the device can inhibit programming—either by raising the
> > bitline voltage or using a self-boosted program inhibit mechanism.
> > Therefore, programming 0xFF is a normal and harmless operation for NAND
> > flash.
>
> That's the crucial question. Is this true for all NAND chips?
> Do avoid larger writes of 0xFF patterns file systems such as UBIFS
> also use compression a lot.
> At least that's what I have been told when I asked 10+ years ago
> how UBI works.

You are correct that there is an issue when blank data pages are repeatedly
erased. This can lead to cells entering a too deep VT state, which may
cause program failures in subsequent operations.

To address this, newer NAND generations typically perform a pre-program
step before executing the actual erase. This keeps the VT distribution from
going too deep, thereby avoiding the blank-page degradation problem.
Such pre-PGM techniques have been widely adopted for roughly the past
10–15 years.

Additionally, JESD22-A117E (page 6, section 4.1.2.1) specifies examples of
acceptable data patterns, including solid-programmed, checkerboard/inverse-
checkerboard, and checkerboard-with-fill patterns. According to
qualification knowledge bases, using 0x00 can sometimes trigger special
failure modes, whereas writing 0xFF is more robust.

Additionally, the Kioxia TC58NVG1S3HTA00 datasheet (page 63) also notes
that continuous program/erase cycling with a high percentage of ‘0'
bits in the data pattern can accelerate block endurance degradation.
This further supports avoiding large 0x00 patterns.

Link: https://europe.kioxia.com/content/dam/kioxia/newidr/productinfo/datasheet/201910/DST_TC58NVG1S3HTA00-TDE_EN_31442.pdf

>
> Thanks,
> //richard
>

Thanks,
Cheng-Ming Lin