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: <608935583.115196.1755171013804.JavaMail.zimbra@nod.at>
Date: Thu, 14 Aug 2025 13:30:13 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: Cheng Ming Lin <linchengming884@...il.com>
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

----- 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.

Thanks,
//richard