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

[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.


> 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.

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.

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.


> 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=.
      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.


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.)

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".
  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.

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.  


Have a nice day :)

Thomas