Discussion:
LUKS GPT GUID
Pali Rohár
2014-01-26 01:40:21 UTC
Permalink
Hello,

according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.

[1] - http://en.wikipedia.org/wiki/Partition_type
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] - http://en.wikipedia.org/wiki/GUID_Partition_Table
--
Pali Rohár
***@gmail.com
Milan Broz
2014-01-26 09:24:39 UTC
Permalink
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
Hi,

this is wonderful... who assigned E8 type? I thought LUKS has no assigned
partition type and also I doubt LVM2 type is properly assigned too
(it is probably form the LVM1 age when it was implemented in-kernel directly
and partition type was important to detect it.) But not sure about this.

Anyway, today partition type is ignored (both in LVM and LUKS), so it is really
just for convenience for other applications.
(Anyway, code should always use (lib)blkid to detect what's really on the device,
not trust partition id.)

For GPT GUID, I would like to know how these GUID codes appeared in libfdisk
and how this was standardized for LVM. LUKS should have GUID too then...
(cc to Karel as util-linux/libfdisk maintainer ;-)

If this is really used, both should be documented in LUKS specification.

Thanks,
Milan
Post by Pali Rohár
[1] - http://en.wikipedia.org/wiki/Partition_type
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] - http://en.wikipedia.org/wiki/GUID_Partition_Table
Pali Rohár
2014-01-26 10:17:11 UTC
Permalink
Post by Milan Broz
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
Hi,
this is wonderful... who assigned E8 type? I thought LUKS has no assigned
partition type and also I doubt LVM2 type is properly assigned too
(it is probably form the LVM1 age when it was implemented in-kernel directly
and partition type was important to detect it.) But not sure about this.
Anyway, today partition type is ignored (both in LVM and LUKS), so it is really
just for convenience for other applications.
(Anyway, code should always use (lib)blkid to detect what's really on the device,
not trust partition id.)
For GPT GUID, I would like to know how these GUID codes appeared in libfdisk
and how this was standardized for LVM. LUKS should have GUID too then...
(cc to Karel as util-linux/libfdisk maintainer ;-)
If this is really used, both should be documented in LUKS specification.
Thanks,
Milan
Post by Pali Rohár
[1] - http://en.wikipedia.org/wiki/Partition_type
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] - http://en.wikipedia.org/wiki/GUID_Partition_Table
I know that linux ignoring MBR partition ID and also GPT GUID.
Filesystems are detected by magic headers... But other systems (like
windows) are still using MBR partition ID and also GPT partition GUID.
So it is still good to store these information. Also if you want, you
can create udev rule to map some MBR ID/GPT GUID partition to some
name (maybe together with other information).

And who assigned E8 for LUKS? I really do not know. I thought that if
wikipedia and also other sources on internet specifing it is standard
and it is using by some applications...

Also I do not know who assigning GPT GUID for partitions. For me it
looks like application developer is choosing one GUID randomly...

CCing Roderick W. Smith, who maintaing gdisk utility. Roderick, who
and how assinged GPT GUIDs which you added to gdisk program? What do
you know about GPT GUID for LUKS?
--
Pali Rohár
***@gmail.com
Rod Smith
2014-01-26 16:02:36 UTC
Permalink
Post by Pali Rohár
CCing Roderick W. Smith, who maintaing gdisk utility. Roderick, who
and how assinged GPT GUIDs which you added to gdisk program? What do
you know about GPT GUID for LUKS?
There is no central authority or registry for GPT type code GUIDs. The
closest thing to that is probably the Wikipedia page on GPT. A
properly-constructed GUID should be unique -- at least, the statistical
probability of a collision is EXTREMELY small. Thus, anybody who wants
to can generate a GUID for a new partition type, and in fact there's
been a fair amount of that going on over the past few years. Many
computer manufacturers have manufacturer-specific GUIDs for ESP-like
partitions, for instance. As OSes adopt GPT, they also tend to add new
codes for their own use. In the Linux world, it's really up to the
parted developers and me to implement such codes, since it's libparted
and gdisk that set them. If somebody else needs a new code, they'll need
to submit patches or propose a change to me and/or the libparted
developers. (The latter is more important, really, since most Linux
installation tools rely on libparted.)

I don't know who generated most of the Linux GPT GUIDs, but I generated
the one for Linux filesystem data
(0FC63DAF-8483-4772-8E79-3D69D8477DE4). See the following mailing list
thread to get an idea of how I and the libparted developers discussed
the issue and decided to implement it:

http://lists.gnu.org/archive/html/bug-parted/2011-06/msg00026.html

The Linux /home partition type code was created by the Freedesktop.org
developers (see
http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html),
but I wasn't privy to whatever discussions led to its creation. I added
it to gdisk when I heard about it, but I haven't heard of libparted
patches to support it, so I don't know if it's really going anywhere.

In terms of gdisk, I began with the list of codes from Wikipedia's GPT
page at the time I wrote gdisk. The list on Wikipedia has expanded over
time, and I've tried to keep up. I've also added codes to gdisk from
other sources, such as when I run into a new code "in the wild" or in
source code for another project. (In most such cases, I've also added
the code to the Wikipedia page, if it's not already there.) The gdisk
parttypes.cc source code file holds all the codes that gdisk supports,
and some of those have comments with URLs to the pages that describe the
type code. You can therefore check that source code page and/or the
Wikipedia page if you have questions about specific type codes. Doing a
Web search on the code can also be informative.

As far as LUKS goes, I don't know of a Linux GPT GUID for it. If you
think it's important to implement such a code, feel free to post to the
parted mailing list. I don't think it's really important, though; Linux
ignores partition type codes for most purposes, and so long as a
partition is flagged with one of the existing Linux-specific type codes,
other OSes should ignore it.
--
Rod Smith
***@rodsbooks.com
http://www.rodsbooks.com
Christoph Anton Mitterer
2014-01-26 15:55:36 UTC
Permalink
Post by Milan Broz
For GPT GUID, I would like to know how these GUID codes appeared in libfdisk
and how this was standardized for LVM. LUKS should have GUID too then...
(cc to Karel as util-linux/libfdisk maintainer ;-)
I think it would make sense to just pick one, even though it is not
used.
At least it may be helpful in partition table managers which can then
show the type as a readable name.

So just pick one... like my /proc/sys/kernel/random/uuid suggests that
we use:
ca7d7ccb-63ed-4c53-861c-1742536059cc
;-)

We should just forward it to the developers of all known GPT partition
managers (gdisk, I guess parted,...) which makes any choice a de facto
standard.


Cheers,
Chris.
Pali Rohár
2014-01-27 10:05:29 UTC
Permalink
Post by Milan Broz
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
Frankly, who cares about partition types?
IMHO partition types make sense in firmwares like UEFI to detect boot
partition (e.g. GPT system partition) or in special cases when you
want to mark a partition for a special purpose (e.g. /home).
It's bad idea to use partition types for something else, especially
add to the partition table info about partition format (e.g. E8 for
LUKS).
Why?
It's nightmare to maintain something like this and I'm sure
that we don't want to maintain mkfs-like programs that modify
partition tables.
Of course, mkfs program should not modify partition table! Editing
parittion table then it is up to system admin (if he using mkfs) or
some high level partition program.
Post by Milan Broz
Post by Pali Rohár
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
All these are historical mistakes, I have doubts we want to contribute
to this nonsense.
BTW, do you know what is the "official" list of the partition types
for MBR according to UEFI standard? It's Brouwer's (~aeb) web page [2].
IMHO it's pretty absurd situation when official standards have to link
random hobby web pages on Internet, because there is no official
authority that main such list... I think it obvious proof that
partition types for things like LIKS, swap, ... is unofficial junk.
In my opinion, if partition table (e.g GPT) support specifing
partition label, uuid or partition type, why user/admin cannot use it
(at least for his own usage)? I think its up to admin, if he want to
use it or not. He can write own udev rules to export these information
to system /dev/ or not.
Post by Milan Broz
this is wonderful... who assigned E8 type? I thought LUKS has no assigned
partition type and also I doubt LVM2 type is properly assigned too
(it is probably form the LVM1 age when it was implemented in-kernel directly
and partition type was important to detect it.) But not sure about this.
Anyway, today partition type is ignored (both in LVM and LUKS), so it is really
just for convenience for other applications.
(Anyway, code should always use (lib)blkid to detect what's really on the device,
not trust partition id.)
For GPT GUID, I would like to know how these GUID codes appeared in libfdisk
and how this was standardized for LVM. LUKS should have GUID too then...
(cc to Karel as util-linux/libfdisk maintainer ;-)
As Rod for gfdisk, wikipedia is the first source, and then random
requests from community.
Post by Milan Broz
Post by Pali Rohár
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
Karel
--
http://karelzak.blogspot.com
--
Pali Rohár
***@gmail.com
Karel Zak
2014-01-27 10:40:02 UTC
Permalink
Post by Pali Rohár
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
Frankly, who cares about partition types?
IMHO partition types make sense in firmwares like UEFI to detect boot
partition (e.g. GPT system partition) or in special cases when you
want to mark a partition for a special purpose (e.g. /home).
It's bad idea to use partition types for something else, especially
add to the partition table info about partition format (e.g. E8 for
LUKS).
Why?
because it duplicates information and result is fragile...

It's always more robust to check /dev/sda3 then rely on partition type in
partition table.
Post by Pali Rohár
It's nightmare to maintain something like this and I'm sure
that we don't want to maintain mkfs-like programs that modify
partition tables.
Of course, mkfs program should not modify partition table! Editing
parittion table then it is up to system admin (if he using mkfs) or
some high level partition program.
but we want to have robust system and minimize complexity and
dependence on humans. So it's better to no depend on partition type by
default and use everywhere generic "data partition" than force people
to use special types for LUKS, LVM, swap, ...
Post by Pali Rohár
Post by Pali Rohár
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
All these are historical mistakes, I have doubts we want to contribute
to this nonsense.
BTW, do you know what is the "official" list of the partition types
for MBR according to UEFI standard? It's Brouwer's (~aeb) web page [2].
IMHO it's pretty absurd situation when official standards have to link
random hobby web pages on Internet, because there is no official
authority that main such list... I think it obvious proof that
partition types for things like LIKS, swap, ... is unofficial junk.
In my opinion, if partition table (e.g GPT) support specifing
partition label, uuid or partition type, why user/admin cannot use it
(at least for his own usage)?
Yes, for example partition UUID is excellent thing. I have nothing
against it.

.. but we are talking about partition types for LUKS (swap, LVM, ..).
Post by Pali Rohár
I think its up to admin, if he want to
use it or not. He can write own udev rules to export these information
to system /dev/ or not.
We already export information from PT to udev db and it's already used
in system (for example mount PARTUUID=).

All my negative notes are about partition types only.

