From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (mail.tansi.org [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Thu, 4 Feb 2016 18:23:12 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-36-72.dclient.hispeed.ch [77.57.36.72]) by v6.tansi.org (Postfix) with ESMTPA id 5F93820DC211 for ; Thu, 4 Feb 2016 18:23:12 +0100 (CET) Date: Thu, 4 Feb 2016 18:23:11 +0100 From: Arno Wagner Message-ID: <20160204172311.GB20874@tansi.org> References: <56B20C05.7080307@gmail.com> <56B25914.5090204@whgl.uni-frankfurt.de> <56B30DE8.1060502@gmail.com> <20160204092017.GA25029@yeono.kjorling.se> <56B37D92.2030306@whgl.uni-frankfurt.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <56B37D92.2030306@whgl.uni-frankfurt.de> Subject: Re: [dm-crypt] The future of disk encryption with LUKS2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Hi Sven, if you place a copy of the header at the end, you already need some way to know where the end is and to reserve space at it. A resize could then be as simple as an additional "luksUpdateHeaderCopy" afterwards (whith all other=20 header-changing operations doing that implicitely already). For completeness and security (preventing an old copy of the header from lingering), a "luksNukeHeaderCopy" would also be required. On the other hand, resizing a Luks container with a=20 filesystem in there without killing that filesystem is already complicated enough that I usually just recomend=20 a backup and recreation instead of a resize. Regards, Arno On Thu, Feb 04, 2016 at 17:34:26 CET, Sven Eschenberg wrote: > Hi all, >=20 > Yes data duplication (a secondary shadow copy of the header) > together with checksumming for integrity checking is of course > easier and more straight forward. I thought about FEC (not > necessarily Reeed-S.) as an alternative that covers both issues > without introducing an extra location of header data. Then again, if > the (primary) header is overwritten completely, FECs won't help you > that much. >=20 > The problem with an extra header at the end of the device is, that > it makes growing/shrinking a more difficult task. Currently the > mapping always covers the whole size of the backing device. >=20 > Regards >=20 > -Sven >=20 > Am 04.02.2016 um 10:20 schrieb Michael Kj=F6rling: > >On 4 Feb 2016 09:38 +0100, from gmazyland@gmail.com (Milan Broz): > >>On 02/03/2016 08:46 PM, Sven Eschenberg wrote: > >>>Personally I'd love to see FEC extensions in a v2 on-disk-format. > >> > >>Anyway, if you have some real use cases for FEC (and specifically some > >>real-world examples of data corruption it can fix), please share it, I = am > >>very interested to see that. (I know the problem exist and that FEC cou= ld > >>be useful but seems nobody is able provide any hard data...) > > > >Plain data duplication seems both easier to implement and likely to > >allow recovery from the same as well as other classes of errors. > >Reed-Solomon and similar FEC is useful when a read is marginal, but > >useless when a read fails completely, which I believe is a far more > >common failure mode in the layers of storage that we are interested > >in. > > > >Storing the LUKS header in two separate locations on disk could > >probably do the trick. For example, right at the start *and* right at > >the end of the LUKS container, which would avoid any issues with > >having to remap a location in the middle of the container. Put a > >counter in the header, ensure that all copies are in sync when the > >header is read or written to, and if they are out of sync, use the one > >with the highest counter value that works and rewrite the other. Add a > >checksum (could be something really simple even, like CRC32, but it > >would be good to make this extensible without needing to change the > >on-disk format) to protect against any corruption that somehow manages > >to slip past the FEC in the storage layer. > > > >In fact, that would be similar to how ZFS and Btrfs already solves > >pretty much the same problem. > > > >I would discourage complex features; in cryptography, simple and easy > >to validate should be the name of the game, and simply storing the > >same data in two distinct locations is _far_ easier to understand than > >code to calculate and use FEC data. > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier