From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5Rh66XQb254 for ; Sun, 30 Dec 2012 10:39:49 +0100 (CET) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sun, 30 Dec 2012 10:39:46 +0100 (CET) Received: by mail-ee0-f48.google.com with SMTP id b57so5926687eek.21 for ; Sun, 30 Dec 2012 01:39:46 -0800 (PST) Message-ID: <50E00BDF.2000109@gmail.com> Date: Sun, 30 Dec 2012 10:39:43 +0100 From: Milan Broz MIME-Version: 1.0 References: <20121227095229.GA9356@tansi.org> <20121228150430.GA17491@tansi.org> <50DDF171.1080807@gmail.com> <96a12d6b77c3f72a240b489e3ceefa4a.squirrel@ssl.verfeiert.org> In-Reply-To: <96a12d6b77c3f72a240b489e3ceefa4a.squirrel@ssl.verfeiert.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: sven@whgl.uni-frankfurt.de Cc: dm-crypt@saout.de On 12/30/2012 09:42 AM, Sven Eschenberg wrote: > Hi Milan, > > What happens though, if signatures are not accessible during luksFormat? > (Or alternatively, are not found, because they are misaligned from the > current setup's perspective?) > > Scenario, create a md volume with 1.0 metadata (end of device), start md > device, do luks format. Well, there are priorities but in fact these configurations need some external info (or admin knowledge). > Now, in intial unused state, the luks header and md metadata is visible. > While cryptsetup might be able to realize that the md device should first > be started, this might not be true for all tools (unfortunately). Possible > similiar scenarions with leftover superblocks etc. can surely be created. Yes, and in the MD format (end of device) case the problem repeats very often. > I am aware this is a specific case due to the end of device policy of the > md metada v1.0. What I am trying to say is, not all cases can > automagically be resolved, sometimes the knowledge and interaction of an > admin might really be required. And for educated guessing, the admin needs > to be educated beforehand ;-). Yes, fully agree. I can mention other situations, which can be configured this way (LVM has several such undocumented scenarios) where you cannot automatically say which signature is the first... (I can write very long description about plans about "block device assembly" library under util-linux project which should help to solve this, but I am afraid that I will not work on this project anymore.) And because we are on dmcrypt list - there is always need from security (or paranoid ;) people to separate or hide metadata (e.g. LUKS header or hidden container). In this situation you simply must know some info in advance to properly activate such storage... Milan