Karel
--
Karel Zak <kzak-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
http://karelzak.blogspot.com
Pali Rohár
2014-01-27 10:49:50 UTC
Permalink
Post by Karel Zak
Post by Pali Rohár
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
Frankly, who cares about partition types?
IMHO partition types make sense in firmwares like UEFI to detect boot
partition (e.g. GPT system partition) or in special cases when you
want to mark a partition for a special purpose (e.g. /home).
It's bad idea to use partition types for something else, especially
add to the partition table info about partition format (e.g. E8 for
LUKS).
Why?
because it duplicates information and result is fragile...
It's always more robust to check /dev/sda3 then rely on partition type in
partition table.
Post by Pali Rohár
It's nightmare to maintain something like this and I'm sure
that we don't want to maintain mkfs-like programs that modify
partition tables.
Of course, mkfs program should not modify partition table! Editing
parittion table then it is up to system admin (if he using mkfs) or
some high level partition program.
but we want to have robust system and minimize complexity and
dependence on humans. So it's better to no depend on partition type by
default and use everywhere generic "data partition" than force people
to use special types for LUKS, LVM, swap, ...
Yes, by default it is better to not depend. But why force other
users/admins to not use it (if they know what are they doing)?
Post by Karel Zak
Post by Pali Rohár
Post by Pali Rohár
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
All these are historical mistakes, I have doubts we want to contribute
to this nonsense.
BTW, do you know what is the "official" list of the partition types
for MBR according to UEFI standard? It's Brouwer's (~aeb) web page [2].
IMHO it's pretty absurd situation when official standards have to link
random hobby web pages on Internet, because there is no official
authority that main such list... I think it obvious proof that
partition types for things like LIKS, swap, ... is unofficial junk.
In my opinion, if partition table (e.g GPT) support specifing
partition label, uuid or partition type, why user/admin cannot use it
(at least for his own usage)?
Yes, for example partition UUID is excellent thing. I have nothing
against it.
.. but we are talking about partition types for LUKS (swap, LVM, ..).
Post by Pali Rohár
I think its up to admin, if he want to
use it or not. He can write own udev rules to export these information
to system /dev/ or not.
We already export information from PT to udev db and it's already used
in system (for example mount PARTUUID=).
All my negative notes are about partition types only.
Ok. So why not to define partition id/guid for users/admins who want
to use it? Sure by default nobody forcing to use it, but if partition
table support to store this kind of information, why to not define id
also for luks and allow users to use it if they want?
Post by Karel Zak
Karel
--
http://karelzak.blogspot.com
--
Pali Rohár
***@gmail.com
Sven Eschenberg
2014-01-27 11:47:49 UTC
Permalink
Post by Karel Zak
Post by Pali Rohár
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition
ID
Post by Pali Rohár
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but
there
Post by Pali Rohár
is nothing on wikipedia [3] nor google... So has LUKS already
Frankly, who cares about partition types?
IMHO partition types make sense in firmwares like UEFI to detect boot
partition (e.g. GPT system partition) or in special cases when you
want to mark a partition for a special purpose (e.g. /home).
It's bad idea to use partition types for something else, especially
add to the partition table info about partition format (e.g. E8 for
LUKS).
Why?
because it duplicates information and result is fragile...
Partition IDs can be very useful in hinting though. If I want to pull a
component of a raid and move it, a list of partition IDs(or names) might
ease my administration effort. In any case it would not harm to have
additional information.
Post by Karel Zak
It's always more robust to check /dev/sda3 then rely on partition type in
partition table.
And slow. Checking all partitions for signatures can take quite some time,
if we don't talk about a handfull of them. Hinting to look in these places
first can increase the speed. And imagine there's not only say lvm and
mdadm but other raid/lvm metadata tools with own signatures and on disk
structure. A common indicator on partition level is meaningfull, as it is
independent of a concrete implementation.
Post by Karel Zak
Post by Pali Rohár
It's nightmare to maintain something like this and I'm sure
that we don't want to maintain mkfs-like programs that modify
partition tables.
Of course, mkfs program should not modify partition table! Editing
parittion table then it is up to system admin (if he using mkfs) or
some high level partition program.
but we want to have robust system and minimize complexity and
dependence on humans. So it's better to no depend on partition type by
default and use everywhere generic "data partition" than force people
to use special types for LUKS, LVM, swap, ...
While it is more complex during setup/maintanance it eases (and possibly
speeds up) operation. But that's just my POV.
Post by Karel Zak
Post by Pali Rohár
Post by Pali Rohár
preferred/assigned GUID for GPT partition table? There is already
GPT
Post by Pali Rohár
GUID for linux data, raid, swap, lvm and home partitions (see [3]),
so
Post by Pali Rohár
I think that LUKS should have GUID too.
All these are historical mistakes, I have doubts we want to contribute
to this nonsense.
BTW, do you know what is the "official" list of the partition types
for MBR according to UEFI standard? It's Brouwer's (~aeb) web page
[2].
IMHO it's pretty absurd situation when official standards have to link
random hobby web pages on Internet, because there is no official
authority that main such list... I think it obvious proof that
partition types for things like LIKS, swap, ... is unofficial junk.
In my opinion, if partition table (e.g GPT) support specifing
partition label, uuid or partition type, why user/admin cannot use it
(at least for his own usage)?
Yes, for example partition UUID is excellent thing. I have nothing
against it.
.. but we are talking about partition types for LUKS (swap, LVM, ..).
There are good reasons though. Encrypted swap has no signature, thus you'd
need a swap GUID, or use explicit PART UUID (not portable). So setting up
encrypted swaps via GUID is straight forward, while all other means need a
specific hard coding.

