Re: dm-integrity: integrity protection device-mapper target

["Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>]

On Sat, Jan 19, 2013 at 1:16 AM, Alasdair G Kergon <agk@redhat.com> wrote:
> On Fri, Jan 18, 2013 at 11:43:34PM +0200, Kasatkin, Dmitry wrote:
>> This patch I sent out has one missing feature what I have not pushed yet.
>> In the case of non-matching blocks, it just zeros blocks and returns
>> no error (zero-on-mismatch).
>> Writing to the block replaces the hmac.
>> It works quite nicely. mkfs and fsck is able to read and write/fix the
>> filesystem.
>> In normal environment, if fsck crashes, it might corrupt file system
>> in the same way.
>> zero-on-mismatch makes block device still accessible/fixable for fsck.
>
> I'm afraid I don't buy that.
>
> We can hardly call this "integrity" if it's designed to lose some of
> your data when the machine crashes - and worse - it doesn't tell you
> what you lost, but just gives you blocks of zeroes instead!
>
> I think a redesign is needed before this goes upstream.
>
> Alasdair
>

Sorry, for re-post, but it was from mobile in HTML format and it did
not go through...

Do not look to it as integrity from reliability point of view. This
might be a wrong name for the target.
The purpose is to provide integrity from security point of view, so
modified blocks are not available.
It is to prevent attacker to put arbitrary content. This is not in
fact to provide reliability.
Default is to return an error. But returning zeroed data might be a
better option.
It works as needed for the purpose and data=journal works for this if
reliability is required.

- Dmitry