grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Subject: Re: Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ?
Date: Sun, 14 Aug 2016 10:44:59 +0200	[thread overview]
Message-ID: <21531588580023287865@scdbackup.webframe.org> (raw)
In-Reply-To: <ac45a775-3077-9b01-866d-2c2d5f2f63f2@gmail.com>

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



      reply	other threads:[~2016-08-14  8:43 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
2016-08-14  8:44     ` Thomas Schmitt [this message]

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=21531588580023287865@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).