linux-kernel - Re: [PATCH v3] mtd: 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: <1689545397.30901605.1747063396608.JavaMail.zimbra@nod.at>
Date: Mon, 12 May 2025 17:23:16 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: Csókás Bence <csokas.bence@...lan.hu>, 
	linux-mtd <linux-mtd@...ts.infradead.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>, 
	Vignesh Raghavendra <vigneshr@...com>
Subject: Re: [PATCH v3] mtd: Verify written data in paranoid mode

----- Ursprüngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal@...tlin.com>
>> The problem we _have_ though happens to be a bit different: here we are
>> blursed with a system that corrupts data at a noticeable
>> probability. But the model is the same: a stochastic process introducing
>> bit errors on write. But I sincerely hope no one else has this problem,
>> and this is *not* the primary aim of this patch; it just happens to
>> solve our issue as well. But I intend it to be useful for the larger
>> Linux community, thus the primary goal is to solve the first issue.
> 
> I don't have a strong opinion there but I don't dislike this idea
> because it might also help troubleshooting errors sometimes. It is very
> hard to understand issues which happen to be discovered way after they
> have been generated (typically during a read, way later than a "faulty"
> write). Having this paranoid option would give a more synchronous
> approach which is easier to work with sometimes.

UBI offers this already, there is a write self-check as part of the io
checks that can be enabled
via debugfs per UBI device.
So for troubleshooting this should be good enough.
There is room for improvement, though. Currently it uses vmalloc().

Thanks,
//richard