From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sven@whgl.uni-frankfurt.de>
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 <dm-crypt@saout.de>; Wed, 10 Feb 2016 16:09:06 +0100 (CET)
Received: from p4fe854e1.dip0.t-ipconnect.de ([79.232.84.225]
 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 <sven@whgl.uni-frankfurt.de>) id 1aTWO9-0006NH-Qc
 for dm-crypt@saout.de; Wed, 10 Feb 2016 16:09:06 +0100
References: <CAFnMBaRfu93jkgmZ_vLDChF7Uv-dCE6dNN6YkSxU3EFvn8iHtg@mail.gmail.com>
 <56B20C05.7080307@gmail.com> <56B90DDD.1080107@gmail.com>
 <56BA6353.7080207@tu-ilmenau.de> <20160209233532.GB21086@tansi.org>
 <56BAF6B5.4060300@gmail.com> <56BB3FC0.5020409@whgl.uni-frankfurt.de>
 <n9fhs5$13t$1@ger.gmane.org>
From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
Message-ID: <56BB5294.8040407@whgl.uni-frankfurt.de>
Date: Wed, 10 Feb 2016 16:09:08 +0100
MIME-Version: 1.0
In-Reply-To: <n9fhs5$13t$1@ger.gmane.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] The future of disk encryption with LUKS2
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

Actually PARTUUID should have read PARTTYPE-GUID - So there's no reason 
why moving it to a different partition should not work, updating the 
PARTTYPE is a trivial step and part of a proper moving operation anyway.

Just imagine the network's linklayer had no idea which upper layer to 
call, because there's no information on that. TCP/IP again does not have 
that type of information.

So either the layering order is fixed and determined, or you actually 
will need intra-layer relationships for proper operation. As an 
alternative, leave it to the user's knowledge and handling. But then we 
don't need partition tables, LUKS-headers or anything else either, 
afterall you can tell each layer the geometry and parameters manually 
and use dmsetup for all your tasks.

Regards

-Sven

Am 10.02.2016 um 15:35 schrieb Robert Nichols:
> On 02/10/2016 07:48 AM, Sven Eschenberg wrote:
>> BTW: Personally I think that one thing in the blockdevice stack was
>> screwed up severely: Always have information on the upper layer in the
>> lower layer - That would eliminate most issues. On the lowest layer we
>> do have that information (PARTUUID/PARTTYPE), it is just mostly ignored.
>
> It's good that it's ignored.  If anything stopped working just because
> I moved a LUKS container to a different partition or device, I would
> get rid of LUKS immediately and just use plain dm-crypt.  Adding
> unnecessary inter-relationships is a _bad_ thing.
>