linux-kernel - Re: [PATCH 0/4] dm verity: add support for error correction

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: <alpine.LRH.2.02.1511121318110.15026@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Thu, 12 Nov 2015 13:50:04 -0500 (EST)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Sami Tolvanen <samitolvanen@...gle.com>
cc:	Mike Snitzer <snitzer@...hat.com>, Milan Broz <mbroz@...hat.com>,
	device-mapper development <dm-devel@...hat.com>,
	Mandeep Baines <msb@...omium.org>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	linux-kernel@...r.kernel.org, Alasdair Kergon <agk@...hat.com>,
	Mark Salyzyn <salyzyn@...gle.com>
Subject: Re: [PATCH 0/4] dm verity: add support for error correction

On Mon, 9 Nov 2015, Sami Tolvanen wrote:

> > Also, the 2 other big questions from Mikulas need answering:
> > 1) why aren't you actually adjustng error codes, returning success, if
> >    dm-verity was able to trap/correct the corruption?
> 
> We don't see actual I/O errors very often. Most corruption we've seen
> is caused by flaky hardware that doesn't return errors. However, I can
> certainly change to code to attempt recovery in this case too.

What flash controller and chips do you use? What is the probability of I/O 
error and what is the probability of silent data corruption? Is the silent 
data corruption permanent or transient? What is causing the silent data 
corruption (decay in flash chips?, errors on the bus?) Why can't you ask 
the hardware engineers to use a controler with proper error correction?

Without these data - it looks like you first wrote the patch and then 
tried to make some excuses why it should be accepted.

I'm also a little bit concerned that the patch will increase prevalence of 
crapware on the market - when accepted, this kind of reasoning will 
follow: "now we have error correction in the kernel, so we cut down flash 
overprovisioning, save a dollar or two per device, and produce a crap that 
randomly corrupts user's data on the read-write partition (because that 
partition not protected by the error correction)".

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/