I assume there's more good examples ...
Post by Karel Zak
Post by Pali Rohár
I think its up to admin, if he want to
use it or not. He can write own udev rules to export these information
to system /dev/ or not.
We already export information from PT to udev db and it's already used
in system (for example mount PARTUUID=).
All my negative notes are about partition types only.
Karel
--
http://karelzak.blogspot.com
_______________________________________________
dm-crypt mailing list
http://www.saout.de/mailman/listinfo/dm-crypt
Karel Zak
2014-01-27 09:53:53 UTC
Permalink
Post by Milan Broz
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
Frankly, who cares about partition types?

IMHO partition types make sense in firmwares like UEFI to detect boot
partition (e.g. GPT system partition) or in special cases when you
want to mark a partition for a special purpose (e.g. /home).

It's bad idea to use partition types for something else, especially
add to the partition table info about partition format (e.g. E8 for
LUKS). It's nightmare to maintain something like this and I'm sure
that we don't want to maintain mkfs-like programs that modify
partition tables.
Post by Milan Broz
Post by Pali Rohár
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
All these are historical mistakes, I have doubts we want to contribute
to this nonsense.

BTW, do you know what is the "official" list of the partition types
for MBR according to UEFI standard? It's Brouwer's (~aeb) web page [2].

IMHO it's pretty absurd situation when official standards have to link
random hobby web pages on Internet, because there is no official
authority that main such list... I think it obvious proof that
partition types for things like LIKS, swap, ... is unofficial junk.
Post by Milan Broz
this is wonderful... who assigned E8 type? I thought LUKS has no assigned
partition type and also I doubt LVM2 type is properly assigned too
(it is probably form the LVM1 age when it was implemented in-kernel directly
and partition type was important to detect it.) But not sure about this.
Anyway, today partition type is ignored (both in LVM and LUKS), so it is really
just for convenience for other applications.
(Anyway, code should always use (lib)blkid to detect what's really on the device,
not trust partition id.)
For GPT GUID, I would like to know how these GUID codes appeared in libfdisk
and how this was standardized for LVM. LUKS should have GUID too then...
(cc to Karel as util-linux/libfdisk maintainer ;-)
As Rod for gfdisk, wikipedia is the first source, and then random
requests from community.
Post by Milan Broz
Post by Pali Rohár
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
Karel
--
Karel Zak <kzak-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
http://karelzak.blogspot.com
Christoph Anton Mitterer
2014-01-27 15:25:31 UTC
Permalink
Frankly, who cares about partition types?
Sure...
It's bad idea to use partition types for something else
... but,.. GPT part types are there and won't go away just because
they're mostly unused...

