From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1bYr13-0004mU-4c for mharc-grub-devel@gnu.org; Sun, 14 Aug 2016 04:43:33 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYr0z-0004m6-US for grub-devel@gnu.org; Sun, 14 Aug 2016 04:43:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYr0w-0005Db-Pd for grub-devel@gnu.org; Sun, 14 Aug 2016 04:43:29 -0400 Received: from mout.gmx.net ([212.227.15.15]:62062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYr0w-0005CX-F2 for grub-devel@gnu.org; Sun, 14 Aug 2016 04:43:26 -0400 Received: from scdbackup.webframe.org ([91.8.173.247]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MeP5b-1bqFRU33h1-00QCYD for ; Sun, 14 Aug 2016 10:43:23 +0200 Date: Sun, 14 Aug 2016 10:44:59 +0200 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Re: Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ? Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit References: In-Reply-To: Message-Id: <21531588580023287865@scdbackup.webframe.org> X-Provags-ID: V03:K0:c4Z9DB88jWgID2cI5e4fKXLL/O1NV5ZMRtE2RY9yhBNcRBarfKm 4iN2KyO77Cj3xVjgVlMOb6VI1FSqoEt8z0lNWBhRgKgfulAIrQezRAXU9cf/csjar7t83ow jMbkyqWKkflW0An/2F+z04jd/aL7t/ncA3wMQajavXswkcJvWFf5EICgecOGldAqJMiUCvx YYfKarAkk9UcWylVczbFQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:YKq2hMaRALQ=:styOrsugr9hNYouMM9mK7t +JpOQmDO33sIhLFLx4emudKd8f9/INJXRHUKTy1g4p6pogOsVGE7fwh6nhLhkbK3GF0D/nrdj oBbi+U2PUZnRkXz4VNcYJQYV5U5O9W0QSXgZqm4LjtRQ2nmjGBaHDMn2mpJs5hvFn+AjhRjpf uhDS9yc7bqukeiEWMkiKBzGXoHxaj8nco4GeGj402vL3IPF98mnpXOvvNE0yB4F4u3dLLpeDH 7Q7gCPAZNtaVQs4elfawJkzxWNJnDHgiWr/49ZdsZpEMB3mFjNr4xQllBAFCoCRl5J+yJBx+I W1lF9fke4yxClcVmwViBkZHCmdXJtxZM0siI6mX7BkvqwQ6GsSutCgv8/Ybf25u88O4dufp42 Alo5HsksDZulhssUrEYCUZ5mKD244ElKQ5ab/GPp8DHoVF7Lrw3pLww3hqhjFAposed0FdD7U A0ueGtSJWx4wbjbqAGzkOflLP/UFoOPwXtDF7EFC+DyAjAttILVWrHFrt1JgZOvQkPP1OGWW4 nQEWZZ6s1R38SOhrOJrhLyN2i2uTdMLJKy+hWcNYZc9nEUsURQmu4LiZvnxx27yj34d9CJ1oh Y9snEmP2WmZK4WtlC2LUbDRuaQyI1WIyIUcbzw7SMTT17t2P9iaTSUPCOlQ3j4Z7D80S9KGzq HF6Zh8e2+iBnPkqNY0iHbRDHVwpKxVhp/Q390LdMA+TthM0lyh4n3qaYp74jnA/+g85+KEZiC 2RefaxRRxxTEjoDew1c5kAxl6cT4FC+yLZU9TdQbYGFOnj8sTJMJKumomR7UC+WjzXhNtCbxZ I4VTbDU X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.15 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 08:43:31 -0000 Hi, Andrei Borzenkov wrote: > as long as generated GUID has reasonable chance to be different from > any other GUID on the system where ISO was booted, it should be good. > For GRUB itself it does not matter anyway - it does not use GUID, so FS > UUID collision is worse problem. That's the decisive point i gnaw on. Vladimir decided to use the low-entropy Volume Modification Date as --fs-uuid for grub-mkrescue ISOs. I understand it uses it for finding the device from where it booted. But other than with this GRUB specific interpretation, the GPT GUIDs have a meaning after GRUB completed its work of booting. Meanwhile i found a strong reason not to rely on the low-entropy ids by default. xorriso lists the --modification-date among the -as mkisofs options which it reports about existing bootable ISOs by: xorriso -indev some_bootable.iso -report_system_area as_mkisofs These options are meant for helping to produce modified ISOs with the same boot equipment as the input ISO. So this is a use case where an ISO is not identical to its predecessor but needs to get the same --modification-date, in case GRUB is in the ISO. This leads me to the decision not to base the GPT GUIDs on --modification-date by default. So those who are not in the business of reproducible ISOs will not experience a change. For those users for whom it matters i will offer a constant option to use the modification timestamp: --gpt_disk_guid modification-date but also the option to provide an externally generated GUID which gets generated once in good quality: $ uuidgen >guid_of_iso and then re-used as often as needed and appropriate $ xorriso -as mkisofs ... --gpt_disk_guid $(cat guid_of_iso) ... -------------------------------------------------------------------------- In order to be able to create reproducible ISOs, grub-mkrescue would need an option to set a user defined modification date which overrides /* obtain date-based UUID. */ at http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n541 If EFI boot equipment is generated, the user would have to additionaly give one of above --gpt_disk_guid options as extra xorrisofs arguments. Have a nice day :) Thomas