linux-kernel - Re: [PATCH RFC 00/17] ubifs: Add filesystem repair support

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: <1145531757.175508.1703844362355.JavaMail.zimbra@nod.at>
Date: Fri, 29 Dec 2023 11:06:02 +0100 (CET)
From: Richard Weinberger <richard@....at>
To: chengzhihao1 <chengzhihao1@...wei.com>
Cc: david oberhollenzer <david.oberhollenzer@...ma-star.at>, 
	Miquel Raynal <miquel.raynal@...tlin.com>, 
	Sascha Hauer <s.hauer@...gutronix.de>, 
	Tudor Ambarus <Tudor.Ambarus@...aro.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>, 
	linux-mtd <linux-mtd@...ts.infradead.org>
Subject: Re: [PATCH RFC 00/17] ubifs: Add filesystem repair support

----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@...wei.com>
> An: "david oberhollenzer" <david.oberhollenzer@...ma-star.at>, "richard" <richard@....at>, "Miquel Raynal"
> <miquel.raynal@...tlin.com>, "Sascha Hauer" <s.hauer@...gutronix.de>, "Tudor Ambarus" <Tudor.Ambarus@...aro.org>
> CC: "linux-kernel" <linux-kernel@...r.kernel.org>, "linux-mtd" <linux-mtd@...ts.infradead.org>
> Gesendet: Donnerstag, 28. Dezember 2023 02:40:55
> Betreff: [PATCH RFC 00/17] ubifs: Add filesystem repair support

Thanks a lot for sharing this.
Below you find some thoughts that came into my mind while skimming over the
patch series.

> UBIFS repair provides a way to fix inconsistent UBIFS image(which is
> corrupted by hardware exceptions or UBIFS realization bugs) and makes
> filesystem become consistent, just like fsck tools(eg. fsck.ext4,
> fsck.f2fs, fsck.fat, etc.) do.

I don't fully agree. The tool makes UBIFS mount again but you still have lost data
and later userspace might fail because file no longer contain what the application
expected.
So my fear is that we're just shifting the problem one layer up.

UBIFS never had a fsck for reasons. UBIFS tries hard to not become inconsistent,
by maintaining a data journal for example.
It can fail of course by hardware issues. e.g. if the underlying MTD loses bits,
but there is nothing UBIFS can do except something like storing duplicates
of data like BTRFS does.

And finally, the biggest pain point, it can fail due to bugs in UBIFS itself.
In my opinion bugs should get addressed by improving our test infrastructure
instead of working around.

> About why do we need it, how it works, what it can fix or it can not
> fix, when and how to use it, see more details in
> Documentation/filesystems/ubifs/repair.rst (Patch 17).

This needs to go into the cover letter.

> Testing on UBIFS repair refers to
> https://bugzilla.kernel.org/show_bug.cgi?id=218327
> 
> Whatever, we finally have a way to fix inconsistent UBFIS image instead
> of formatting UBI when UBIFS becomes inconsistent.

Fix in terms of making mount work again, I fear? As I said, most likely
the problem is now one layer above. UBIFS thinks everything is good but
userspace suddenly will see old/incomplete files.

What I can think of is a tool (in userspace like other fscks) which
can recover certain UBIFS structures but makes very clear to the user what
the data is lost. e.g. that inode XY now misses some blocks or an old version
of something will be used.
But this isl nothing you can run blindly in production.

Thanks,
//richard