All of lore.kernel.org
 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 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.