From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1bYxvB-0008OA-OY for mharc-grub-devel@gnu.org; Sun, 14 Aug 2016 12:05:57 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYxv8-0008Nz-QZ for grub-devel@gnu.org; Sun, 14 Aug 2016 12:05:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYxv5-00023a-I7 for grub-devel@gnu.org; Sun, 14 Aug 2016 12:05:54 -0400 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:35459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYxv5-00023U-6X for grub-devel@gnu.org; Sun, 14 Aug 2016 12:05:51 -0400 Received: by mail-wm0-x235.google.com with SMTP id f65so55084209wmi.0 for ; Sun, 14 Aug 2016 09:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=oU+rNdRcqZdJ5+MzABT/Cu9pRDrgUx9oRwNSBn2ClPY=; b=knTmJ1mljMsdAxPQIq3B31JX8L0nC1lsvvoG2DCDxHkLEWawT3hmvPvKYeobxQo91q FFEvVxbyjcShWXuo7h74XbjfE6IfbfqueUK9rAMV0eVC7GDcEhImrGnNOLpmJi4iH+1G OBW/NI45F4jYYpYmbPpGkmEHjFBGJa4MUnGNwGKgQ0JXP8u7AUdWlEfKjD8r2p4BBiHx PmKl6+aaVT2Vx+xpuXIQeYgZydEQCtQZ/gjmWsCnJhLlHFFBW+myVR7hqVt311YqwIXY YUBaGK02oYqcBhL8CRwDLHLJgpwE7WjcOxkSbnn2qlvcnMyagrRKIokfGPJnyr81KNvB hdVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oU+rNdRcqZdJ5+MzABT/Cu9pRDrgUx9oRwNSBn2ClPY=; b=mQrl5h+eYHCYuLJKl1Hcc1ONCZozfeBTh1RoEw7NEYKHfWfq97hy2NSMUVlo0Jj1dM 8woKEc2/sMb6IbnZ/+38na1Bz04Vj/wZ+ceRgggNVMQTXdn8Rdo6b95Ts+7QtESUlEqx u6a37KaUOITLHtmCk2t0ntq9zY+DVkeXl/OJillNkdNhV0G254sHg5akiQPLL1Ghy2/M HGyTjpdg0ZBEjW3OjB9Vh/8iTHCvZaLZuV9YB4TOTM5hiqawdGyMHFHELc9BXmFDJD18 +JWVwuklh9V3aU470209UKzOM5uQ5MppGy46kpw41z1ieIL5w6jJaK7OXUwwS43O4w7N XAeg== X-Gm-Message-State: AEkoouv1bGE/uXZ8rsCu8kwVJyoXNFY5HK5T4a6JYzbgYho2OOjZY85g3vbMivHseYVj8Q== X-Received: by 10.25.87.2 with SMTP id l2mr4003489lfb.170.1471190749783; Sun, 14 Aug 2016 09:05:49 -0700 (PDT) Received: from [192.168.1.43] (ppp109-252-91-231.pppoe.spdop.ru. [109.252.91.231]) by smtp.gmail.com with ESMTPSA id f40sm3082049lji.46.2016.08.14.09.05.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Aug 2016 09:05:48 -0700 (PDT) Subject: Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time To: grub-devel@gnu.org References: <194b639a-3830-4076-f485-ec699a5d188e@gmail.com> <35415886001541044910@scdbackup.webframe.org> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <6dca8c49-667c-e548-618d-2dd022e042af@gmail.com> Date: Sun, 14 Aug 2016 19:05:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <35415886001541044910@scdbackup.webframe.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::235 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 16:05:56 -0000 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.