[dm-crypt] The future of disk encryption with LUKS2

Sven Eschenberg sven at whgl.uni-frankfurt.de
Mon Feb 8 01:25:31 CET 2016


I know that mdraid uses an events counter and checksum, probably Neil 
Brown could clarify on the amount of updates. Never had problems either, 
then again I think that mdraid signatures are by a magnitute smaller 
than a LUKS header (mdadm signature/header is 1 sector). The checksum of 
course is a good idea, to detect if the 'newer' header is corrupted or 
partially written.

Concerning disks, I thought with ACS2/ATA-8 real write barriers were 
introduced. On the other hand I've seen disks returning successfull 
reads with long zero-burst-errors undetected - no fun. I always wondered 
how a HDD exactly behaves when power fails, while a sector is in 
transit. My best hope is, that the CRC at the end of the sector does not 
match and an error is returned on the next read?

Regards

-Sven


Am 08.02.2016 um 00:05 schrieb Arno Wagner:
> Incidentally, this is the way Linux md-RAID checks whether
> elements are in sync on RAID assembly. I don't know how
> reliable and often md-RAID updates the counters, but I
> have not run into problems so far.
>
> For the LUKS header, a classic 2-phase commit would
> not be a problem. Disks do lie about having flushed
> buffers to disk (this world being pretty imperfect, in
> particular with regards to its inhabitants), but
> with some sensible delays that any header updates need
> anyways, this should be pretty reliable.
>
> Regards,
> Arno
>
> On Sat, Feb 06, 2016 at 20:18:02 CET, Sven Eschenberg wrote:
>> Okay, I see, for simple updates a counter could indeed be sufficient
>> to ensure consistency by bringing the header with lower counter in
>> sync with the other one.
>>
>> Regards
>>
>> -Sven
>>
>> Am 06.02.2016 um 20:09 schrieb Michael Kjörling:
>>> On 6 Feb 2016 19:56 +0100, from sven at whgl.uni-frankfurt.de (Sven Eschenberg):
>>>> Hopefully I did not miss any step and yes, it is not THAT
>>>> complicated as there is no concurrency involved, but the
>>>> transactions for resizing need to be crafted carefully.
>>>
>>> I agree, it gets more complicated when resizing a container. I was
>>> considering primarily the normal use case of a container that isn't in
>>> the process of changing its size.
>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>


More information about the dm-crypt mailing list