All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ?
Date: Sun, 14 Aug 2016 09:29:31 +0300	[thread overview]
Message-ID: <ac45a775-3077-9b01-866d-2c2d5f2f63f2@gmail.com> (raw)
In-Reply-To: <CAN9vWDJS0-K=FF45z0jW33dMzViY55J6LQ1u6_hSg=5Ys3Upng@mail.gmail.com>

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
> 



  reply	other threads:[~2016-08-14  6:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11 19:55 Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ? Thomas Schmitt
2016-08-14  5:03 ` Michael Zimmermann
2016-08-14  6:29   ` Andrei Borzenkov [this message]
2016-08-14  8:44     ` Thomas Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac45a775-3077-9b01-866d-2c2d5f2f63f2@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.