linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Milan Broz <mbroz@redhat.com>
Cc: Sami Tolvanen <samitolvanen@google.com>,
	device-mapper development <dm-devel@redhat.com>,
	Mandeep Baines <msb@chromium.org>, Will Drewry <wad@chromium.org>,
	Kees Cook <keescook@chromium.org>,
	Mike Snitzer <snitzer@redhat.com>,
	linux-kernel@vger.kernel.org, Alasdair Kergon <agk@redhat.com>,
	Mark Salyzyn <salyzyn@google.com>
Subject: Re: [PATCH 0/4] dm verity: add support for error correction
Date: Fri, 6 Nov 2015 12:23:29 -0500 (EST)	[thread overview]
Message-ID: <alpine.LRH.2.02.1511061201520.5619@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <563B066C.6050202@redhat.com>



On Thu, 5 Nov 2015, Milan Broz wrote:

> On 11/05/2015 03:02 AM, Sami Tolvanen wrote:
> > This patch set adds error correction support to dm-verity, which
> > makes it possible to recover from data corruption in exchange of
> > increased space overhead.
> > 
> > The feature is implemented as part of dm-verity to take advantage
> > of the existing hash tree to improve performance and locate known
> > erasures.
> 
> Hi,
> 
> could you please elaborate why is all this needed? To extend support
> of some faulty flash chips?
> 
> Do you have some statistics that there are really such correctable errors
> in real devices?

I'm also wondering what is this patch useful for. Disks and flash 
controllers have their own error detection and correction, so the 
controller will much more likely return an I/O error rather than corrupted 
data. And the patch does absolutely nothing to recover from an I/O error, 
it only attempts to correct corrupted reads.

Another point - if the read-only system partition is experiencing some 
errors, than the read-write partition will probably have errors too 
(because both partitions are on the same flash chip) and the Chromebook or 
smartphone will be unusable anyway because of errors on the writeable 
partition. Do you have some real case where such error corrections 
increase longevity of some device?

> Anyway, I really do not understand layer separation here. Either we have
> cryptographically strong data integrity checking or we have
> error-correction. Are we sure this combination does not create some unintended
> gap in integrity checking? Why the integrity check should even try to do some
> error correction if there is an intentional integrity attack?
> 
> IMO if you need an error correction, this should be placed as a separate
> layer below the crypto integrity check, the same as RAID operates.

If error correction was placed below dm-verity, it would degrade 
performance because it would have to verify every sector, even if 
dm-verity said that the sector is valid.

But you can take raid5 in read-only mode, put it on several partitions 
protected with dm-verity and you get decent error correction (unlike this 
patch, it would also correct I/O errors returned by the flash controller). 
I suggest doing this.

> The second question - why are you writing another separate tool
> for maintenance for dm-verity when there is veritysetup?
> 
> Milan

Mikulas

  parent reply	other threads:[~2015-11-06 17:23 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05  2:02 [PATCH 0/4] dm verity: add support for error correction Sami Tolvanen
2015-11-05  2:02 ` [PATCH 1/4] dm verity: clean up duplicate hashing code Sami Tolvanen
2015-11-17 22:32   ` Kees Cook
2015-11-05  2:02 ` [PATCH 2/4] dm verity: separate function for parsing opt args Sami Tolvanen
2015-11-17 22:33   ` Kees Cook
2015-12-02 20:16   ` Mike Snitzer
2015-11-05  2:02 ` [PATCH 3/4] dm verity: add support for forward error correction Sami Tolvanen
2015-11-05  5:36   ` kbuild test robot
2015-11-05 22:06   ` kbuild test robot
2015-11-05  2:02 ` [PATCH 4/4] dm verity: ignore zero blocks Sami Tolvanen
2015-11-05 22:13   ` kbuild test robot
2015-11-05  7:34 ` [PATCH 0/4] dm verity: add support for error correction Milan Broz
2015-11-05 17:33   ` Sami Tolvanen
2015-11-09 16:37     ` Mike Snitzer
2015-11-09 19:19       ` Sami Tolvanen
2015-11-09 19:58         ` Mike Snitzer
2015-11-12 10:30         ` Milan Broz
2015-12-03  9:36           ` Sami Tolvanen
2015-11-12 18:50         ` Mikulas Patocka
2015-12-03  9:33           ` Sami Tolvanen
2015-12-02 20:22         ` Mike Snitzer
2015-12-03  9:11           ` Sami Tolvanen
2015-11-06 17:23   ` Mikulas Patocka [this message]
2015-11-06 19:06     ` Sami Tolvanen
2015-11-06 19:20       ` [dm-devel] " Zdenek Kabelac
2015-11-06 20:27         ` Sami Tolvanen
2015-11-06 21:05           ` Zdenek Kabelac
2015-11-06 21:23             ` Sami Tolvanen
2015-11-07 15:29               ` Mikulas Patocka
2015-11-07 15:20           ` Mikulas Patocka
2015-11-07 15:18       ` Mikulas Patocka
2015-11-09 15:06         ` Austin S Hemmelgarn
2015-12-03 14:26 ` [PATCH v2 0/2] " Sami Tolvanen
2015-12-03 14:26   ` [PATCH v2 1/2] dm verity: add support for forward " Sami Tolvanen
2015-12-03 14:26   ` [PATCH v2 2/2] dm verity: ignore zero blocks Sami Tolvanen
2015-12-03 19:54   ` [PATCH v2 0/2] dm verity: add support for error correction Mike Snitzer
2015-12-03 23:05     ` Mike Snitzer
2015-12-04 10:03       ` Sami Tolvanen
2015-12-04 21:09         ` Mike Snitzer
2015-12-07 13:21           ` Sami Tolvanen
2015-12-07 14:58             ` Mike Snitzer
2015-12-07 16:31               ` Sami Tolvanen
2015-12-07 18:07                 ` Milan Broz
2015-12-07 19:07                   ` Mike Snitzer
2015-12-08 10:18                     ` Sami Tolvanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.02.1511061201520.5619@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbroz@redhat.com \
    --cc=msb@chromium.org \
    --cc=salyzyn@google.com \
    --cc=samitolvanen@google.com \
    --cc=snitzer@redhat.com \
    --cc=wad@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).