All of lore.kernel.org
 help / color / mirror / Atom feed
From: phcoder <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [RFC] Boot parameters and geometrical stability
Date: Wed, 03 Sep 2008 20:36:33 +0200	[thread overview]
Message-ID: <48BED931.2010208@gmail.com> (raw)
In-Reply-To: <48BECE1A.1070406@nic.fi>

Vesa Jääskeläinen wrote:
> 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.
> 
Yes it is, but in my opinion price is too high (shame ubuntu uses this
solution). It's somewhat similar to some solutions found in windows when
  for user convenience they open a big gate for the hackers (e.g. all
users by default are administrators in winxp)
> 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.

Yes. This is a solution found in grub legacy and I think it's a good one.
> 
> Alternative would be that you integrate some module to core that
> validates your system that there is no extra devices or such.

It's bigger since you require module and has no advantages over using
hardware names. But what we can do is to check if 2 partitions share the
same UUID and if it's the case prompt for password. The problem is that
if the same device is visible twice then it will result in a false
positive. Another solution would be to checksum modules we load. But in
this case after partial update or configuration modification a run
checksum-updater is necessary or at least user will have to enter his
password on the next boot.
> 
> Thanks,
> Vesa Jääskeläinen

Vladimir 'phcoder' Serbinenko



  reply	other threads:[~2008-09-03 18:36 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
2008-09-03 18:36           ` phcoder [this message]
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=48BED931.2010208@gmail.com \
    --to=phcoder@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.