An I think it's actually much worse to have people set *some value*
(which may actually be used by something else in some way - since people
will not just set a random UUID, but something that their part manager
provides them from its list) than a well defined value (even if that is
never used by dm-crypt or its tools.


Moreover,... it may actually make sense for the plain dm-crypt type
(which would of course need another ID than the LUKS type), where we
have no other way to see that this is dmcrypt.

On the other hand one could argue, that this is much like the issue with
MIME types and stuff like .gz or .bz2.
The MIME-type of a gzipped PNG, e.g. image.png.gz should still be
image/gz and not something like application/x-gzip.
GZIP in that case is not a type, but an encoding.

With tar or zip it would be different, since both are not just encodings
of a file.


Now coming back to GPT UUIDs and plain dm-crypt/LUKS:

1) IMHO for LUKS it's clear - it's not like an encoding, but contains
additional stuff (all the header parts) => own GPT type


2) With plain dm-crypt one could argue that this is just an "encoding"
of something below it like "Linux FS" or "MD containter".

So one could do three things:
a) either the GPT type of encrypted partition would apply (if one
follows the principles of MIME)
b) One makes a new GPT type for each <whatever>-on-top-of<plain dmcrypt>
e.g. plainly-dmcrypted-Linux-FS, plainly-dmcrypted-MD-container, and so
on.
c) One goes the pragmatic way and makes just one single type for any
plain dm-crypt partition.


Cheers,
Chris.
Milan Broz
2014-01-27 20:41:17 UTC
Permalink
...
Post by Christoph Anton Mitterer
c) One goes the pragmatic way and makes just one single type for any
plain dm-crypt partition.
So let's define, approve (and forget about it)

"Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)"

