linux-kernel - Re: [PATCH] spi-nor: Verify written data in paranoid mode

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: <373620122.295980015.1744808943985.JavaMail.zimbra@nod.at>
Date: Wed, 16 Apr 2025 15:09:03 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: Csókás Bence <csokas.bence@...lan.hu>
Cc: Michael Walle <mwalle@...nel.org>, linux-mtd <linux-mtd@...ts.infradead.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>, 
	Szentendrei, Tamás <szentendrei.tamas@...lan.hu>, 
	Tudor Ambarus <tudor.ambarus@...aro.org>, 
	pratyush <pratyush@...nel.org>, 
	Miquel Raynal <miquel.raynal@...tlin.com>, 
	Vignesh Raghavendra <vigneshr@...com>
Subject: Re: [PATCH] spi-nor: Verify written data in paranoid mode

----- Ursprüngliche Mail -----
> Von: "Csókás Bence" <csokas.bence@...lan.hu>
>>> Add MTD_SPI_NOR_PARANOID config option for verifying all written data to
>>> prevent silent bit errors to be undetected, at the cost of halving SPI
>>> bandwidth.
>> 
>> What is the use case for this? Why is it specific to SPI-NOR
>> flashes? Or should it rather be an MTD "feature". I'm not sure
>> whether this is the right way to do it, thus I'd love to hear more
>> about the background story to this.
> 
> Well, our case is quite specific, but we wanted to provide a general
> solution for upstream. In our case we have a component in the data path
> that can cause a burst bit error, on average after about a hundred
> megabytes written.

Hmm. So, there is a serve hardware issue you're working around.

> We _could_ make it MTD-wide, in our case we only have a NOR Flash
> onboard so this is where we added it. If it were in the MTD core, where
> would it make sense?

I'm not so sure whether it makes sense at all.
In it's current form, there is no recovery. So anything non-trivial
on top of the MTD will just see an -EIO and has to give up.
E.g. a filesystem will remount read-only.

Thanks,
//richard