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

[Andrei Borzenkov]

14.08.2016 12:09, Thomas Schmitt пишет:
> Hi,
> 
> after having freshly re-read the specs of UEFI and RFC4122,
> here is some nitpicking:
> 
> Steve Kenton wrote:
>>>     3F2504E0-4F89-41D3-9A0C-0305E82C3301
> 
> Andrei Borzenkov wrote:
>> Usually GUIDs are displayed in lower case
> 
> RFC4122 prescribes to read them independently of case, but to produce
> them with lowercase letters.
> 
> 
>> GPT GUID are pretty well defined by UEFI spec which in turn is
>> based on RFC 4122.
> 
> UEFI 2.4 Appendix A claims to be in sync with RFC 4122. But that's
> obviously not true.
> 
> They seem to have evolved in parallel. UEFI only documents the GUID variant
> with MAC address and finely granulated timestamp, which imposes a privacy
> problem. Other sources blame Microsoft for it.
> RFC 4122 describes that variant with different endianness, a pseudo-random
> variant (which about everybody is using), and a variant with crypto-grade
> hash of user input. The abstract of RFC 4122 names Distributed Computing
> Environment by Open Software Foundation as ancestor of its definition.
> 


Randomly checking well known EFI GUID gives Variant 10 (RFC 4122) and
Version 1 (time based) or 4 (randomly generated). Appendix A does not
really tell anything about how GUIDs are actually generated. Version 1
also allows random generated content of Node field instead of MAC. So in
general it looks compliant with RFC with single deviation being byte order.

> While trying to grok the conversion from text format to binary format
> i could not reliably determine where to put the version nibble. RFC 4122
> prescribes big-endian representation of 16 bit "time_hi_and_version",
> whereas UEFI prescribes little-endian "TimeHighAndVersion".
> 

According to UEFI Appendix A it goes into 7-th byte (starting with 0) of
binary representation of EFI GUID.

> uuidgen(1) obviously follows RFC 4122.
> xorriso currently generates them UEFI style but in next release will
> cowardly waste 4 bits of entropy by writing the nibble into both bytes.
> 
> It seems that nobody interprets the entrails of GUIDs but rather everybody
> uses them as opaque byte strings.

Still we need accurate representation (simply to be able to actually
compare/search for GUIDs) and proposed option for xorriso must have
defined semantic. Currently textual representation of UUID/GUID is

uint32-uint16-uint16-rest_as_individual_bytes

So it is pretty much possible to use uuidgen, except internal
representation will differ between RFC4122 and UEFI.

> Nevertheless one has to expect byte swapping to happen when converting
> forth and back between text representation and binary representation
> by using different conversion software.
> 

We have well defined semantic, other conversion software hardly matters
here.