With GUID generated (without doubt by properly seeded Christoph's RNG ;-)
ca7d7ccb-63ed-4c53-861c-1742536059cc

<fanfare>

Regards,
Milan
Christoph Anton Mitterer
2014-01-27 21:12:15 UTC
Permalink
Post by Milan Broz
"Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)"
With GUID generated (without doubt by properly seeded Christoph's RNG ;-)
ca7d7ccb-63ed-4c53-861c-1742536059cc
I think at most we should say:
LUKS or rather even
LUKS = ca7d7ccb-63ed-4c53-861c-1742536059cc
dm-crypt = 7ffec5c9-2d00-49b7-8941-3ea10a5586b7
... but especially not mix TC and loop-AES together, since dm-crypt is
not the upstream for them...


Agreed? I could pass this on then to Wikipedia, GPT fdiks and parted

Cheers,
Chris.

PS: UUIDs created with TRNG seeded Linux RNG ;-P
Milan Broz
2014-01-28 16:58:11 UTC
Permalink
Post by Christoph Anton Mitterer
Post by Milan Broz
"Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)"
With GUID generated (without doubt by properly seeded Christoph's RNG ;-)
ca7d7ccb-63ed-4c53-861c-1742536059cc
LUKS or rather even
LUKS = ca7d7ccb-63ed-4c53-861c-1742536059cc
dm-crypt = 7ffec5c9-2d00-49b7-8941-3ea10a5586b7
... but especially not mix TC and loop-AES together, since dm-crypt is
not the upstream for them...
My idea was just to use one generic encrypted partition marking, whatever
format it is...

But really, who cares? :) If you want, send it to the "upstream".

Milan
Christoph Anton Mitterer
2014-01-29 13:47:05 UTC
Permalink
Post by Milan Broz
Post by Christoph Anton Mitterer
Post by Milan Broz
"Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)"
With GUID generated (without doubt by properly seeded Christoph's RNG ;-)
ca7d7ccb-63ed-4c53-861c-1742536059cc
LUKS or rather even
LUKS = ca7d7ccb-63ed-4c53-861c-1742536059cc
dm-crypt = 7ffec5c9-2d00-49b7-8941-3ea10a5586b7
... but especially not mix TC and loop-AES together, since dm-crypt is
not the upstream for them...
My idea was just to use one generic encrypted partition marking, whatever
format it is...
Well I don't like the idea of having such kind of wildcard/group types a
lot... since it pretty much contradicts the idea of partition types,
IMHO.
Having something like "Linux Filesystem" is pretty much useless, since
then again you don't know what it actually is (even though that is of
course just a hint, and no guarantee).
Post by Milan Broz
But really, who cares? :)
Well I think that especially for plain dm-crypt it could be helpful for
tools/etc. to recognise the partition as an encrypted one, which is
otherwise not really possible.


I pushed forward these "definitions" to:
- English Wikipedia: http://en.wikipedia.org/w/index.php?title=GUID_Partition_Table&diff=592830774&oldid=592521574
- German Wikipedia: http://de.wikipedia.org/w/index.php?title=GUID_Partition_Table&diff=126967660&oldid=126000138
- GPT fdisk: http://sourceforge.net/mailarchive/message.php?msg_id=31895963
- util-linux fdisk: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/8436
- GNU parted: <wrote to their list but either it's broken or I don't know...>

Arno, could you add that perhaps to the FAQ? Stating though that right
now it's not really used and probably never will.


Cheers,
Chris.
Arno Wagner
2014-01-28 00:04:54 UTC
Permalink
Post by Milan Broz
...
Post by Christoph Anton Mitterer
c) One goes the pragmatic way and makes just one single type for any
plain dm-crypt partition.
So let's define, approve (and forget about it)
"Encrypted disk partition (LUKS, dm-crypt, TrueCrypt, loop-AES or similar)"
With GUID generated (without doubt by properly seeded Christoph's RNG ;-)
ca7d7ccb-63ed-4c53-861c-1742536059cc
<fanfare>
I approve this solution!

<applause>

Arno
Post by Milan Broz
Regards,
Milan
_______________________________________________
dm-crypt mailing list
http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno-***@public.gmane.org
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. - Plato
Arno Wagner
2014-01-26 13:18:25 UTC
Permalink
I don't think one is needed. I just use whatever is in the
LUKS container. Most are on RAID though, and there I just
use 0xfd for autodetection to get a clean, transparent
assembly process that doe snot rely on anything in user-space.
(The current Linux software RAID folks are unfortunately pretty
incompetent and completely missed the point of autodetection.
Fortunately the old, well implemented, mechanisms continue to
work.)

Arno
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
[1] - http://en.wikipedia.org/wiki/Partition_type
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] - http://en.wikipedia.org/wiki/GUID_Partition_Table
--
Pali Rohár
_______________________________________________
dm-crypt mailing list
http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno-***@public.gmane.org
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. - Plato
Pali Rohár
2014-01-31 20:56:11 UTC
Permalink
Post by Pali Rohár
Hello,
according to wikipedia [1] and other sites (e.g. [2]) MBR partition ID
for LUKS is E8. I tried to find GPT partition GUID for LUKS, but there
is nothing on wikipedia [3] nor google... So has LUKS already
preferred/assigned GUID for GPT partition table? There is already GPT
GUID for linux data, raid, swap, lvm and home partitions (see [3]), so
I think that LUKS should have GUID too.
[1] - http://en.wikipedia.org/wiki/Partition_type
[2] - http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[3] - http://en.wikipedia.org/wiki/GUID_Partition_Table
--
Pali Rohár
So what do you think? Should there be GPT GUID for LUKS defined? Or not?
--
Pali Rohár
***@gmail.com
Christoph Anton Mitterer
2014-01-31 21:32:28 UTC
Permalink
Post by Pali Rohár
So what do you think? Should there be GPT GUID for LUKS defined? Or not?
There is one now... as you can see from the later posts of that thread.

I placed it already in Wikipedia, etc.


Of course nobody really enforces anyone to use that... and there is
currently (and likely never) no place where it's really used
(technically).


Cheers,
Chris.

Loading...