linux-kernel - Re: [PATCH 1/1] fs:ubifs:recovery:fixup UBIFS cannot recover master node issue

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]

Date:	Mon, 1 Feb 2016 09:28:57 +0100
From:	Richard Weinberger <richard@....at>
To:	Bean Huo 霍斌斌 (beanhuo) 
	<beanhuo@...ron.com>, Artem Bityutskiy <dedekind1@...il.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Brian Norris <computersforpeace@...il.com>
Cc:	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Peter Pan 潘栋 (peterpandong) 
	<peterpandong@...ron.com>,
	Karl Zhang 张双锣 (karlzhang) <karlzhang@...ron.com>,
	Jason Tian 田晓强 (jasontian) 
	<jasontian@...ron.com>
Subject: Re: [PATCH 1/1] fs:ubifs:recovery:fixup UBIFS cannot recover master
 node issue

Bean,

Am 01.02.2016 um 08:17 schrieb Bean Huo 霍斌斌 (beanhuo):
>> If you can explain in detail why UBIFS' assumptions are wrong and how such
>> corruptions can happen on SLC we can talk.
>> But I think then we'd have to redo a lot of UBI and UBIFS code.
> 
> I will hack my patch again, and double check these strict checks.
> But I still insist on Master node should always be recovered by another good master,
> even if two corrupted pages exist in one block. This is more reasonable and reliable.
> Of course, so far, we did not meet this scenario on SLC NAND.
> Current UBIFS master node recovery mechanism totally can handle with
> Power loss no matter MLC or SLC, why not let UBIFS more reliable? Two master node blocks
> Just for SLC NAND?

Of course, I'm all for improvements. But if you talk about "more reliable" you have to define
first what the issue is.
As I said, we have this strict checks for reasons and they did a very
good service so far.
I've seen a lot UBIFS corruptions where the master node was damaged but not a single time
it was UBIFS' fault. It was always a subtle MTD driver issue.

Thanks,
//richard