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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
