Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ?

Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ?

[Thomas Schmitt]

Hi,

i am discussing with Chris Lamb on reproducible-builds@lists.alioth.debian.org
how to make production of bootable ISOs reproducible. The last (yet known)
obstacle are the pseudo-random GUIDs of the GPT which is produced for EFI
bootability.

Up to this obstacle it turned out that it will suffice to use the same
input file tree and the same overall timestamp with xorriso -as mkisofs
option
  --modification-date=YYYYMMDDhhmmsscc
which was originally introduced for grub-mkrescue to match in grub.cfg
  search --fs-uuid --set YYYY-MM-DD-hh-mm-ss-cc

I am now wondering whether it would be ok for grub-mkrescue if the GUIDs
of the GPT would be derived reproducibly from this timestamp by default.
(Currently they stem from /dev/urandom.)

These GUIDs will of course be unique inside the GPT. But their entropy
will be low and collisions with other ISOs could happen systematically
because of nearly identical production times.
Well, this can happen to the ISO 9660 --fs-uuid string under the same
circumstances.


So my question:
Is there any reason known why the GPT GUID needs to have better randomness
than the "search --fs-uuid" string ?


Have a nice day :)

Thomas

Re: Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ?

[Michael Zimmermann]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

couldn't we generate GUID's based on the current git revision?
this way you reproduce the ISO without even looking at the timestamp.

I don't know anything about the entropy requirements though. Lets wait for
a reply of the maintainers about that.

Thanks
Michael

On Thu, Aug 11, 2016 at 9:55 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> i am discussing with Chris Lamb on reproducible-builds@lists.
> alioth.debian.org
> how to make production of bootable ISOs reproducible. The last (yet known)
> obstacle are the pseudo-random GUIDs of the GPT which is produced for EFI
> bootability.
>
> Up to this obstacle it turned out that it will suffice to use the same
> input file tree and the same overall timestamp with xorriso -as mkisofs
> option
>   --modification-date=YYYYMMDDhhmmsscc
> which was originally introduced for grub-mkrescue to match in grub.cfg
>   search --fs-uuid --set YYYY-MM-DD-hh-mm-ss-cc
>
> I am now wondering whether it would be ok for grub-mkrescue if the GUIDs
> of the GPT would be derived reproducibly from this timestamp by default.
> (Currently they stem from /dev/urandom.)
>
> These GUIDs will of course be unique inside the GPT. But their entropy
> will be low and collisions with other ISOs could happen systematically
> because of nearly identical production times.
> Well, this can happen to the ISO 9660 --fs-uuid string under the same
> circumstances.
>
>
> So my question:
> Is there any reason known why the GPT GUID needs to have better randomness
> than the "search --fs-uuid" string ?
>
>
> Have a nice day :)
>
> Thomas
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2462 bytes --]

Re: Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ?

[Andrei Borzenkov]

14.08.2016 08:03, Michael Zimmermann пишет:
> couldn't we generate GUID's based on the current git revision?
> this way you reproduce the ISO without even looking at the timestamp.
> 
> I don't know anything about the entropy requirements though. Lets wait for
> a reply of the maintainers about that.
> 

EFI GUIDs are compliant with RFC 4122 which means that technically
deriving GUID from e.g. http://www.gnu.org/software/grub or even simply
timestamp string is absolutely legal as well as basing GUID on "GIT hash
namespace".

For the purpose of reproducible builds I am not sure what having GUIDs
based on GIT revision buys us. It can't distinguish between different
instances of generated ISO, it cannot be traced back to GIT hash anyway.
So 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.

> Thanks
> Michael
> 
> On Thu, Aug 11, 2016 at 9:55 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:
> 
>> Hi,
>>
>> i am discussing with Chris Lamb on reproducible-builds@lists.
>> alioth.debian.org
>> how to make production of bootable ISOs reproducible. The last (yet known)
>> obstacle are the pseudo-random GUIDs of the GPT which is produced for EFI
>> bootability.
>>
>> Up to this obstacle it turned out that it will suffice to use the same
>> input file tree and the same overall timestamp with xorriso -as mkisofs
>> option
>>   --modification-date=YYYYMMDDhhmmsscc
>> which was originally introduced for grub-mkrescue to match in grub.cfg
>>   search --fs-uuid --set YYYY-MM-DD-hh-mm-ss-cc
>>
>> I am now wondering whether it would be ok for grub-mkrescue if the GUIDs
>> of the GPT would be derived reproducibly from this timestamp by default.
>> (Currently they stem from /dev/urandom.)
>>
>> These GUIDs will of course be unique inside the GPT. But their entropy
>> will be low and collisions with other ISOs could happen systematically
>> because of nearly identical production times.
>> Well, this can happen to the ISO 9660 --fs-uuid string under the same
>> circumstances.
>>
>>
>> So my question:
>> Is there any reason known why the GPT GUID needs to have better randomness
>> than the "search --fs-uuid" string ?
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ?

[Thomas Schmitt]

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