Re: Cryptsetup-reencrypt and data integrity.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On March 8, 2017 at 9:53 PM Michael Kjörling <michael@xxxxxxxxxxx> wrote:
>
>
> On 8 Mar 2017 20:55 +0100, from daniel@xxxxxxxxxxx:
> > I was playing with cryptsetup-reencrypt recently and I noticed it doesn't do any
> > integrity checks on re-encrypted data and there is an assumption everything went
> > fine once the command completes. Are there any plans to introduce integrity
> > checks in the future? I understanding that verifying large volumes of data would
> > be a time consuming task but lack of such option may be a show stopper for some
> > setups.
>
> How do you propose such integrity checking should be performed?
> Remember that a LUKS container may be (at least for all practical
> purposes) arbitrarily large. Also, if any inconsistencies are found,
> how should the tool respond? At that point, it's not like it can go
> back and undo (or redo) what was done.
 
There are many ways in which data can be integrity can be possibly checked, including checksums, xors of continuous blocks and others, it's certainly doable on large scale. Also, assuming we have a backup, all we'd need is the tool to tell us "oops, something went wrong, go and fix it". Per Arno's email, it's hard to argue data integrity is a huge concern to you if you don't have backups.

>
> If this is a showstopper issue for you, there is always the option of
> creating a new container and copying the data from one mapped device
> to another. (cat /dev/mapper/source > /dev/mapper/target, or more
> likely the same with something like ddrescue.) You can then check the
> data integrity in any way you like, and handle mismatches in any way
> you like.
>
> Or you can take the approach that storage is potentially unreliable
> for any number of reasons, many of which completely unrelated to LUKS,
> and use something within the container that gives you integrity
> checking and recovery capability. Redundant ZFS or Btrfs are probably
> good candidates there, but other alternatives exist.
 
Don't get me wrong, I'm not trying to lash out at LUKS for not having features not advertised in its specs and in fact my question isn't LUKS related at all, it's about cryptsetup-reencrypt only. There are environments with certain constraints, where there's no file system support (ie RHEL and zfs) or no file system exists on disk at all. I was mainly curious whether disk integrity as an additional functionality is something on the horizon for cryptsetup-reencrypt.

>
> --
> Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx
> “People who think they know everything really annoy
> those of us who know we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux