[dm-crypt] crypetsetup and GPT partitions

Sven Eschenberg sven at whgl.uni-frankfurt.de
Fri Feb 10 16:00:31 CET 2017


<----- disk ----->

cryptsetup without any GPT or Partition likewise:

<-- cryptsetup header -- data area  --->

data area will be exported as /dev/mapper/yourname and /dev/dm-???

<--- data area --->

using parted to create a GPT on the data area (cleartext mapped device)

<--- primary GPT area ---- cleartext data ---- secondary GPT area --->

looking at the whole disk you'll have:

<--- cryptsetup header (cryptbegin)<--- primary GPT --- 'cleartext data' 
--- secondary GPT>(cryptend)>

1) As noted the kernel does not handle the GPT inside the crypto area, 
as the blockdevice is not physical (See dmesg, the kernel will read the 
GPTs on physical disks and tell you so)
2) GPTs always come with a shadow copy at the end of device with inverse 
offsetting, no matter if you use fdisk, gptfdisk or parted.

Since partitions ontop of pseudo-blockdevices are not kernel handled and 
are harder to manage, this is not recommended in general. There are very 
specific exceptions where this makes sense, esp. when you do not use 
partitions on pseudoblockdevices but volumemanagers or the like. Still, 
harder to manage, esp. when something goes utterly wrong. No fun if you 
don't know all the tools components and physical stuff very well.

Recommended and normale mode of operations will be:

<--- primary GPT --- part1<luks header --- fs> --- part2<luks header 
---- fs> --- <...> --- partN<luks header --- fs> secondary GPT --->

Advantage, once the kernel sees the physical disk, it will automagically 
create device inodes (/dev/[sh]dN). You'd then luksOpen all the N 
partitions and then mount all the filesystems. I assume CentOS uses 
crypttab, that's where the info about your crypto mappings go. Only 
disadvantage is:
You'll have to enter one passphrase per partition. If you don't like 
this, check your distribution, some of them have startup code that i.e. 
let's you use a single passphrase for a keyring which holds all the 
passwords.

As an alternative you can create a single partition create a crypto 
mapping and use lvm2 ontop of that to slice. This is however harder to 
manage, esp if you don't have the experience and using lvm2 to just 
slice a jist is a little bit like using a jackhammer on a needle.

This would roughly look like this:

<--- primary GPT --- crypto header --- <LVM header area --- LV1 <fs> --- 
LV2 <fs> ... > --- secondary GPT --->

This is quite similiar to using partition on top of the crypto 
container. Except that the tools to read a partiton table on a 
pseudoblockdevie which create the necessary mapping are usually not part 
of the core system, whereas LVM2 usually comes as part of the core 
system. The harder managability and recovery when problems arise are 
however important to consider.


Regards

-Sven

P.S.: Sorry for the limited ASCII graphics.


Am 10.02.2017 um 13:58 schrieb Houtchen, Steven:
> Thanks for the replies, but I am still a little unsure here...
> If I create the LUKS container on a whole block device, I understand it
> puts the LUKS header the beginning of the block device.  I am using GPT
> partition tables. I read that parted puts the partition at the beginning of the
> block device also
>
> I tried that scenario, and it seem sto work,,, but here are my questions here.
>
> Once I use luksFormat and luksOpen to "create and open the container", I suppose I need to
> run "parted" on the container , which the  dev/mapper device .  Is that the correct way
> to do that?  If I do that , why doesn't the GPT partition table collide with the LUKs header info
> on the block device? Does the /dev/mapper layer prevent that? Or parted?
>
> SteveH
>
>
>
> -----Original Message-----
> From: dm-crypt [mailto:dm-crypt-bounces at saout.de] On Behalf Of Sven Eschenberg
> Sent: Friday, February 10, 2017 7:35 AM
> To: dm-crypt at saout.de
> Subject: Re: [dm-crypt] crypetsetup and GPT partitions
>
> Hi,
>
> Am 08.02.2017 um 13:33 schrieb Houtchen, Steven:
>> Hello,
>>
>>
>>
>> I am trying to use "crypsetup" setup ant "parted" together.
>>
>> I want to use "cryptsetup" to encrypt a whole solid state disk,
>>
>> and then use "parted" to create partitions on it with a GPT partition
>>
>> table.  I have be able to do the first task, but not the second.
>
> Usually partitions are handled directly in the kernel which creates the inodes (well depending on the system there's udev in the equation aswell). Anyhow the kernel only looks at physical devices for that (not pseudoblockdevices like device-mapper targets etc.)
>
> That being said:
> This mode of operation is possible, but the kernel won't create blockdevice inodes for the partitions after the dm-crypt blockdevice comes up. It is possible to used specific tools like kpartx IIRC, to get additional dm targets for each of the partitions. Be reminded however, that gpt does have a secondary partition table in the end of the device, which will give you extra fun, when you scale a container holding you partitions.
>
> If you want to save time and trouble you don't want to go this route.
>>
>>
>>
>> Or vice versa. Create a few partitions, and then optionally
>>
>> encrypt each one individually. I have be able to do the first
>>
>> task, but not the second.
>
> This is the typical mode of operation as this removes some critical stuff from the equation. Usually you will create your GPT partitions and then create the cryptomapping and then the filesystems. You are free however to throw in any additional block layer as you wish.
>
>>
>>
>>
>> So my question is, is "cryptsetup" compatible with parted and
>>
>> GPT partition table? Or do  need to use something like "lvm2"
>>
>> to accomplish what I am trying to do?
>
> Yes they are compatible, you can use lvm2 if you wish, but there's no need if you don't use large scale storage with dynamic needs.
>>
>>
>>
>> I am using CentOS7 with
>>
>>
>>
>> [root at dts1 ~]# cryptsetup --version
>>
>> cryptsetup 1.6.7
>>
>> [root at dts1 ~]#
>>
>>
>>
>> [root at dts1 ~]# parted --version
>>
>> parted (GNU parted) 3.1
>>
>> Copyright (C) 2012 Free Software Foundation, Inc.
>>
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>.
>>
>> This is free software: you are free to change and redistribute it.
>>
>> There is NO WARRANTY, to the extent permitted by law.
>>
>>
>>
>> Written by
>> <http://git.debian.org/?p=parted/parted.git;a=blob_plain;f=AUTHORS>.
>>
>> [root at dts1 ~]#
>>
>>
>
> Both versions are a little outdated but should work as expected.
>
>>
>>
>>
>> Thanks for any help you can give me..
>>
>>
>>
>> *Steve Houtchen
>> *Senior Software Engineer
>>
>> *Curtiss-Wright
>> *2600 Paramount Place, Suite 200, Fairborn, OH 45324
>> T: 937.610.5420 | F: 937.252.1465
>> shoutchen at curtisswright.com <mailto:shoutchen at curtisswright.com> |
>> www.curtisswrightds.com <http://www.curtisswrightds.com/>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
> Regards
>
> -Sven
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
> _______________________________________________________________________
> This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed.  If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files.  Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries.  Documents attached hereto may contain technology subject to government export regulations.  Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations.  The recipient should check this e-mail and any attachments for the presence of viruses.  Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>


More information about the dm-crypt mailing list