Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Andrei Borzenkov]

14.08.2016 16:55, Thomas Schmitt пишет:
> Hi,
> 
> i wrote:
>>> i could not reliably determine where to put the version nibble.
> 
> Andrei Borzenkov wrote:
>> According to UEFI Appendix A it goes into 7-th byte (starting with 0) of
>> binary representation of EFI GUID.
> 
> And RFC 4122 with its big-endian representation puts it into byte 6.
> 

Yes, but EFI GUID is explicitly little-endian.

Here is how GRUB currently prints them (do not forget that both
platforms where EFI is currently supported are little-endian).

            grub_printf ("
%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x\n",
                         protocols[j]->data1,
                         protocols[j]->data2,
                         protocols[j]->data3,


> 
>> Currently textual representation of UUID/GUID is
>> uint32-uint16-uint16-rest_as_individual_bytes
> 
> I believe to understand that both specs prescribe the same text form
> (big endian hex) but different binary form. It may well be that it
> is meant twice swapped and thus identical ... but i know at least of
> Matthew Garrett's GPT code in isohybrid.c which would then have gotten
> it wrong.
> 

No it does not. It calls uuid_generate() from util-linux (which creates
RFC4122 big-endian binary representation) and then calls reverse_uuid()
which converts them to EFI little-endian. If you mean something
different, could you point to corresponding code please?

> In effect one simply cannot trust a GUID, which has undergone conversion
> from text to binary and/or vice versa, to bear the same byte sex in
> the first 8 bytes as the same GUID with a different conversion history.
> 

We can trust is as long as we know how it was produced and how it is
going to be used. uuidgen *command* spits out textual representation
that can be used both as RFC4122 UUID and EFI GUID and will result in
different binary content. Which is good because we can actually use
uuidgen to generate it and pass as argument to xorriso.

> One may trust that any reasonable converter applies the swapping in
> a consistent way to uint32-uint16-uint16. So there should be only one
> twin GUID resulting from conversion confusion.
>    3cd0f966-2a50-444b-b6b4-2925fe82429a
>    66f9d03c-502a-4b44-b6b4-2925fe82429a
> Some programmer could come to the idea to swap the forth component, too.
>    3cd0f966-2a50-444b-b4b6-2925fe82429a
>    66f9d03c-502a-4b44-b4b6-2925fe82429a
> 
> This all is no problem if the GUIDs in question do not have a history
> of different conversions before they get compared.
> Straight uuidgen -> xorriso -> GRUB for all GUIDs in question should
> yield an unambiguous situation.
> 

Yes; uuidgen -> xorriso -> GUID should convert textual representation to
EFI GUID. How to do *that* is exhaustively described in EFI spec. It is
responsibility of caller to ensure that passed string is valid (U|G)UID
(or may be it makes sense to do some basic sanity checks?)

> 
>> proposed option for xorriso must have defined semantic.
> 
> I decided for RFC 4122 because it matches with a plain byte string
> where the first binary byte is printed as first two hex digits.
> 
> The upcomming man page says:
> 
>   --gpt_disk_guid value
>       Control  whether  an emerging GPT shall get a randomly generated
>       disk GUID or whether the GUID is supplied by  the  user.   Value
>       "random"  is  default.  Value "modification-date" produces a low
>       quality GUID from the value set by option --modification-date=.

How? Time base UUID (Version 1) requires "node data" that is either MAC
or random bytes. You need to set those random bytes to something.

>       A string of 32 hex digits, or a RFC 4122 compliant  GUID  string
>       may be used to set the disk GUID directly.
>       E.g.  --gpt_disk_guid 2303cd2a-73c7-424a-a298-25632da7f446
>       The  partition GUIDs get generated by minimally varying the disk
>       GUID.
> 
> The upcomming libisofs API 1.4.6 clarifies on binary level:
> 
>   The partition GUIDs will be generated in a reproducible way by exoring a
>   little-endian 32 bit counter with the disk GUID beginning at byte offset 9.
> 

Not sure I follow - what counter?

> 
> xorriso and libisofs do not participate in text format speculation.
> libisofs API states about the report format of iso_image_report_system_area():
> 
>   GPT disk GUID      :      hex_digits
>        32 hex digits giving the byte string of the disk's GUID
> 
> E.g.
> 
>   GPT disk GUID      :      dea3cb6ac9ad314481d46ecc024fdcf0
> 
> No '-' means no doubt. (Actually one can just insert '-' to get RFC 4122.)
> 

No, one cannot. In the above case you /probably/ have Version 4 GUID,
but simply inserting '-' will suddenly make it Version 3. Not that it
really matters, but it will make everything even more confusing.
Explicitly showing raw binary GUID is OK.

> man xorriso encourages the reader to get the API text from
> 
>   xorriso -report_system_area help | less
> 
> by saying:
> 
>   -report_system_area mode
>        With  mode  plain  print a report about the information found in
>        the System Area of the loaded ISO image. [...]
>        With mode help print a text which explains the  meaning  of  the
>        lines  put  out  by  "plain".
>        [...]
> 
> Well, who reads the manual, anyways ...
> 
> 
> Super nitpicking (nobody cares in practice, obviously):
> 
> Andrei Borzenkov wrote:
>> Appendix A does not
>> really tell anything about how GUIDs are actually generated.
> 
> My copy of UEFI 2.4 talks of "timestamp" and "IEEE 802 address obtained
> from a network card".

My copy of 2.4 RevC still does not mention IEEE 802. Could you tell
which page (or chapter) in 2000 pages document tells this?

>   This appendix for GUID defines a 60-bit timestamp format that is used
>   to generate the GUID. [...] This time value will not roll over until the
>   year 3400 AD.
> 

This is almost direct quote from RFC4122 which also defines 60 bit
timestamp.

> I think it is perky or simply a bug to state in one single paragraph:
>   All EFI GUIDs (Globally Unique Identifiers) have the format described
>   in RFC 4122 [...]. TimeLow, TimeMid, TimeHighAndVersion fields in the
>   EFI are encoded as little endian.  
> 

Well ... one could also interpret this as "fields meaning is taken from
RFC but binary representation is different". Yes it could be more clear.