fdisk: add GPT partition types for plain dm-crypt and LUKS

fdisk: add GPT partition types for plain dm-crypt and LUKS

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

Hi.

Recently a discussion[0] was initiated at the dm-crypt mailing list
about whether or not to have a GPT type for it.

In the end, upstream basically agreed[1][2] to the following
definitions:
plain dm-crypt   7FFEC5C9-2D00-49B7-8941-3EA10A5586B7
LUKS partition   CA7D7CCB-63ED-4C53-861C-1742536059CC

Could you please upgrade util-linux fdisk accordingly (well at least in
case it features some list of the well-known IDs or so)?

Thanks, :-)
Chris.


[0] http://www.saout.de/pipermail/dm-crypt/2014-January/003837.html
[1] http://www.saout.de/pipermail/dm-crypt/2014-January/003855.html
[2] http://www.saout.de/pipermail/dm-crypt/2014-January/003859.html


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5165 bytes --]

Re: fdisk: add GPT partition types for plain dm-crypt and LUKS

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/28/2014 01:48 PM, Christoph Anton Mitterer wrote:
> Hi.
> 
> Recently a discussion[0] was initiated at the dm-crypt mailing
> list about whether or not to have a GPT type for it.
> 
> In the end, upstream basically agreed[1][2] to the following 
> definitions: plain dm-crypt   7FFEC5C9-2D00-49B7-8941-3EA10A5586B7 
> LUKS partition   CA7D7CCB-63ED-4C53-861C-1742536059CC

Why?  Linux doesn't use partition IDs.  Also isn't plain dm-crypt
depreciated?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS6Bm/AAoJEI5FoCIzSKrw5pIH/RNRrw1saTRL0emY+QBzjYAb
AY8Me6djgDkzQchnm5OdLQGvfDSjBy+Mrci2zEyjqGN80ceM2ugwZKvlEZnppkjc
UjeWKsLBs8AK2NT3sWDzA4Qo0iuvwYJprbjRp46BAhwiI4VHn8Pgj1ZMutgJLo/n
mjUFt1zB+P9Bs8YyhUWael6Bf0dM2M/PKrHgJDHSll3rVpHwWnZIPQ0Q19eoCxD9
ZocxIPkyPXFZPX8hzz00BBseQfYGIOC544Zi5FZzlXiiouqfAfC6nJhsp1GKZKiS
1gcQycOphugBPHqHtDR5scj0Jj+BkjTcEgjdgs3aDsQFt85ky7KOn8j1l+1u4VQ=
=DZc2
-----END PGP SIGNATURE-----

Re: fdisk: add GPT partition types for plain dm-crypt and LUKS

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On Tue, 2014-01-28 at 15:57 -0500, Phillip Susi wrote:
> Why?
Sure... some people (including myself) have pointed out arguments in the
thread over at the dm-crypt mailinglist, like:
- for plain dm-crypt it's a "good" way to make it recognisable
- partitioning tools can use it to hint what a partition contains
- and after all, partition types do exist, whether they make sense and
are used or not... and I think it's better to have some standardised
value which people may set (if they want) even if it's nowhere used,..
instead of having them set something which may actually cause issues
even if only in the future.

> Linux doesn't use partition IDs.
Phew... that's not fully true... not even for the kernel which I think
still contains the code to do MD auto assembly with 0.9 superblocks when
some MBR partition type is set...

And there are probably many tools (fdisk ;-) ) out there which some how
use or at least display the types.


> Also isn't plain dm-crypt
> depreciated?
Why should it be?


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5165 bytes --]

Re: fdisk: add GPT partition types for plain dm-crypt and LUKS

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/28/2014 04:09 PM, Christoph Anton Mitterer wrote:
> - for plain dm-crypt it's a "good" way to make it recognisable

Or use LUKS instead.

> - partitioning tools can use it to hint what a partition contains

The problem with hints is that they often tend to be wrong, which is
why Linux ignores them and goes straight to looking at what is in the
partition.

> - and after all, partition types do exist, whether they make sense
> and are used or not... and I think it's better to have some
> standardised value which people may set (if they want) even if it's
> nowhere used,.. instead of having them set something which may
> actually cause issues even if only in the future.

If it isn't used then why have it?  All it does is add confusion.

>> Linux doesn't use partition IDs.
> Phew... that's not fully true... not even for the kernel which I
> think still contains the code to do MD auto assembly with 0.9
> superblocks when some MBR partition type is set...

That's the exception and is depreciated/legacy behavior from the days
before initrd/initramfs.

> And there are probably many tools (fdisk ;-) ) out there which some
> how use or at least display the types.

Displaying useless esoteric information is useless and esoteric ;)

>> Also isn't plain dm-crypt depreciated?
> Why should it be?

For all of the reasons that LUKS was created.  In particular, the lack
of the ability to identify the thing.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS6CEPAAoJEI5FoCIzSKrw0A0IAIFc9xGVzg39lBkFGJlQAsan
diBUVDYwaxhZRcHMIkpw3QNHlPnz9XbzJGlE6BZgL3m/v3FVQ5EL/XyEnqftafBO
W2rAk+qiXvmopO9B3I+UkQhDN7z2sOXR1x59FQC2uY/Fn+mJs6dTwKS3NbQZD1Z3
wHVN0k0xWWDjFRDXZ7LIqc3Uw+XplUv4cvuM9BLWpkB8Qc2y2hxoPNiemDtuN7N3
cdGzaN/8c6I+sAclbqQpak0ElCdO/1MP3cC39S0tnTcnGPOP1F66I7RBiJFWYKIW
Q1NrjVUy090TgEEEB8AhHLWPY5BFN5m3qci0Kpq/0Yla8x80thoHnibbI98jZw0=
=GFnU
-----END PGP SIGNATURE-----

Re: fdisk: add GPT partition types for plain dm-crypt and LUKS

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

On Tue, 2014-01-28 at 16:28 -0500, Phillip Susi wrote:
> On 01/28/2014 04:09 PM, Christoph Anton Mitterer wrote:
> > - for plain dm-crypt it's a "good" way to make it recognisable
> Or use LUKS instead.
Well some people don't want to do so... whether that makes sense or
not.. is probably up to them :)


> The problem with hints is that they often tend to be wrong, which is
> why Linux ignores them and goes straight to looking at what is in the
> partition.
Sure and that's likely the best approach,... but there is not only
Linux ;-)


> If it isn't used then why have it?  All it does is add confusion.
Again... other systems may use it... there is the ID for the ESP, which
is definitely used... and you never know which other system (other OS,
bootloader) comes a long and tries to do something based on it.

Anyway.. as I said... no one is forced to use it at all... it just
sounds better to have something defined that to leave that open and have
people choose anything...

And this mail was merely to inform fdisk upstream that these values were
now "chosen".


> >> Linux doesn't use partition IDs.
> > Phew... that's not fully true... not even for the kernel which I
> > think still contains the code to do MD auto assembly with 0.9
> > superblocks when some MBR partition type is set...
> That's the exception and is depreciated/legacy behavior from the days
> before initrd/initramfs.
Well but that exception just proves my point.. that feature was
deprecated for good reason as it caused many issues... and you cannot
guarantee that no one else (e.g. outside the FLOSS world) comes along
and adds some other seemingly smart functionality... and at least one
could hope that such someone wouldn't touch any IDs which clearly don't
"belong" to him.

> >> Also isn't plain dm-crypt depreciated?
> > Why should it be?
> For all of the reasons that LUKS was created.  In particular, the lack
> of the ability to identify the thing.
Well I guess the main reason was rather to have the functionality with
key slots, and have the cipher/hash/mode/etc. stored.

Aprart from that one would usually rather try not to run around shouting
that one has an encrypted container...


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5165 bytes --]

Re: fdisk: add GPT partition types for plain dm-crypt and LUKS

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/28/2014 04:41 PM, Christoph Anton Mitterer wrote:
> Well some people don't want to do so... whether that makes sense
> or not.. is probably up to them :)

Sure, but they are just as likely to continue to be ignorant of this
type code and never use it.

> Sure and that's likely the best approach,... but there is not only 
> Linux ;-)

So are there any other operating systems that want to or already are
using these codes?

> Again... other systems may use it... there is the ID for the ESP,
> which is definitely used... and you never know which other system
> (other OS, bootloader) comes a long and tries to do something based
> on it.

The possibility that someone some day may use it isn't a good reason
to add it.  The ESP has a special ID because the UEFI standard
requires it, and that causes enough trouble as it is.

> Anyway.. as I said... no one is forced to use it at all... it just 
> sounds better to have something defined that to leave that open and
> have people choose anything...
> 
> And this mail was merely to inform fdisk upstream that these values
> were now "chosen".

Unless someone is doing the work to actually be able to use them then
I don't see any point in adding them.  I also don't see any point in a
code for LUKS, though pure a pure dm-crypt code would at least have a use.

> Well but that exception just proves my point.. that feature was 
> deprecated for good reason as it caused many issues... and you
> cannot guarantee that no one else (e.g. outside the FLOSS world)
> comes along and adds some other seemingly smart functionality...
> and at least one could hope that such someone wouldn't touch any
> IDs which clearly don't "belong" to him.

Ummm... how does it prove your point?  You admit that it was a bad
idea that caused many issues... and somehow that makes repeating the
same mistake a good idea?

> Aprart from that one would usually rather try not to run around
> shouting that one has an encrypted container...

Yet you propose doing exactly that via the partition type code.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS6FDQAAoJEI5FoCIzSKrwnHgH/35xp4IqiMtYVeoY6+B5qyZk
1aY3C3RirnPtVw9xgCWiVCX+rA/x1fyKfmu1VO7SMcyPCY0tSHMjj6S5WVgPM0g9
9PNTc6lr0EGzCcEPyFl2/VU9QNcoorUR3/hfuTzEo01klh73jHxRkIsi80qbtxA3
e5g+96h092myovWZyqrFcgYyLoXcM7VreUdIPBBKyGlDRf0WrGZTnBVZW1lo/6X8
ny35FdOlWD1zap0cMNmUDLcXF2VXA38e7thlFbDH4CiuvjoUyTZfpXr0E2f6hsf0
s/QWuCIgygD6ObYrcfMgsxdsNG9+QGfc7KIL6T0hhjDur7U4G1jYLnM0evhM0PQ=
=x1QU
-----END PGP SIGNATURE-----

Re: fdisk: add GPT partition types for plain dm-crypt and LUKS

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]

On Tue, 2014-01-28 at 19:52 -0500, Phillip Susi wrote:
> On 01/28/2014 04:41 PM, Christoph Anton Mitterer wrote:
> > Well some people don't want to do so... whether that makes sense
> > or not.. is probably up to them :)
> 
> Sure, but they are just as likely to continue to be ignorant of this
> type code and never use it.
> 
> > Sure and that's likely the best approach,... but there is not only 
> > Linux ;-)
> 
> So are there any other operating systems that want to or already are
> using these codes?
> 
> > Again... other systems may use it... there is the ID for the ESP,
> > which is definitely used... and you never know which other system
> > (other OS, bootloader) comes a long and tries to do something based
> > on it.
> 
> The possibility that someone some day may use it isn't a good reason
> to add it.  The ESP has a special ID because the UEFI standard
> requires it, and that causes enough trouble as it is.

As I've said... use it or not... :) ... this mail was just an
information which I've sent to all GPT capable open source partition
editors I knew.


> I also don't see any point in a
> code for LUKS, though pure a pure dm-crypt code would at least have a use.
Well the reason for that is simply, that I think, conceptually it would
be a bad idea to have the same code used for both, since these are
different types of "containers" (the one having the LUKS header the
other not).
Now I only a dm-crypt GPT type would have been defined, people would
have used that for LUKS as well... which is - as said - IMHO not very
clean.


> Ummm... how does it prove your point?  You admit that it was a bad
> idea that caused many issues... and somehow that makes repeating the
> same mistake a good idea?
The bad thing about 0xFD for MD auto assembly is not that there was some
type defined, but that it was used for something fragile.

Defining a GPT type for LUKS/dm-crypt is just like a placeholder-type,
so that people/tools who do set a type in any case aren't tempted to set
something stupid.


> > Aprart from that one would usually rather try not to run around
> > shouting that one has an encrypted container...
> Yet you propose doing exactly that via the partition type code.
Yeah I know... but again... one isn't forced to set it... ;-)

People also tend to use plain dm-crypt for swap... and if such partition
is wanted to be marked as plain dm-crypt... that would be the way to
go...



Anyway... guess we can stop that pointless discussion...
Some people wanted such code... whether it's useful or not is something
everybody can decide on his own... I just wanted to inform the part
editors about this, so that they can take it up in their lists of well
known types - if they want.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5165 bytes --]

Re: fdisk: add GPT partition types for plain dm-crypt and LUKS

[Davidlohr Bueso]

On Tue, 2014-01-28 at 22:09 +0100, Christoph Anton Mitterer wrote:
> On Tue, 2014-01-28 at 15:57 -0500, Phillip Susi wrote:
> > Why?
> Sure... some people (including myself) have pointed out arguments in the
> thread over at the dm-crypt mailinglist, like:
> - for plain dm-crypt it's a "good" way to make it recognisable
> - partitioning tools can use it to hint what a partition contains
> - and after all, partition types do exist, whether they make sense and
> are used or not... and I think it's better to have some standardised
> value which people may set (if they want) even if it's nowhere used,..
> instead of having them set something which may actually cause issues
> even if only in the future.
> 
> > Linux doesn't use partition IDs.
> Phew... that's not fully true... not even for the kernel which I think
> still contains the code to do MD auto assembly with 0.9 superblocks when
> some MBR partition type is set...
> 
> And there are probably many tools (fdisk ;-) ) out there which some how
> use or at least display the types.

I don't have any particular objections to this.