Re: [dm-crypt] Why is it necessary to "wipe" an authenticated luks2 device when creating it?

From: Ondrej Kozina <okozina@redhat.com>
To: dm-crypt@saout.de
Cc: Robert Nichols <rnicholsNOSPAM@comcast.net>
Subject: Re: [dm-crypt] Why is it necessary to "wipe" an authenticated luks2 device when creating it?
Date: Thu, 26 Sep 2019 16:29:53 +0200	[thread overview]
Message-ID: <e69bf2d4-b2db-badb-f179-84f2499ae1ca@redhat.com> (raw)
In-Reply-To: <qmif0r$3ifq$1@blaine.gmane.org>

On 9/26/19 3:38 PM, Robert Nichols wrote:
> 
> On 9/26/19 2:41 AM, Milan Broz wrote:
>> On 25/09/2019 21:40, .. ink .. wrote:
>>> I just added an ability to create an authenticated luks2 device in
>>> zuluCrypt[1] and i am
>>> wondering why these volumes need to be wiped when created. I made it work by
>>> looking at how cryptsetup does it but i don't understand why because i
>>> have so far
>>> failed to find any documentation about it.
>>
>> I think it is explained in the referenced paper, we should add a FAQ about it.
>>
>> Initial wipe recalculates integrity tags - so you can read the device afterward.
>>
>> If you skip initialization (wipe), integrity tags for all sectors is incorrect
>> and read will return integrity failure (EILSEQ errno).
>>
>> In theory, it is not a problem ("do not read what you did not write").
>>
>> But it reality it cases many programs to fail because it can access device
>> through page cache. If the *write* is not aligned to a page, page cache tries
>> to first read content, then update content, and write it back to the device.
>>
>> But as said above, all read fails because integrity tags are not initialized,
>> thus even page-unaligned writes can fail.
>> (I have seen this problem even in programs like mkfs, where it is apparent bug.)
> 
> So, LUKS2 is incompatible with LVM thin provisioning or other sparse storage
> formats like QCOW2. Good to know.
> 

That is not correct.

First, LUKS2 does not enforce use of authenticated encryption in any 
way. It's optional choice and definitely not default (it's still 
considered experimental feature, unlike LUKS2 format that is new 
upstream default).

Contrary, if you prefer discards (trim) pass-through via dm-crypt you 
may use --persistent --allow-discards option so that it's automatically 
enabled during every following LUKS2 device activation. So it's more 
thin provisioning friendly if that is important for you (for others it 
may not be so).

Yes, authenticated encryption with dm-integrity in interleave mode does 
require device initialization for reason Milan described and moreover 
dm-integrity does not allow discards pass-through so thin provisioning 
does not make sense with it because you won't be able to reclaim free 
space from it.

O.