All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vesa Jääskeläinen" <chaac@nic.fi>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [RFC] Boot parameters and geometrical stability
Date: Wed, 03 Sep 2008 20:49:14 +0300	[thread overview]
Message-ID: <48BECE1A.1070406@nic.fi> (raw)
In-Reply-To: <48BEC6AD.5040305@gmail.com>

phcoder wrote:
> But consider a scenario when attacker can't overwrite the existing
> harddrive but can plug new one. Then the attacker can prepare a
> harddrive having a partition with the same UUID as our boot partition.
> Then he plugs it and depnding on factors like order of interfaces,
> devices, phase of the moon, ... GRUB can load attacker's modules. While
> it's ok to use UUID on personal desktop system when attacker can't plug
> his devices it shouldn't be the default.

That is a valid point.

Would you prefer to use hardware path to device or what you had in mind
then? Because this is something that we can left for expert people. Most
common problem is that user plugs in new drive to system and
bios/hardware order gets changed or something like that, and that
renders system unbootable. UUID is perfect solution for that case.

Possibilites are there, but basically they are limited to something like:

(ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)

I do not know if those all would be valid, but I hope you get the idea.

Alternative would be that you integrate some module to core that
validates your system that there is no extra devices or such.

Thanks,
Vesa Jääskeläinen



  reply	other threads:[~2008-09-03 17:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-03  9:50 [RFC] Boot parameters and geometrical stability phcoder
2008-09-03 10:36 ` Robert Millan
2008-09-03 12:31   ` phcoder
2008-09-03 16:51     ` Vesa Jääskeläinen
2008-09-03 17:17       ` phcoder
2008-09-03 17:49         ` Vesa Jääskeläinen [this message]
2008-09-03 18:36           ` phcoder
2008-09-03 19:07             ` Vesa Jääskeläinen
2008-09-03 19:23               ` phcoder
2008-09-04 19:37           ` Robert Millan
2008-09-04 21:40             ` phcoder
2008-09-05  9:58               ` Robert Millan
2008-09-04 19:33     ` Robert Millan
2008-09-04 21:37       ` phcoder
2008-09-05 10:05         ` Robert Millan

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=48BECE1A.1070406@nic.fi \
    --to=chaac@nic.fi \
    --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.