[U-Boot] GUID/UUID string representation

[Przemyslaw Marczak]

Hello,

On 07/30/2015 01:19 PM, Palacios, Hector wrote:
> Hello,
>
> Commit d718ded056eefb6239bd2e0a57b7f6d99c6e9e4b introduced translation of UUID binary
> data to GUID string representation.
>
> So, for example, if I use the 'gpt' command to create a partition table and pass a
> 'uuid' parameter like this:
> => gpt write mmc 0
> "uuid_disk=${uuid_disk};start=2MiB,name=linux,size=64MiB,uuid=43f1961b-ce4c-4e6c-8f22-2230c5d532bd;"
>
> As a result, when I print the partition table I get:
> => part list mmc 0
>
> Partition Map for MMC device 0  --   Partition Type: EFI
>
> Part    Start LBA       End LBA         Name
>          Attributes
>          Type GUID
>          Partition GUID
>    1     0x00001000      0x00020fff      "linux"
>          attrs:  0x0000000000000000
>          type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>          guid:   1b96f143-4cce-6c4e-8f22-2230c5d532bd
>
> which prints the GUID string representation of my supplied UUID (with endian change on
> the first three parts).
>
> The command 'part uuid' (despite its name) returns this same GUID representation:
> => part uuid mmc 0
> 1b96f143-4cce-6c4e-8f22-2230c5d532bd
>
> I have some questions:
> - Why is preferred the GUID representation when listing the partition table?

Because it's defined by the specification and is the same as in the 
kernel. Please look at Apendix A of UEFI specification[1], which says 
about GUID text representation, which is simply shown in the table.
The binary format of guid is consistent with RFC4122[2], which says that 
both guid and uuid are binary equal, but different represented by text.

[1]: http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf
[2]: https://www.ietf.org/rfc/rfc4122.txt

You can check it by printing gpt with:

  'mmc part' - let's store the guids somewhere

Then mount the same disk in linux, and next do:

  'ls -lhgG /dev/disk/by-partuuid/'

You can see, that even if the name is 'by-partuuid', the ids are 
displayed as GUIDs. Probably there is a bug with the path name, since 
uuid is a reserved name for "universally unique identifier".

> - Should the 'part uuid' return the UUID representation instead of the GUID?

It returns a string representation of partition id, which is GUID text 
format.

> - Should there be a 'part uuid' and a 'part guid' commands that return the different
> representations?

I don't think so, because there is only one text format in the standard.

> - Isn't it a bit inconsistent that the 'gpt' command reads the 'uuid' parameter in
> UUID string representation and the 'part uuid' and 'part list' represent the number in
> GUID?

You're right. This is inconsistent for string comparison - we can't just 
compare the UUID string with GUID, even if the 16 bytes binary buffer is 
the same.  I don't know why GPT support was introduced with uuid names, 
we have a functions to convert it in lib/uuid.c, so additional command 
could be added - but I think cleanup is better.

>
> It may all sound as a futile discussion but in v2013.04 I had some variables to store
> the UUID numbers for my partitions that I used to generate the partition table, and
> then compared these variables with the values returned by 'part uuid' (as strings).
> Now on v2015.04 the strings do not match due to this endianness change on the
> representation.
>
> Thanks
> --
> Hector
>

Thank you for pointing this issue.

After looking into the code, I found a bug in function 
gpt_fill_header(), which converts string to GUID, but it shouldn't, 
since we pass UUID's to gpt command.

So what can we do to fix this inconsistency:

- change the variable uuid_* to guid_* in the $partitions. This is a 
string representation compatible with specification.

- update str_format argument to UUID_STR_GUID in gen_rand_uuid_str() 
calls in gpt command.

Update uuid format argument in uuid_str_to_bin() calls:
- update UUID_STR_FORMAT_STD to FORMAT_GUID in gpt_fill_pte()

- leave UUID_STR_FORMAT_GUID in gpt_fill_header() - it is bug when UUID 
is generated in gpt command.

Stephen, is that good for you?

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com