linux-kernel - Re: [PATCH v2 0/2] 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: <20151207190743.GA30593@redhat.com>
Date:	Mon, 7 Dec 2015 14:07:43 -0500
From:	Mike Snitzer <snitzer@...hat.com>
To:	Milan Broz <mbroz@...hat.com>
Cc:	Sami Tolvanen <samitolvanen@...gle.com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	Mandeep Baines <msb@...omium.org>,
	Will Drewry <wad@...omium.org>,
	Alasdair Kergon <agk@...hat.com>, dm-devel@...hat.com,
	linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
	Mark Salyzyn <salyzyn@...gle.com>
Subject: Re: [PATCH v2 0/2] dm verity: add support for error correction

On Mon, Dec 07 2015 at  1:07pm -0500,
Milan Broz <mbroz@...hat.com> wrote:

> On 12/07/2015 05:31 PM, Sami Tolvanen wrote:
> > On Mon, Dec 07, 2015 at 09:58:14AM -0500, Mike Snitzer wrote:
> >> Great.  Moving forward it'd be awesome if you could work to get your
> >> verity FEC support regression tests into cryptsetup's tests.
> > 
> > Sure. These tests would basically involve generating a valid disk
> > image, corrupting it up to the theoretical maximum, and verifying that
> > dm-verity can correct it.
> 
> Does the code handle/report even the same type of data corruption
> for RS blocks? Or this is just silently ignored until
> data area corruption happens?
> Sorry, I did not study the code here, I am just curious :)
> 
> (IOW I mean if data are ok but recovery metadata is corrupted.)

There is no preemptive accessing/checking of the RS blocks.  Once a
parity is needed for a given block, due to some corruption, the RS block
will be accessed with:

fec_decode_bufs -> fec_read_parity() -> fec_decode_rs8() -> decode_rs8()

I'm not seeing any verification of the metadata in fec_read_parity() --
so it would seem that corrupt RS blocks would result in -EBADMSG being
returned from decode_rs8() (by virtue of incorrect parity being passed
to decode_rs8).

Sami (or others) am I right?
--
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/