From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mps1.wohnheimg.uni-frankfurt.de (mps1.wohnheimg.uni-frankfurt.de [141.2.118.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 4 Feb 2016 17:34:23 +0100 (CET) Received: from p4fcefefb.dip0.t-ipconnect.de ([79.206.254.251] helo=[192.168.0.11]) (Authed sender Sven 'DarKRaveR' Eschenberg) by mps1.wohnheimg.uni-frankfurt.de via ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim) (envelope-from ) id 1aRMrO-0000v7-9l for dm-crypt@saout.de; Thu, 04 Feb 2016 17:34:22 +0100 References: <56B20C05.7080307@gmail.com> <56B25914.5090204@whgl.uni-frankfurt.de> <56B30DE8.1060502@gmail.com> <20160204092017.GA25029@yeono.kjorling.se> From: Sven Eschenberg Message-ID: <56B37D92.2030306@whgl.uni-frankfurt.de> Date: Thu, 4 Feb 2016 17:34:26 +0100 MIME-Version: 1.0 In-Reply-To: <20160204092017.GA25029@yeono.kjorling.se> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit 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 all, 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. 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. Regards -Sven Am 04.02.2016 um 10:20 schrieb Michael Kjörling: > 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 could >> 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. >