From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KawTo-0003Tp-Tv for mharc-grub-devel@gnu.org; Wed, 03 Sep 2008 13:49:20 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KawTm-0003Tg-5v for grub-devel@gnu.org; Wed, 03 Sep 2008 13:49:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KawTh-0003TE-B3 for grub-devel@gnu.org; Wed, 03 Sep 2008 13:49:17 -0400 Received: from [199.232.76.173] (port=43771 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KawTh-0003TB-85 for grub-devel@gnu.org; Wed, 03 Sep 2008 13:49:13 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:56868 helo=jenni2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KawTg-00038M-M1 for grub-devel@gnu.org; Wed, 03 Sep 2008 13:49:13 -0400 Received: from [127.0.0.1] (88.193.32.97) by jenni2.inet.fi (8.5.014) id 489066C5019D87F8 for grub-devel@gnu.org; Wed, 3 Sep 2008 20:49:11 +0300 Message-ID: <48BECE1A.1070406@nic.fi> Date: Wed, 03 Sep 2008 20:49:14 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: The development of GRUB 2 References: <48BE5DE9.4090302@gmail.com> <20080903103654.GC29762@thorin> <48BE838E.9090204@gmail.com> <48BEC078.7030006@nic.fi> <48BEC6AD.5040305@gmail.com> In-Reply-To: <48BEC6AD.5040305@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: [RFC] Boot parameters and geometrical stability X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 17:49:18 -0000 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=E4=E4skel=E4inen