Issue with boot != root and chainloading

Issue with boot != root and chainloading

[Andy Kittner]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

Hi all,

First of all I hope I've come to the right place with my little bug 
(from what I've read this list seems to be preferred to the tracker?).

Anyway here it goes: I have two hard drives in my notebook, and tried 
installing grub (svn r1724) with it's root on the second one (/dev/sdb5 
to be precise)

    grub-install /dev/sda

Everything went smooth, however after rebooting I get dropped in rescue 
mode with this message: "unknown device fd1,5"

As I had a bit of free time I investigated where the fd1 might come 
from and it turned out that grub_root_device seems to contain a wrong 
value:

diff --git a/grub2/kern/i386/pc/init.c b/grub2/kern/i386/pc/init.c
index e47cbfd..01e8d7d 100644
--- a/grub2/kern/i386/pc/init.c
+++ b/grub2/kern/i386/pc/init.c
@@ -236,8 +236,10 @@ grub_machine_init (void)
   void
   grub_machine_set_prefix (void)
   {
+  char *prefix = make_install_device();
     /* Initialize the prefix.  */
-  grub_env_set ("prefix", make_install_device ());
+  grub_env_set ("prefix", prefix);
+  grub_printf("0x%x, 0x%x, %s\n", grub_boot_drive, grub_root_drive, prefix ? prefix : "<null>");
   }
   
   void


With this patch it prints
"0x80, 0x1, (fd1,5)/boot/grub/"
and I presume the 0x1 should actually be a 0x81, however I have no clue 
why it is wrong and as it seems to be initialized in startup.S I thought 
I'd leave it to the experts at this point. 

After:

    set prefix=(hd1,5)/boot/grub
    set root=(hd1,5)
    insmod normal
    normal

I end up in the menu and can boot my linux kernels just fine.

Now for my second problem:
If I try to chainload grub legacy on another partition it just hangs 
after printing "GRUB ". The command I used to do this was:
    chainloader (hd0,5)+1

Chainloading my windows partition using:
    chainloader (hd0,1)+1
has a similar result, namely a blank screen with a blinking cursor.

I would need some advice on how to debug this, but I guess the first 
interesting bit would be if this is broken for others as well, or just 
a peculiarity of my system.


Best regards
Andy

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Issue with boot != root and chainloading

[Pavel Roskin]

Quoting Andy Kittner <andkit@gmx.de>:

> Everything went smooth, however after rebooting I get dropped in rescue
> mode with this message: "unknown device fd1,5"

Please check your /boot/grub/device.map.  You may need to remove it  
and let grub-install regenerate it.  It would be great if you post it  
here, before and after it's regenerated.

I've seen that fd1 somewhere, but I don't remember where.  I guess  
GRUB just defaults to that value if it cannot figure out the real  
device number of the root device.

If you check the archives, you'll see that your message is greatly timed :-)

I wish we could ditch device.map completely.  However, I'll try to  
find a less radical solution for your problem.  Whether it works or  
not, it will give us insight into the real live failures of  
cross-drive installs.

> Now for my second problem:
> If I try to chainload grub legacy on another partition it just hangs
> after printing "GRUB ". The command I used to do this was:
>    chainloader (hd0,5)+1

Maybe the installation is broken?

> Chainloading my windows partition using:
>    chainloader (hd0,1)+1
> has a similar result, namely a blank screen with a blinking cursor.

There is still a chance that something is broken on those partitions,  
but please try reinstalling grub with the new device.map.

-- 
Regards,
Pavel Roskin

Re: Issue with boot != root and chainloading

[Felix Zielcke]

From: "Pavel Roskin" <proski@gnu.org>


> I've seen that fd1 somewhere, but I don't remember where.  I guess  
> GRUB just defaults to that value if it cannot figure out the real  
> device number of the root device.
> 

Maybe this Debian bug ? :)
For the reporter fd0 wasn't in device.map

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467501 

Re: Issue with boot != root and chainloading

[Andy Kittner]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

On Tue, Jul 22, 2008 at 09:50:21AM -0400, Pavel Roskin wrote:
>Quoting Andy Kittner <andkit@gmx.de>:
>
>> Everything went smooth, however after rebooting I get dropped in rescue
>> mode with this message: "unknown device fd1,5"
>
>Please check your /boot/grub/device.map.  You may need to remove it  
>and let grub-install regenerate it.  It would be great if you post it  
>here, before and after it's regenerated.

I already did an rm -rf /boot/grub before installing grub2 so so the old 
cruft wouldn't get in the way. I'll include the corresponding generated 
device.map after running grub-install:

---- grub legacy ----
(fd0)   /dev/fd0
(hd0)   /dev/sda
(hd1)   /dev/sdb
---------------------

---- grub 2 ---------
(hd0)   /dev/sda
(hd1)   /dev/sdb
---------------------

Which looks all fine for me (even better than grub-legacy where I always 
removed the spurious fd0)

>I've seen that fd1 somewhere, but I don't remember where.  I guess  
>GRUB just defaults to that value if it cannot figure out the real  
>device number of the root device.
>
>If you check the archives, you'll see that your message is greatly timed :-)

Yeah, I've seen that support for this is pretty fresh, but I thought I'd 
give it a try ;-)

>> Now for my second problem:
>> If I try to chainload grub legacy on another partition it just hangs
>> after printing "GRUB ". The command I used to do this was:
>>    chainloader (hd0,5)+1
>
>Maybe the installation is broken?
To make sure I reinstalled grub in that partition
    chainloader (hd0,5)+1

still didn't work, but:

   set root=(hd0,5)
   chainloader +1

this did. As thats basically what I did with the old grub too, I guess 
this one was my fault for not setting root correctly before firing the 
chainloader.


Thanks for the help
Andy

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Issue with boot != root and chainloading

[Pavel Roskin]

On Tue, 2008-07-22 at 16:01 +0200, Felix Zielcke wrote:
> From: "Pavel Roskin" <proski@gnu.org>
> 
> 
> > I've seen that fd1 somewhere, but I don't remember where.  I guess  
> > GRUB just defaults to that value if it cannot figure out the real  
> > device number of the root device.
> > 
> 
> Maybe this Debian bug ? :)
> For the reporter fd0 wasn't in device.map
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467501 

That's it.  The "id" field doesn't represent the BIOS ID anymore.  It's
just a sequential number now, perhaps the entry number in device.map,
not counting invalid devices.  But it's written to a field where the
bootloader expects to find a BIOS ID, such as 0x81 for the second hard
drive.

Although grub-setup correctly determines the name of the root device,
such as (hd1,1), there is no code that translates "hd1" into 0x81.  That
code was removed to allow drive names like "hd" without a number, used
on PowerPC machines.

That means that device.map support is already totally broken on i386-pc.
So few people noticed it because cross-drive installs are uncommon, and
single-drive installs rely on the boot drive supplied by BIOS.

-- 
Regards,
Pavel Roskin

Re: Issue with boot != root and chainloading

[Felix Zielcke]

From: "Felix Zielcke" <fzielcke@z-51.de>
Sent: Tuesday, July 22, 2008 4:01 PM
To: "The development of GRUB 2" <grub-devel@gnu.org>
Subject: Re: Issue with boot != root and chainloading

> From: "Pavel Roskin" <proski@gnu.org>
>
>
>> I've seen that fd1 somewhere, but I don't remember where.  I guess  GRUB just defaults to that value if it cannot figure out the 
>> real  device number of the root device.
>>
>
> Maybe this Debian bug ? :)
> For the reporter fd0 wasn't in device.map
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467501

Seems like I have to reopen that bug.
I just had grub2 failing with unknown device (fd1,1)
I have Debian sid + experimental running in VMware with ext4
Now that the 2.6.26-git* kernel has delayed allocation support and it's enabled by default
I did the same as always when playing around with ext4 and grub
Just rsync everything from sdb to sdc, poweroff, removed sdb and swaped sda and sdc in VMware,
on boot changed boot order to it boots old grub from now hd1 (so the original system I used to copy my second)
so that /dev/sda is now the new one.
and then did grub-install /dev/sda,update-grub
Just to make it clear I have 2 systems in VMware both with ext4, one I normally use and the other has only 609 MiB to copy the other 
one while it's offline
and as a rescue system if I need one :)

Then I wanted to rsync my bigger disk. So I added again a fresh sdc
powered on and booted the first time from the new set up grub2 on the freshly rsync'ed disk.
And it failed with that fd1,1

Maybe I can find out more about it.
I don't use anything special like LVM or software raid, only one partition /dev/sda1
The only special thing is ext4 and now that 2.6.26-git11 kernel

device.map only contains
(hd0) /dev/sda 

Re: Issue with boot != root and chainloading

[Felix Zielcke]

From: "Felix Zielcke" <fzielcke@z-51.de>
...

Now did the same with my other disk and it worked.
I forgot I did first the mistake grub-install /dev/sdb
which I never did before.
I'll try if I can reproduce this somehow.

the VM hasn't a floppy assigned, and I've disabled floppy disk and controller in BIOS
There are only 3 scsi disks
Maybe the problem is grub-install sdb when sdb isn't in device.map or maybe it did even happen when it was there in.
 

Re: Issue with boot != root and chainloading

[Felix Zielcke]

From: "Felix Zielcke" <fzielcke@z-51.de>


> Maybe this Debian bug ? :)
> For the reporter fd0 wasn't in device.map
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467501 
> 
> 

Sorry for my third mail, I really should think more before writing :(
sdb needs to be in device.map else grub-install luckly complains about it.
But:
I just did grub-install /dev/sdb, changed boot order in BIOS so grub from sdb gets booted
unknown device fd0,1 

Re: Issue with boot != root and chainloading

[Pavel Roskin]

On Thu, 2008-07-24 at 13:00 +0200, Felix Zielcke wrote:

> Sorry for my third mail, I really should think more before writing :(
> sdb needs to be in device.map else grub-install luckly complains about it.

grub-install always complains about device.map.  Even if it does a
single-drive install and never relies on any information in device.map,
it still asks the user to check if device.map is correct.  We should fix
it.  Users should not be constantly bugged to check the whole
device.map, only the entries GRUB was relying on, if any.

Better yet, device.map should go away, but not everyone agrees with me.

> But:
> I just did grub-install /dev/sdb, changed boot order in BIOS so grub from sdb gets booted
> unknown device fd0,1 

As I said, GRUB uses its internal ID instead of BIOS ID.  We need to fix
it.  Until it's fixed, cross-device installs are broken, even if
device.map is absolutely correct.

Let's stop discussing symptoms and start talking about the cure.

-- 
Regards,
Pavel Roskin

Re: Issue with boot != root and chainloading

[Robert Millan]

On Thu, Jul 24, 2008 at 12:49:05PM -0400, Pavel Roskin wrote:
> 
> As I said, GRUB uses its internal ID instead of BIOS ID.  We need to fix
> it.

Why not just remove that logic and use UUIDs instead?  It would also simplify
the code both in grub-setup and in kernel, maybe even make it smaller.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: Issue with boot != root and chainloading

[Pavel Roskin]

On Fri, 2008-07-25 at 23:08 +0200, Robert Millan wrote:
> On Thu, Jul 24, 2008 at 12:49:05PM -0400, Pavel Roskin wrote:
> > 
> > As I said, GRUB uses its internal ID instead of BIOS ID.  We need to fix
> > it.
> 
> Why not just remove that logic and use UUIDs instead?  It would also simplify
> the code both in grub-setup and in kernel, maybe even make it smaller.

I have no objections to that plan.  We'll need UUID search functionality
on core.img.  I understand you implemented it already.  Is it committed?
Where should we put the root UUID in core.img?

-- 
Regards,
Pavel Roskin

[PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Fri, Jul 25, 2008 at 05:47:00PM -0400, Pavel Roskin wrote:
> On Fri, 2008-07-25 at 23:08 +0200, Robert Millan wrote:
> > On Thu, Jul 24, 2008 at 12:49:05PM -0400, Pavel Roskin wrote:
> > > 
> > > As I said, GRUB uses its internal ID instead of BIOS ID.  We need to fix
> > > it.
> > 
> > Why not just remove that logic and use UUIDs instead?  It would also simplify
> > the code both in grub-setup and in kernel, maybe even make it smaller.
> 
> I have no objections to that plan.  We'll need UUID search functionality
> on core.img.  I understand you implemented it already.  Is it committed?

Yes.  There's a virtual disk in fs_uuid.mod which can be optionaly loaded in.

> Where should we put the root UUID in core.img?

In grub_prefix.  It already supports this, since it was needed for root-in-LVM
setups.

See attached patch.  I'm afraid it doesn't make kernel smaller as promised;
I expected to get rid of make_install_device() in kernel, but later noticed
that this is still needed for non-cross installs.

2008-07-26  Robert Millan  <rmh@aybabtu.com>

        * include/grub/i386/pc/kernel.h (GRUB_KERNEL_MACHINE_DATA_END):
        Increase from 0x50 to 0x60.
        * util/i386/pc/grub-install.in: Detect cross-disk installs, and
        use UUIDs to identify the root drive for them.  If that's not
        possible, abort.
        * util/i386/pc/grub-setup.c (setup): Do not special-case, or even
        check, for cross-disk installs.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

[-- Attachment #2: uuid_boot.diff --]
[-- Type: text/x-diff, Size: 4397 bytes --]

2008-07-26  Robert Millan  <rmh@aybabtu.com>

	* include/grub/i386/pc/kernel.h (GRUB_KERNEL_MACHINE_DATA_END):
	Increase from 0x50 to 0x60.
	* util/i386/pc/grub-install.in: Detect cross-disk installs, and
	use UUIDs to identify the root drive for them.  If that's not
	possible, abort.
	* util/i386/pc/grub-setup.c (setup): Do not special-case, or even
	check, for cross-disk installs.

Index: include/grub/i386/pc/kernel.h
===================================================================
--- include/grub/i386/pc/kernel.h	(revision 1733)
+++ include/grub/i386/pc/kernel.h	(working copy)
@@ -41,7 +41,7 @@
 #define GRUB_KERNEL_MACHINE_PREFIX		0x20
 
 /* End of the data section. */
-#define GRUB_KERNEL_MACHINE_DATA_END		0x50
+#define GRUB_KERNEL_MACHINE_DATA_END		0x60
 
 /* The size of the first region which won't be compressed.  */
 #if defined(ENABLE_LZO)
Index: util/i386/pc/grub-install.in
===================================================================
--- util/i386/pc/grub-install.in	(revision 1733)
+++ util/i386/pc/grub-install.in	(working copy)
@@ -233,15 +233,34 @@
 # Device abstraction module, if any (lvm, raid).
 devabstraction_module=`$grub_probe --target=abstraction --device ${grub_device}`
 
+# The order in this list is critical.  Be careful when modifying it.
+modules="$modules $fs_module $partmap_module biosdisk $devabstraction_module"
+
+prefix_drive=
 if [ "x${devabstraction_module}" = "x" ] ; then
-    prefix_drive=
+    if echo "${install_device}" | grep -qx "(.*)" ; then
+      install_drive="${install_device}"
+    else
+      install_drive="`$grub_probe --target=drive --device ${install_device}`"
+    fi
+    grub_drive="`$grub_probe --target=drive --device ${grub_device}`"
+
+    # Strip partition number
+    install_drive="`echo ${install_drive} | sed -e s/,[0-9]*//g`"
+    grub_drive="`echo ${grub_drive} | sed -e s/,[0-9]*//g`"
+    if [ "x${grub_drive}" != "x${install_drive}" ] ; then
+        uuid="`$grub_probe --target=fs_uuid --device ${grub_device}`"
+        if [ "x${uuid}" = "x" ] ; then
+          echo "You attempted a cross-disk install, but the filesystem containing ${grubdir} does not support UUIDs." 1>&2
+          exit 1
+        fi
+        prefix_drive="(UUID=${uuid})"
+        modules="$modules fs_uuid"
+    fi
 else
     prefix_drive=`$grub_probe --target=drive --device ${grub_device}`
 fi
 
-# The order in this list is critical.  Be careful when modifying it.
-modules="$modules $fs_module $partmap_module biosdisk $devabstraction_module"
-
 grub_prefix="${prefix_drive}`make_system_path_relative_to_its_root ${grubdir}`" || exit 1
 
 $grub_mkimage --output=${grubdir}/core.img --prefix=${grub_prefix}/ $modules || exit 1
Index: util/i386/pc/grub-setup.c
===================================================================
--- util/i386/pc/grub-setup.c	(revision 1733)
+++ util/i386/pc/grub-setup.c	(working copy)
@@ -339,18 +339,12 @@
 	  if (grub_disk_write (dest_dev->disk, embed_region.start, 0, core_size, core_img))
 	    grub_util_error ("%s", grub_errmsg);
 
-	  /* The boot image and the core image are on the same drive,
-	     so there is no need to specify the boot drive explicitly.  */
-	  *boot_drive = 0xff;
+	  /* FIXME: can this be skipped?  */
+	  *boot_drive = 0xFF;
+	  *root_drive = 0xFF;
+
 	  *kernel_sector = grub_cpu_to_le64 (embed_region.start);
 
-          /* If the root device is different from the destination device,
-             it is necessary to embed the root drive explicitly.  */
-          if (root_dev->disk->id != dest_dev->disk->id)
-            *root_drive = (grub_uint8_t) root_dev->disk->id;
-          else
-            *root_drive = 0xFF;
-
 	  /* Write the boot image onto the disk.  */
 	  if (grub_disk_write (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE,
 			       boot_img))
@@ -480,15 +474,8 @@
   
   *kernel_sector = grub_cpu_to_le64 (first_sector);
 
-  /* If the destination device is different from the root device,
-     it is necessary to embed the boot drive explicitly.  */
-  if (root_dev->disk->id != dest_dev->disk->id)
-    *boot_drive = (grub_uint8_t) root_dev->disk->id;
-  else
-    *boot_drive = 0xFF;
-
-  /* When the core image is not embedded, the root device always follows
-     the boot device.  */
+  /* FIXME: can this be skipped?  */
+  *boot_drive = 0xFF;
   *root_drive = 0xFF;
 
   *install_dos_part = grub_cpu_to_le32 (dos_part);

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Pavel Roskin]

On Sat, 2008-07-26 at 00:10 +0200, Robert Millan wrote:

> See attached patch.  I'm afraid it doesn't make kernel smaller as promised;
> I expected to get rid of make_install_device() in kernel, but later noticed
> that this is still needed for non-cross installs.

I like your patch.  We should try to move more logic to scripts.

As for single drive installs, we could also encode the prefix in the
text form, like "(hd0,5)/boot/grub" and obsolete the numerical partition
data.  That would make make_install_device() unnecessary.

The only problem is that we should avoid hardcoding the drive.  We need
a notation for partitions on the boot or the current drive, perhaps by
removing the drive name e.g. "(,5)/boot/grub"

We could also use UUID for single-drive installs and fallback to the
partition prefix only if UUID is unsupported or the user requests not to
use UUID.  Then it won't be a big deal if we hardcode the drive.

-- 
Regards,
Pavel Roskin

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Robert Millan]

On Fri, Jul 25, 2008 at 09:08:52PM -0400, Pavel Roskin wrote:
> 
> As for single drive installs, we could also encode the prefix in the
> text form, like "(hd0,5)/boot/grub" and obsolete the numerical partition
> data.  That would make make_install_device() unnecessary.

On single drive installs we don't encode equivalent information;  we set
some variable to 5 and some variable to -1 (or was it -2?) which basicaly
means: "partition 5, drive is the same you used to boot (and bios told
you via %dx)"

If we do that, it could happen that what we see as hd0 in userland is seen
by BIOS as 0x81 -> hd1, hence breakage.

> The only problem is that we should avoid hardcoding the drive.  We need
> a notation for partitions on the boot or the current drive, perhaps by
> removing the drive name e.g. "(,5)/boot/grub"

Ah; well, as explained above we do this already, just in a different way.

> We could also use UUID for single-drive installs and fallback to the
> partition prefix only if UUID is unsupported or the user requests not to
> use UUID.  Then it won't be a big deal if we hardcode the drive.

Based on the rest of your mail I assume the goal you're pursuing here is
deleting make_install_device().  The problem I see is that if you fallback
when UUIDs are unsupported, you still need to have the code to handle the
fallback case, even if it's rarely used.

OTOH, since UUIDs are supported in all major FSs we have, I don't think
it'd be such a big deal if we abort the install when they can't be probed.

But then, this would need to be carefuly discussed IMHO, as it's a more
radical change.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Pavel Roskin]

On Sun, 2008-07-27 at 14:19 +0200, Robert Millan wrote:

> > We could also use UUID for single-drive installs and fallback to the
> > partition prefix only if UUID is unsupported or the user requests not to
> > use UUID.  Then it won't be a big deal if we hardcode the drive.
> 
> Based on the rest of your mail I assume the goal you're pursuing here is
> deleting make_install_device().  The problem I see is that if you fallback
> when UUIDs are unsupported, you still need to have the code to handle the
> fallback case, even if it's rarely used.

You are right, I'm thinking how to get rid of make_install_device().  It
looks wrong to me that we are converting binary data to text, which will
be parsed back to the binary data.  If we want to keep the GRUB core
aware of the textual device names, we should try to avoid the
binary-to-text conversion.

But it turns out that the binary format can represent something that the
text format cannot, namely "partition N on the current drive".  I think
it's an omission, since we have representation for files on the current
partition (the drive and partition part is omitted).

I'm thinking of implementing grub-install for PowerPC.  It should work
like yaboot because that's what it will likely replace.  In means that
the hfs boot partition may be short and not mounted.  Then it would be
better to put core.img there, perhaps with a wrapper script, and put all
modules and grub.cfg to /boot/grub, which will be on a native mounted
partition.  Thus it will be necessary to specify the root partition in
core.img.  It would be nice to implement it in a platform independent
way.

> OTOH, since UUIDs are supported in all major FSs we have, I don't think
> it'd be such a big deal if we abort the install when they can't be probed.
> 
> But then, this would need to be carefuly discussed IMHO, as it's a more
> radical change.

I'm also concerned that UUID may not be unique.  For instance, a disk
was cloned, and a filesystem of the clone was modified without changing
the UUID.

-- 
Regards,
Pavel Roskin

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Robert Millan]

Aside from the discussion about removing / refurbishing make_install_device(),
is everybody ok with what this patch does?

If I don't hear any objections I'll commit it soon.

On Sat, Jul 26, 2008 at 12:10:50AM +0200, Robert Millan wrote:
> 2008-07-26  Robert Millan  <rmh@aybabtu.com>
> 
> 	* include/grub/i386/pc/kernel.h (GRUB_KERNEL_MACHINE_DATA_END):
> 	Increase from 0x50 to 0x60.
> 	* util/i386/pc/grub-install.in: Detect cross-disk installs, and
> 	use UUIDs to identify the root drive for them.  If that's not
> 	possible, abort.
> 	* util/i386/pc/grub-setup.c (setup): Do not special-case, or even
> 	check, for cross-disk installs.
> 
> Index: include/grub/i386/pc/kernel.h
> ===================================================================
> --- include/grub/i386/pc/kernel.h	(revision 1733)
> +++ include/grub/i386/pc/kernel.h	(working copy)
> @@ -41,7 +41,7 @@
>  #define GRUB_KERNEL_MACHINE_PREFIX		0x20
>  
>  /* End of the data section. */
> -#define GRUB_KERNEL_MACHINE_DATA_END		0x50
> +#define GRUB_KERNEL_MACHINE_DATA_END		0x60
>  
>  /* The size of the first region which won't be compressed.  */
>  #if defined(ENABLE_LZO)
> Index: util/i386/pc/grub-install.in
> ===================================================================
> --- util/i386/pc/grub-install.in	(revision 1733)
> +++ util/i386/pc/grub-install.in	(working copy)
> @@ -233,15 +233,34 @@
>  # Device abstraction module, if any (lvm, raid).
>  devabstraction_module=`$grub_probe --target=abstraction --device ${grub_device}`
>  
> +# The order in this list is critical.  Be careful when modifying it.
> +modules="$modules $fs_module $partmap_module biosdisk $devabstraction_module"
> +
> +prefix_drive=
>  if [ "x${devabstraction_module}" = "x" ] ; then
> -    prefix_drive=
> +    if echo "${install_device}" | grep -qx "(.*)" ; then
> +      install_drive="${install_device}"
> +    else
> +      install_drive="`$grub_probe --target=drive --device ${install_device}`"
> +    fi
> +    grub_drive="`$grub_probe --target=drive --device ${grub_device}`"
> +
> +    # Strip partition number
> +    install_drive="`echo ${install_drive} | sed -e s/,[0-9]*//g`"
> +    grub_drive="`echo ${grub_drive} | sed -e s/,[0-9]*//g`"
> +    if [ "x${grub_drive}" != "x${install_drive}" ] ; then
> +        uuid="`$grub_probe --target=fs_uuid --device ${grub_device}`"
> +        if [ "x${uuid}" = "x" ] ; then
> +          echo "You attempted a cross-disk install, but the filesystem containing ${grubdir} does not support UUIDs." 1>&2
> +          exit 1
> +        fi
> +        prefix_drive="(UUID=${uuid})"
> +        modules="$modules fs_uuid"
> +    fi
>  else
>      prefix_drive=`$grub_probe --target=drive --device ${grub_device}`
>  fi
>  
> -# The order in this list is critical.  Be careful when modifying it.
> -modules="$modules $fs_module $partmap_module biosdisk $devabstraction_module"
> -
>  grub_prefix="${prefix_drive}`make_system_path_relative_to_its_root ${grubdir}`" || exit 1
>  
>  $grub_mkimage --output=${grubdir}/core.img --prefix=${grub_prefix}/ $modules || exit 1
> Index: util/i386/pc/grub-setup.c
> ===================================================================
> --- util/i386/pc/grub-setup.c	(revision 1733)
> +++ util/i386/pc/grub-setup.c	(working copy)
> @@ -339,18 +339,12 @@
>  	  if (grub_disk_write (dest_dev->disk, embed_region.start, 0, core_size, core_img))
>  	    grub_util_error ("%s", grub_errmsg);
>  
> -	  /* The boot image and the core image are on the same drive,
> -	     so there is no need to specify the boot drive explicitly.  */
> -	  *boot_drive = 0xff;
> +	  /* FIXME: can this be skipped?  */
> +	  *boot_drive = 0xFF;
> +	  *root_drive = 0xFF;
> +
>  	  *kernel_sector = grub_cpu_to_le64 (embed_region.start);
>  
> -          /* If the root device is different from the destination device,
> -             it is necessary to embed the root drive explicitly.  */
> -          if (root_dev->disk->id != dest_dev->disk->id)
> -            *root_drive = (grub_uint8_t) root_dev->disk->id;
> -          else
> -            *root_drive = 0xFF;
> -
>  	  /* Write the boot image onto the disk.  */
>  	  if (grub_disk_write (dest_dev->disk, 0, 0, GRUB_DISK_SECTOR_SIZE,
>  			       boot_img))
> @@ -480,15 +474,8 @@
>    
>    *kernel_sector = grub_cpu_to_le64 (first_sector);
>  
> -  /* If the destination device is different from the root device,
> -     it is necessary to embed the boot drive explicitly.  */
> -  if (root_dev->disk->id != dest_dev->disk->id)
> -    *boot_drive = (grub_uint8_t) root_dev->disk->id;
> -  else
> -    *boot_drive = 0xFF;
> -
> -  /* When the core image is not embedded, the root device always follows
> -     the boot device.  */
> +  /* FIXME: can this be skipped?  */
> +  *boot_drive = 0xFF;
>    *root_drive = 0xFF;
>  
>    *install_dos_part = grub_cpu_to_le32 (dos_part);

> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Robert Millan]

On Sun, Jul 27, 2008 at 12:29:43PM -0400, Pavel Roskin wrote:
> On Sun, 2008-07-27 at 14:19 +0200, Robert Millan wrote:
> 
> > > We could also use UUID for single-drive installs and fallback to the
> > > partition prefix only if UUID is unsupported or the user requests not to
> > > use UUID.  Then it won't be a big deal if we hardcode the drive.
> > 
> > Based on the rest of your mail I assume the goal you're pursuing here is
> > deleting make_install_device().  The problem I see is that if you fallback
> > when UUIDs are unsupported, you still need to have the code to handle the
> > fallback case, even if it's rarely used.
> 
> You are right, I'm thinking how to get rid of make_install_device().  It
> looks wrong to me that we are converting binary data to text, which will
> be parsed back to the binary data.  If we want to keep the GRUB core
> aware of the textual device names, we should try to avoid the
> binary-to-text conversion.
> 
> But it turns out that the binary format can represent something that the
> text format cannot, namely "partition N on the current drive".  I think
> it's an omission, since we have representation for files on the current
> partition (the drive and partition part is omitted).

Perhaps we are over-engineering a bit here.  In the long run, maybe it makes
more sense to always use UUIDs and drop the make_install_device() complexity.

This is AFAICS the only way we can use our own disk drivers.  If we were to
use e.g. ata.mod in the core image, we'd have no way to tell what BIOS (or
EFI, or Coreboot [1]) means by "disk 1".

[1] but of course, Coreboot doesn't even bother about disks.  The Coreboot
    use case is interesting though, because using your own driver is the only
    option.

> I'm thinking of implementing grub-install for PowerPC.

Did you notice util/ieee1275/grub-install.in?  :-)

> It should work
> like yaboot because that's what it will likely replace.

I'm not satisfied with the current user interface of that script, but I
couldn't think of any better way to do it back then.  If you can improve
it that'd be much welcome.

Btw, I'm currently working on adding --prefix / uuid support to our
ieee1275 ports.  I'll send a patch RSN.

> > OTOH, since UUIDs are supported in all major FSs we have, I don't think
> > it'd be such a big deal if we abort the install when they can't be probed.
> > 
> > But then, this would need to be carefuly discussed IMHO, as it's a more
> > radical change.
> 
> I'm also concerned that UUID may not be unique.  For instance, a disk
> was cloned, and a filesystem of the clone was modified without changing
> the UUID.

I think in the long term the solution to that is that cloning software
becomes UUID-aware and picks the right option between generating or copying
the UUIDs (of course, the right option could just be what the user says!
but this is outside of our scope ;-)).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

UUID boot on ieee1275 (Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading))

[Robert Millan]

On Sun, Jul 27, 2008 at 08:37:37PM +0200, Robert Millan wrote:
> I'm not satisfied with the current user interface of that script, but I
> couldn't think of any better way to do it back then.  If you can improve
> it that'd be much welcome.
> 
> Btw, I'm currently working on adding --prefix / uuid support to our
> ieee1275 ports.  I'll send a patch RSN.

Here it is.  For powerpc it'd need some adjustment to start.S.  Unfortunately
my patch appears to uncover a memory corruption problem somewhere else, which
I haven't managed to track down yet.

But I'd still like to know if it works on other setups.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] UUID boot on ieee1275 (Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading))

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

On Sun, Jul 27, 2008 at 09:28:58PM +0200, Robert Millan wrote:
> On Sun, Jul 27, 2008 at 08:37:37PM +0200, Robert Millan wrote:
> > I'm not satisfied with the current user interface of that script, but I
> > couldn't think of any better way to do it back then.  If you can improve
> > it that'd be much welcome.
> > 
> > Btw, I'm currently working on adding --prefix / uuid support to our
> > ieee1275 ports.  I'll send a patch RSN.
> 
> Here it is.  For powerpc it'd need some adjustment to start.S.  Unfortunately
> my patch appears to uncover a memory corruption problem somewhere else, which
> I haven't managed to track down yet.
> 
> But I'd still like to know if it works on other setups.

OTOH, if --prefix is used to override prefix to a value that is not of
the '(UUID=xxx)' form, it works just fine.

So I'm submitting a patch that implements --prefix, without having grub-install
use it.  This is useful already (for manual installs), and I'd like to use that
--prefix option for Coreboot later too.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

[-- Attachment #2: ofw_uuid.diff --]
[-- Type: text/x-diff, Size: 5984 bytes --]

2008-07-27  Robert Millan  <rmh@aybabtu.com>

	* kern/ieee1275/init.c (grub_machine_set_prefix): If `grub_prefix'
	is non-empty, use it to set the `prefix' environment variable instead
	of the usual approach.

	* kern/i386/ieee1275/startup.S: Include `<grub/machine/kernel.h>'.
	(start): Insert a data section, with `grub_prefix' variable.

	* include/grub/powerpc/ieee1275/kernel.h [!ASM_FILE] (grub_prefix):
	New variable reference.

	* include/grub/i386/ieee1275/kernel.h (GRUB_KERNEL_MACHINE_PREFIX):
	New macro.  Defines offset of `grub_prefix' within startup.S (relative
	to `start').
	(GRUB_KERNEL_MACHINE_DATA_END): New macro.  Defines the end of data
	section within startup.S (relative to `start').

	* util/elf/grub-mkimage.c (add_segments): Receive `prefix' parameter.
	Overwrite grub_prefix with its contents, at the beginning of the
	first segment.
	(main): Understand -p|--prefix.

Index: kern/ieee1275/init.c
===================================================================
--- kern/ieee1275/init.c	(revision 1734)
+++ kern/ieee1275/init.c	(working copy)
@@ -84,6 +84,13 @@
     /* We already set prefix in grub_machine_init().  */
     return;
 
+  if (grub_prefix[0])
+    {
+      grub_env_set ("prefix", grub_prefix);
+      /* Prefix is hardcoded in kernel.elf.  */
+      return;
+    }
+
   if (grub_ieee1275_get_property (grub_ieee1275_chosen, "bootpath", &bootpath,
 				  sizeof (bootpath), 0))
     {
Index: kern/i386/ieee1275/startup.S
===================================================================
--- kern/i386/ieee1275/startup.S	(revision 1734)
+++ kern/i386/ieee1275/startup.S	(working copy)
@@ -19,6 +19,7 @@
 #define ASM_FILE	1
 
 #include <grub/symbol.h>
+#include <grub/machine/kernel.h>
 #include <grub/machine/memory.h>
 #include <grub/cpu/linux.h>
 #include <multiboot.h>
@@ -38,6 +39,24 @@
 
 start:
 _start:
+	jmp codestart
+
+	/*
+	 *  This is a special data area at a fixed offset from the beginning.
+	 */
+
+	. = EXT_C(start) + GRUB_KERNEL_MACHINE_PREFIX
+
+VARIABLE(grub_prefix)
+	/* to be filled by grub-mkimage */
+
+	/*
+	 *  Leave some breathing room for the prefix.
+	 */
+
+	. = EXT_C(start) + GRUB_KERNEL_MACHINE_DATA_END
+
+codestart:
 	movl %eax, EXT_C(grub_ieee1275_entry_fn)
 	jmp EXT_C(grub_main)
 
Index: include/grub/powerpc/ieee1275/kernel.h
===================================================================
--- include/grub/powerpc/ieee1275/kernel.h	(revision 1734)
+++ include/grub/powerpc/ieee1275/kernel.h	(working copy)
@@ -28,7 +28,15 @@
    rewrite grub-mkimage to generate valid ELF files.  */
 #define GRUB_MOD_GAP 0x8000
 
+#ifndef ASM_FILE
+
 void EXPORT_FUNC (grub_reboot) (void);
 void EXPORT_FUNC (grub_halt) (void);
 
+/* The prefix which points to the directory where GRUB modules and its
+   configuration file are located.  */
+extern char grub_prefix[];
+
+#endif
+
 #endif /* ! GRUB_KERNEL_MACHINE_HEADER */
Index: include/grub/i386/ieee1275/kernel.h
===================================================================
--- include/grub/i386/ieee1275/kernel.h	(revision 1734)
+++ include/grub/i386/ieee1275/kernel.h	(working copy)
@@ -1 +1,4 @@
 #include <grub/powerpc/ieee1275/kernel.h>
+
+#define GRUB_KERNEL_MACHINE_PREFIX	0x2
+#define GRUB_KERNEL_MACHINE_DATA_END	0x42
Index: util/elf/grub-mkimage.c
===================================================================
--- util/elf/grub-mkimage.c	(revision 1734)
+++ util/elf/grub-mkimage.c	(working copy)
@@ -158,7 +158,7 @@
 }
 
 void
-add_segments (char *dir, FILE *out, int chrp, char *mods[])
+add_segments (char *dir, char *prefix, FILE *out, int chrp, char *mods[])
 {
   Elf32_Ehdr ehdr;
   Elf32_Phdr *phdrs = NULL;
@@ -166,7 +166,7 @@
   FILE *in;
   char *kernel_path;
   grub_addr_t grub_end = 0;
-  off_t offset;
+  off_t offset, first_segment;
   int i, phdr_size;
 
   /* Read ELF header.  */
@@ -192,6 +192,8 @@
   phdrs = xmalloc (phdr_size);
   offset += ALIGN_UP (phdr_size, GRUB_TARGET_SIZEOF_LONG);
 
+  first_segment = offset;
+
   /* Copy all existing segments.  */
   for (i = 0; i < grub_target_to_host16 (ehdr.e_phnum); i++)
     {
@@ -272,6 +274,13 @@
   /* Write ELF header.  */
   grub_util_write_image_at (&ehdr, sizeof (ehdr), 0, out);
 
+  if (prefix)
+    {
+      if (GRUB_KERNEL_MACHINE_PREFIX + strlen (prefix) + 1 > GRUB_KERNEL_MACHINE_DATA_END)
+        grub_util_error ("prefix too long");
+      grub_util_write_image_at (prefix, strlen (prefix) + 1, first_segment + GRUB_KERNEL_MACHINE_PREFIX, out);
+    }
+
   free (phdrs);
   free (kernel_path);
 }
@@ -279,6 +288,7 @@
 static struct option options[] =
   {
     {"directory", required_argument, 0, 'd'},
+    {"prefix", required_argument, 0, 'p'},
     {"output", required_argument, 0, 'o'},
     {"help", no_argument, 0, 'h'},
     {"note", no_argument, 0, 'n'},
@@ -299,6 +309,7 @@
 Make a bootable image of GRUB.\n\
 \n\
 -d, --directory=DIR     use images and modules under DIR [default=%s]\n\
+-p, --prefix=DIR        set grub_prefix directory\n\
 -o, --output=FILE       output a generated image to FILE\n\
 -h, --help              display this message and exit\n\
 -n, --note              add NOTE segment for CHRP Open Firmware\n\
@@ -317,13 +328,14 @@
   FILE *fp;
   char *output = NULL;
   char *dir = NULL;
+  char *prefix = NULL;
   int chrp = 0;
 
   progname = "grub-mkimage";
 
   while (1)
     {
-      int c = getopt_long (argc, argv, "d:o:hVvn", options, 0);
+      int c = getopt_long (argc, argv, "d:p:o:hVvn", options, 0);
       if (c == -1)
 	break;
 
@@ -334,6 +346,11 @@
 	      free (dir);
 	    dir = xstrdup (optarg);
 	    break;
+	  case 'p':
+	    if (prefix)
+	      free (prefix);
+	    prefix = xstrdup (optarg);
+	    break;
 	  case 'h':
 	    usage (0);
 	    break;
@@ -364,7 +381,7 @@
   if (! fp)
     grub_util_error ("cannot open %s", output);
 
-  add_segments (dir ? : GRUB_LIBDIR, fp, chrp, argv + optind);
+  add_segments (dir ? : GRUB_LIBDIR, prefix, fp, chrp, argv + optind);
 
   fclose (fp);
 

Re: [PATCH] UUID boot on ieee1275 (Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading))

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Sun, Jul 27, 2008 at 10:13:19PM +0200, Robert Millan wrote:
> 
> So I'm submitting a patch that implements --prefix, without having grub-install
> use it.  This is useful already (for manual installs), and I'd like to use that
> --prefix option for Coreboot later too.

Here's a combined patch which also implements --prefix for Coreboot (and on
Coreboot it's the only option for automated boot we provide so far).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

[-- Attachment #2: elf_prefix.diff --]
[-- Type: text/x-diff, Size: 8366 bytes --]

2008-07-27  Robert Millan  <rmh@aybabtu.com>

	* kern/ieee1275/init.c (grub_machine_set_prefix): If `grub_prefix'
	is non-empty, use it to set the `prefix' environment variable instead
	of the usual approach.
	* kern/i386/linuxbios/init.c (make_install_device): Remove function.
	(grub_machine_set_prefix): Use `grub_prefix' to set the `prefix'
	environment variable instead of dummy make_install_device().

	* kern/i386/ieee1275/startup.S: Include `<grub/machine/kernel.h>'.
	(start): Insert a data section, with `grub_prefix' variable.
        * kern/i386/linuxbios/startup.S: Likewise.

	* include/grub/powerpc/ieee1275/kernel.h [!ASM_FILE] (grub_prefix):
	New variable reference.
	* include/grub/i386/ieee1275/kernel.h (GRUB_KERNEL_MACHINE_PREFIX):
	New macro.  Defines offset of `grub_prefix' within startup.S (relative
	to `start').
	(GRUB_KERNEL_MACHINE_DATA_END): New macro.  Defines the end of data
	section within startup.S (relative to `start').
	* include/grub/i386/coreboot/kernel.h: Likewise.

	* util/elf/grub-mkimage.c (add_segments): Receive `prefix' parameter.
	Overwrite grub_prefix with its contents, at the beginning of the
	first segment.
	(main): Understand -p|--prefix.

Index: kern/ieee1275/init.c
===================================================================
--- kern/ieee1275/init.c	(revision 1734)
+++ kern/ieee1275/init.c	(working copy)
@@ -84,6 +84,13 @@
     /* We already set prefix in grub_machine_init().  */
     return;
 
+  if (grub_prefix[0])
+    {
+      grub_env_set ("prefix", grub_prefix);
+      /* Prefix is hardcoded in kernel.elf.  */
+      return;
+    }
+
   if (grub_ieee1275_get_property (grub_ieee1275_chosen, "bootpath", &bootpath,
 				  sizeof (bootpath), 0))
     {
Index: kern/i386/ieee1275/startup.S
===================================================================
--- kern/i386/ieee1275/startup.S	(revision 1734)
+++ kern/i386/ieee1275/startup.S	(working copy)
@@ -19,6 +19,7 @@
 #define ASM_FILE	1
 
 #include <grub/symbol.h>
+#include <grub/machine/kernel.h>
 #include <grub/machine/memory.h>
 #include <grub/cpu/linux.h>
 #include <multiboot.h>
@@ -38,6 +39,24 @@
 
 start:
 _start:
+	jmp codestart
+
+	/*
+	 *  This is a special data area at a fixed offset from the beginning.
+	 */
+
+	. = EXT_C(start) + GRUB_KERNEL_MACHINE_PREFIX
+
+VARIABLE(grub_prefix)
+	/* to be filled by grub-mkimage */
+
+	/*
+	 *  Leave some breathing room for the prefix.
+	 */
+
+	. = EXT_C(start) + GRUB_KERNEL_MACHINE_DATA_END
+
+codestart:
 	movl %eax, EXT_C(grub_ieee1275_entry_fn)
 	jmp EXT_C(grub_main)
 
Index: kern/i386/linuxbios/startup.S
===================================================================
--- kern/i386/linuxbios/startup.S	(revision 1734)
+++ kern/i386/linuxbios/startup.S	(working copy)
@@ -19,6 +19,7 @@
 #define ASM_FILE	1
 
 #include <grub/symbol.h>
+#include <grub/machine/kernel.h>
 #include <grub/machine/memory.h>
 #include <grub/cpu/linux.h>
 #include <multiboot.h>
@@ -35,7 +36,25 @@
 	.file	"startup.S"
 	.text
 	.globl	start, _start
+start:
+_start:
+	jmp codestart
 
+	/*
+	 *  This is a special data area at a fixed offset from the beginning.
+	 */
+
+	. = EXT_C(start) + GRUB_KERNEL_MACHINE_PREFIX
+
+VARIABLE(grub_prefix)
+	/* to be filled by grub-mkimage */
+
+	/*
+	 *  Leave some breathing room for the prefix.
+	 */
+
+	. = EXT_C(start) + GRUB_KERNEL_MACHINE_DATA_END
+
 #if 0
 /*
  *  Support for booting GRUB from a Multiboot boot loader (e.g. GRUB itself).
@@ -49,8 +68,7 @@
 	.long	-0x1BADB002
 #endif
 
-start:
-_start:
+codestart:
 	/* initialize the stack */
 	movl $GRUB_MEMORY_MACHINE_PROT_STACK, %esp
 
Index: kern/i386/linuxbios/init.c
===================================================================
--- kern/i386/linuxbios/init.c	(revision 1734)
+++ kern/i386/linuxbios/init.c	(working copy)
@@ -78,12 +78,6 @@
 {
 }
 
-static char *
-make_install_device (void)
-{
-  return NULL;
-}
-
 void
 grub_machine_init (void)
 {
@@ -155,7 +149,7 @@
 grub_machine_set_prefix (void)
 {
   /* Initialize the prefix.  */
-  grub_env_set ("prefix", make_install_device ());
+  grub_env_set ("prefix", grub_prefix);
 }
 
 void
Index: include/grub/powerpc/ieee1275/kernel.h
===================================================================
--- include/grub/powerpc/ieee1275/kernel.h	(revision 1734)
+++ include/grub/powerpc/ieee1275/kernel.h	(working copy)
@@ -28,7 +28,15 @@
    rewrite grub-mkimage to generate valid ELF files.  */
 #define GRUB_MOD_GAP 0x8000
 
+#ifndef ASM_FILE
+
 void EXPORT_FUNC (grub_reboot) (void);
 void EXPORT_FUNC (grub_halt) (void);
 
+/* The prefix which points to the directory where GRUB modules and its
+   configuration file are located.  */
+extern char grub_prefix[];
+
+#endif
+
 #endif /* ! GRUB_KERNEL_MACHINE_HEADER */
Index: include/grub/i386/ieee1275/kernel.h
===================================================================
--- include/grub/i386/ieee1275/kernel.h	(revision 1734)
+++ include/grub/i386/ieee1275/kernel.h	(working copy)
@@ -1 +1,4 @@
 #include <grub/powerpc/ieee1275/kernel.h>
+
+#define GRUB_KERNEL_MACHINE_PREFIX	0x2
+#define GRUB_KERNEL_MACHINE_DATA_END	0x42
Index: include/grub/i386/coreboot/kernel.h
===================================================================
--- include/grub/i386/coreboot/kernel.h	(revision 1734)
+++ include/grub/i386/coreboot/kernel.h	(working copy)
@@ -26,4 +26,11 @@
 /* Non-zero value is only needed for some IEEE-1275 platforms.  */
 #define GRUB_MOD_GAP 0
 
+#ifndef ASM_FILE
+extern char grub_prefix[];
+#endif
+
+#define GRUB_KERNEL_MACHINE_PREFIX	0x2
+#define GRUB_KERNEL_MACHINE_DATA_END	0x42
+
 #endif /* ! GRUB_KERNEL_MACHINE_HEADER */
Index: util/elf/grub-mkimage.c
===================================================================
--- util/elf/grub-mkimage.c	(revision 1734)
+++ util/elf/grub-mkimage.c	(working copy)
@@ -158,7 +158,7 @@
 }
 
 void
-add_segments (char *dir, FILE *out, int chrp, char *mods[])
+add_segments (char *dir, char *prefix, FILE *out, int chrp, char *mods[])
 {
   Elf32_Ehdr ehdr;
   Elf32_Phdr *phdrs = NULL;
@@ -166,7 +166,7 @@
   FILE *in;
   char *kernel_path;
   grub_addr_t grub_end = 0;
-  off_t offset;
+  off_t offset, first_segment;
   int i, phdr_size;
 
   /* Read ELF header.  */
@@ -192,6 +192,8 @@
   phdrs = xmalloc (phdr_size);
   offset += ALIGN_UP (phdr_size, GRUB_TARGET_SIZEOF_LONG);
 
+  first_segment = offset;
+
   /* Copy all existing segments.  */
   for (i = 0; i < grub_target_to_host16 (ehdr.e_phnum); i++)
     {
@@ -272,6 +274,13 @@
   /* Write ELF header.  */
   grub_util_write_image_at (&ehdr, sizeof (ehdr), 0, out);
 
+  if (prefix)
+    {
+      if (GRUB_KERNEL_MACHINE_PREFIX + strlen (prefix) + 1 > GRUB_KERNEL_MACHINE_DATA_END)
+        grub_util_error ("prefix too long");
+      grub_util_write_image_at (prefix, strlen (prefix) + 1, first_segment + GRUB_KERNEL_MACHINE_PREFIX, out);
+    }
+
   free (phdrs);
   free (kernel_path);
 }
@@ -279,6 +288,7 @@
 static struct option options[] =
   {
     {"directory", required_argument, 0, 'd'},
+    {"prefix", required_argument, 0, 'p'},
     {"output", required_argument, 0, 'o'},
     {"help", no_argument, 0, 'h'},
     {"note", no_argument, 0, 'n'},
@@ -299,6 +309,7 @@
 Make a bootable image of GRUB.\n\
 \n\
 -d, --directory=DIR     use images and modules under DIR [default=%s]\n\
+-p, --prefix=DIR        set grub_prefix directory\n\
 -o, --output=FILE       output a generated image to FILE\n\
 -h, --help              display this message and exit\n\
 -n, --note              add NOTE segment for CHRP Open Firmware\n\
@@ -317,13 +328,14 @@
   FILE *fp;
   char *output = NULL;
   char *dir = NULL;
+  char *prefix = NULL;
   int chrp = 0;
 
   progname = "grub-mkimage";
 
   while (1)
     {
-      int c = getopt_long (argc, argv, "d:o:hVvn", options, 0);
+      int c = getopt_long (argc, argv, "d:p:o:hVvn", options, 0);
       if (c == -1)
 	break;
 
@@ -334,6 +346,11 @@
 	      free (dir);
 	    dir = xstrdup (optarg);
 	    break;
+	  case 'p':
+	    if (prefix)
+	      free (prefix);
+	    prefix = xstrdup (optarg);
+	    break;
 	  case 'h':
 	    usage (0);
 	    break;
@@ -364,7 +381,7 @@
   if (! fp)
     grub_util_error ("cannot open %s", output);
 
-  add_segments (dir ? : GRUB_LIBDIR, fp, chrp, argv + optind);
+  add_segments (dir ? : GRUB_LIBDIR, prefix, fp, chrp, argv + optind);
 
   fclose (fp);
 

Re: [PATCH] UUID boot on ieee1275 (Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading))

[Robert Millan]

Committed.

On Sun, Jul 27, 2008 at 10:36:35PM +0200, Robert Millan wrote:
> On Sun, Jul 27, 2008 at 10:13:19PM +0200, Robert Millan wrote:
> > 
> > So I'm submitting a patch that implements --prefix, without having grub-install
> > use it.  This is useful already (for manual installs), and I'd like to use that
> > --prefix option for Coreboot later too.
> 
> Here's a combined patch which also implements --prefix for Coreboot (and on
> Coreboot it's the only option for automated boot we provide so far).
> 
> -- 
> Robert Millan
> 
> <GPLv2> I know my rights; I want my phone call!
> <DRM> What good is a phone call… if you are unable to speak?
> (as seen on /.)

> 2008-07-27  Robert Millan  <rmh@aybabtu.com>
> 
> 	* kern/ieee1275/init.c (grub_machine_set_prefix): If `grub_prefix'
> 	is non-empty, use it to set the `prefix' environment variable instead
> 	of the usual approach.
> 	* kern/i386/linuxbios/init.c (make_install_device): Remove function.
> 	(grub_machine_set_prefix): Use `grub_prefix' to set the `prefix'
> 	environment variable instead of dummy make_install_device().
> 
> 	* kern/i386/ieee1275/startup.S: Include `<grub/machine/kernel.h>'.
> 	(start): Insert a data section, with `grub_prefix' variable.
>         * kern/i386/linuxbios/startup.S: Likewise.
> 
> 	* include/grub/powerpc/ieee1275/kernel.h [!ASM_FILE] (grub_prefix):
> 	New variable reference.
> 	* include/grub/i386/ieee1275/kernel.h (GRUB_KERNEL_MACHINE_PREFIX):
> 	New macro.  Defines offset of `grub_prefix' within startup.S (relative
> 	to `start').
> 	(GRUB_KERNEL_MACHINE_DATA_END): New macro.  Defines the end of data
> 	section within startup.S (relative to `start').
> 	* include/grub/i386/coreboot/kernel.h: Likewise.
> 
> 	* util/elf/grub-mkimage.c (add_segments): Receive `prefix' parameter.
> 	Overwrite grub_prefix with its contents, at the beginning of the
> 	first segment.
> 	(main): Understand -p|--prefix.
> 
> Index: kern/ieee1275/init.c
> ===================================================================
> --- kern/ieee1275/init.c	(revision 1734)
> +++ kern/ieee1275/init.c	(working copy)
> @@ -84,6 +84,13 @@
>      /* We already set prefix in grub_machine_init().  */
>      return;
>  
> +  if (grub_prefix[0])
> +    {
> +      grub_env_set ("prefix", grub_prefix);
> +      /* Prefix is hardcoded in kernel.elf.  */
> +      return;
> +    }
> +
>    if (grub_ieee1275_get_property (grub_ieee1275_chosen, "bootpath", &bootpath,
>  				  sizeof (bootpath), 0))
>      {
> Index: kern/i386/ieee1275/startup.S
> ===================================================================
> --- kern/i386/ieee1275/startup.S	(revision 1734)
> +++ kern/i386/ieee1275/startup.S	(working copy)
> @@ -19,6 +19,7 @@
>  #define ASM_FILE	1
>  
>  #include <grub/symbol.h>
> +#include <grub/machine/kernel.h>
>  #include <grub/machine/memory.h>
>  #include <grub/cpu/linux.h>
>  #include <multiboot.h>
> @@ -38,6 +39,24 @@
>  
>  start:
>  _start:
> +	jmp codestart
> +
> +	/*
> +	 *  This is a special data area at a fixed offset from the beginning.
> +	 */
> +
> +	. = EXT_C(start) + GRUB_KERNEL_MACHINE_PREFIX
> +
> +VARIABLE(grub_prefix)
> +	/* to be filled by grub-mkimage */
> +
> +	/*
> +	 *  Leave some breathing room for the prefix.
> +	 */
> +
> +	. = EXT_C(start) + GRUB_KERNEL_MACHINE_DATA_END
> +
> +codestart:
>  	movl %eax, EXT_C(grub_ieee1275_entry_fn)
>  	jmp EXT_C(grub_main)
>  
> Index: kern/i386/linuxbios/startup.S
> ===================================================================
> --- kern/i386/linuxbios/startup.S	(revision 1734)
> +++ kern/i386/linuxbios/startup.S	(working copy)
> @@ -19,6 +19,7 @@
>  #define ASM_FILE	1
>  
>  #include <grub/symbol.h>
> +#include <grub/machine/kernel.h>
>  #include <grub/machine/memory.h>
>  #include <grub/cpu/linux.h>
>  #include <multiboot.h>
> @@ -35,7 +36,25 @@
>  	.file	"startup.S"
>  	.text
>  	.globl	start, _start
> +start:
> +_start:
> +	jmp codestart
>  
> +	/*
> +	 *  This is a special data area at a fixed offset from the beginning.
> +	 */
> +
> +	. = EXT_C(start) + GRUB_KERNEL_MACHINE_PREFIX
> +
> +VARIABLE(grub_prefix)
> +	/* to be filled by grub-mkimage */
> +
> +	/*
> +	 *  Leave some breathing room for the prefix.
> +	 */
> +
> +	. = EXT_C(start) + GRUB_KERNEL_MACHINE_DATA_END
> +
>  #if 0
>  /*
>   *  Support for booting GRUB from a Multiboot boot loader (e.g. GRUB itself).
> @@ -49,8 +68,7 @@
>  	.long	-0x1BADB002
>  #endif
>  
> -start:
> -_start:
> +codestart:
>  	/* initialize the stack */
>  	movl $GRUB_MEMORY_MACHINE_PROT_STACK, %esp
>  
> Index: kern/i386/linuxbios/init.c
> ===================================================================
> --- kern/i386/linuxbios/init.c	(revision 1734)
> +++ kern/i386/linuxbios/init.c	(working copy)
> @@ -78,12 +78,6 @@
>  {
>  }
>  
> -static char *
> -make_install_device (void)
> -{
> -  return NULL;
> -}
> -
>  void
>  grub_machine_init (void)
>  {
> @@ -155,7 +149,7 @@
>  grub_machine_set_prefix (void)
>  {
>    /* Initialize the prefix.  */
> -  grub_env_set ("prefix", make_install_device ());
> +  grub_env_set ("prefix", grub_prefix);
>  }
>  
>  void
> Index: include/grub/powerpc/ieee1275/kernel.h
> ===================================================================
> --- include/grub/powerpc/ieee1275/kernel.h	(revision 1734)
> +++ include/grub/powerpc/ieee1275/kernel.h	(working copy)
> @@ -28,7 +28,15 @@
>     rewrite grub-mkimage to generate valid ELF files.  */
>  #define GRUB_MOD_GAP 0x8000
>  
> +#ifndef ASM_FILE
> +
>  void EXPORT_FUNC (grub_reboot) (void);
>  void EXPORT_FUNC (grub_halt) (void);
>  
> +/* The prefix which points to the directory where GRUB modules and its
> +   configuration file are located.  */
> +extern char grub_prefix[];
> +
> +#endif
> +
>  #endif /* ! GRUB_KERNEL_MACHINE_HEADER */
> Index: include/grub/i386/ieee1275/kernel.h
> ===================================================================
> --- include/grub/i386/ieee1275/kernel.h	(revision 1734)
> +++ include/grub/i386/ieee1275/kernel.h	(working copy)
> @@ -1 +1,4 @@
>  #include <grub/powerpc/ieee1275/kernel.h>
> +
> +#define GRUB_KERNEL_MACHINE_PREFIX	0x2
> +#define GRUB_KERNEL_MACHINE_DATA_END	0x42
> Index: include/grub/i386/coreboot/kernel.h
> ===================================================================
> --- include/grub/i386/coreboot/kernel.h	(revision 1734)
> +++ include/grub/i386/coreboot/kernel.h	(working copy)
> @@ -26,4 +26,11 @@
>  /* Non-zero value is only needed for some IEEE-1275 platforms.  */
>  #define GRUB_MOD_GAP 0
>  
> +#ifndef ASM_FILE
> +extern char grub_prefix[];
> +#endif
> +
> +#define GRUB_KERNEL_MACHINE_PREFIX	0x2
> +#define GRUB_KERNEL_MACHINE_DATA_END	0x42
> +
>  #endif /* ! GRUB_KERNEL_MACHINE_HEADER */
> Index: util/elf/grub-mkimage.c
> ===================================================================
> --- util/elf/grub-mkimage.c	(revision 1734)
> +++ util/elf/grub-mkimage.c	(working copy)
> @@ -158,7 +158,7 @@
>  }
>  
>  void
> -add_segments (char *dir, FILE *out, int chrp, char *mods[])
> +add_segments (char *dir, char *prefix, FILE *out, int chrp, char *mods[])
>  {
>    Elf32_Ehdr ehdr;
>    Elf32_Phdr *phdrs = NULL;
> @@ -166,7 +166,7 @@
>    FILE *in;
>    char *kernel_path;
>    grub_addr_t grub_end = 0;
> -  off_t offset;
> +  off_t offset, first_segment;
>    int i, phdr_size;
>  
>    /* Read ELF header.  */
> @@ -192,6 +192,8 @@
>    phdrs = xmalloc (phdr_size);
>    offset += ALIGN_UP (phdr_size, GRUB_TARGET_SIZEOF_LONG);
>  
> +  first_segment = offset;
> +
>    /* Copy all existing segments.  */
>    for (i = 0; i < grub_target_to_host16 (ehdr.e_phnum); i++)
>      {
> @@ -272,6 +274,13 @@
>    /* Write ELF header.  */
>    grub_util_write_image_at (&ehdr, sizeof (ehdr), 0, out);
>  
> +  if (prefix)
> +    {
> +      if (GRUB_KERNEL_MACHINE_PREFIX + strlen (prefix) + 1 > GRUB_KERNEL_MACHINE_DATA_END)
> +        grub_util_error ("prefix too long");
> +      grub_util_write_image_at (prefix, strlen (prefix) + 1, first_segment + GRUB_KERNEL_MACHINE_PREFIX, out);
> +    }
> +
>    free (phdrs);
>    free (kernel_path);
>  }
> @@ -279,6 +288,7 @@
>  static struct option options[] =
>    {
>      {"directory", required_argument, 0, 'd'},
> +    {"prefix", required_argument, 0, 'p'},
>      {"output", required_argument, 0, 'o'},
>      {"help", no_argument, 0, 'h'},
>      {"note", no_argument, 0, 'n'},
> @@ -299,6 +309,7 @@
>  Make a bootable image of GRUB.\n\
>  \n\
>  -d, --directory=DIR     use images and modules under DIR [default=%s]\n\
> +-p, --prefix=DIR        set grub_prefix directory\n\
>  -o, --output=FILE       output a generated image to FILE\n\
>  -h, --help              display this message and exit\n\
>  -n, --note              add NOTE segment for CHRP Open Firmware\n\
> @@ -317,13 +328,14 @@
>    FILE *fp;
>    char *output = NULL;
>    char *dir = NULL;
> +  char *prefix = NULL;
>    int chrp = 0;
>  
>    progname = "grub-mkimage";
>  
>    while (1)
>      {
> -      int c = getopt_long (argc, argv, "d:o:hVvn", options, 0);
> +      int c = getopt_long (argc, argv, "d:p:o:hVvn", options, 0);
>        if (c == -1)
>  	break;
>  
> @@ -334,6 +346,11 @@
>  	      free (dir);
>  	    dir = xstrdup (optarg);
>  	    break;
> +	  case 'p':
> +	    if (prefix)
> +	      free (prefix);
> +	    prefix = xstrdup (optarg);
> +	    break;
>  	  case 'h':
>  	    usage (0);
>  	    break;
> @@ -364,7 +381,7 @@
>    if (! fp)
>      grub_util_error ("cannot open %s", output);
>  
> -  add_segments (dir ? : GRUB_LIBDIR, fp, chrp, argv + optind);
> +  add_segments (dir ? : GRUB_LIBDIR, prefix, fp, chrp, argv + optind);
>  
>    fclose (fp);
>  

> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Robert Millan]

On Sun, Jul 27, 2008 at 08:27:53PM +0200, Robert Millan wrote:
> 
> Aside from the discussion about removing / refurbishing make_install_device(),
> is everybody ok with what this patch does?
> 
> If I don't hear any objections I'll commit it soon.

Committed.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Isaac Dupree]

Robert Millan wrote:
> Perhaps we are over-engineering a bit here.  In the long run, maybe it makes
> more sense to always use UUIDs and drop the make_install_device() complexity.

>> I'm also concerned that UUID may not be unique.  For instance, a disk
>> was cloned, and a filesystem of the clone was modified without changing
>> the UUID.
> 
> I think in the long term the solution to that is that cloning software
> becomes UUID-aware and picks the right option between generating or copying
> the UUIDs (of course, the right option could just be what the user says!
> but this is outside of our scope ;-)).

Is using UUIDs alone resilient 
against this situation:
An attacker finds out the 
UUIDs on your hard-disk.  S/he 
makes a USB drive or CD (that 
preferably looks innocuous 
when plugged into a running 
system), but has a UUID on it 
equal to that of the GRUB boot 
partition (which might not be 
mounted on a running system). 
  Anyway, when the system 
(core.img) boots, can it tell 
the difference well enough to 
prefer the GRUB that's on the 
disk that it was originally 
installed to?  (Equally well, 
you could have a GRUB core.img 
and /boot on a CD or 
unwriteable USB drive that 
you're trying to boot when you 
don't entirely trust the 
computer's hard disk.) 
Furthermore, perhaps all the 
modules that the attacker 
provided are the same as the 
genuine ones; only grub.cfg 
differs... only the most 
paranoid of us would try to 
put a hash in core.img that 
complains whenever grub.cfg 
has changed from the original 
state?

To try to answer my own 
questions: If it's BIOS-based 
and a same-drive install (and 
if we trust the BIOS, and it's 
not too buggy...), and the 
BIOS has started booting from 
our drive, then we should be 
able to check the same drive 
first?  But if we don't 
understand anything about how 
the boot-process selected us 
to boot, or if it's a 
cross-drive install, then 
there's no way for us to tell 
the difference between "our 
disk" and a malicious 
duplication of the disk with a 
few modifications?  Maybe by 
interface type (e.g. we 
expected it to be on an ATA 
not a USB drive)??

I'm sure I might be way off 
track, but I worry about the 
predictability of my bootloader..

-Isaac

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Robert Millan]

On Sun, Aug 03, 2008 at 07:09:51AM -0400, Isaac Dupree wrote:
> 
> Is using UUIDs alone resilient 
> against this situation:
> An attacker finds out the 
> UUIDs on your hard-disk.  S/he 
> makes a USB drive or CD (that 
> preferably looks innocuous 
> when plugged into a running 
> system), but has a UUID on it 
> equal to that of the GRUB boot 
> partition (which might not be 
> mounted on a running system). 
>  Anyway, when the system 
> (core.img) boots, can it tell 
> the difference well enough to 
> prefer the GRUB that's on the 
> disk that it was originally 
> installed to?

biosdisk prefers hard disks over floppies.  Of course, usb drives are generally
identified as hard disks, but this problem will go away when we get rid of the
BIOS and access devices directly.

Then again, on BIOS we only use UUIDs when the situation is desperate, like on
a cross-disk install.  If you're concerned about security and/or reliability,
don't do cross-disk installs.

> (Equally well, 
> you could have a GRUB core.img 
> and /boot on a CD or 
> unwriteable USB drive that 
> you're trying to boot when you 
> don't entirely trust the 
> computer's hard disk.) 
> Furthermore, perhaps all the 
> modules that the attacker 
> provided are the same as the 
> genuine ones; only grub.cfg 
> differs... only the most 
> paranoid of us would try to 
> put a hash in core.img that 
> complains whenever grub.cfg 
> has changed from the original 
> state?

This line of thinking is what is commonly used to justify draconian measures
(i.e. Treacherous Computing) but it doesn't make any sense.  If your security
policy is such that you don't trust users with physical access, try any of
the following:

  - Crypt your whole disk.  Have your /boot in a usb drive you carry with you.

  - Remove your CD drive and unexpose USB slots (use locks or if really paranoid
    sink your board in concrete).

So-called "Trusted" Computing is just a blatant excuse to steal your music and
your documents.  Don't drink the kool aid.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Robert Millan]

On Sun, Aug 03, 2008 at 02:08:33PM +0200, Robert Millan wrote:
> 
> This line of thinking is what is commonly used to justify draconian measures
> (i.e. Treacherous Computing) but it doesn't make any sense.  If your security
> policy is such that you don't trust users with physical access, try any of
> the following:
> 
>   - Crypt your whole disk.  Have your /boot in a usb drive you carry with you.
> 
>   - Remove your CD drive and unexpose USB slots (use locks or if really paranoid
>     sink your board in concrete).

Or use a crypto module where you load a key from a secure environment and use
that to implement measurement during boot.  The TPM could have become such
module, but they decided to cripple it by:

  a) Loading the key themselves.
  b) Not giving you a copy of the key.

I still hope sooner or later a sane company (that is, one that understands
basic rights like ownership) will manufacture modules for this purpose.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Isaac Dupree]

Robert Millan wrote:
> Then again, on BIOS we only use UUIDs when the situation is desperate, like on
> a cross-disk install.  If you're concerned about security and/or reliability,
> don't do cross-disk installs.

that's good

> This line of thinking is what is commonly used to justify draconian measures
> (i.e. Treacherous Computing) but it doesn't make any sense.  If your security
> policy is such that you don't trust users with physical access

I'm actually a little more worried about the combination of 
overworked/confused sysadmins making mistakes, and GRUB 
(potentially) not being completely deterministic in the face 
of additional drives (which is inherently confusing because 
it rarely matters).  And some of my situations are 
hit-or-miss anyway: if you (the intrepid user trying to boot 
from CD) don't even trust the contents of the hard disk, 
most likely the BIOS or boot process could be corrupted too. 
  I suppose I haven't yet seen any duplicate UUIDs, even 
including FAT ids, so I shouldn't worry so much.

Anyway, I *don't* wish to trust the random CDs and USB 
drives I plug in without my explicit say-so, and that's been 
true at least on the Mac for years and years before TPM 
chips became common, probably even before CDs became common. 
  The point is that giving my explicit say-so is easy.  The 
way I interpret that in the case of a bootloader that's not 
built in but that's on one of the drives, is that GRUB only 
trusts the drive it's on (and the RAM, CPU etc.) by default, 
or whatever configuration of hardware you want to specify 
allowing in grub.cfg?  (Or maybe just a well-defined search 
order is sufficient -- but it would be odd to find something 
identified by UUID on a different disk than it was 
originally, so the user might want to be asked if all is as 
s/he intended.)  Of course at GRUB commandline you can still 
boot from CD!  Locking away GRUB's powers from its user is a 
completely different matter!

> try any of
> the following:
> 
>   - Crypt your whole disk.  Have your /boot in a usb drive you carry with you.

(well, I do crypt my home-directory with LUKS and a long 
random password made with physical dice, which would be a 
decent way of keeping someone who steals my computer from 
reading/changing my documents, except that I hardly ever 
shut down my computer.  Besides that LUKS password, and my 
very short login passwords, my computer trusts the 
user-with-physical-access completely.)

>   - Remove your CD drive and unexpose USB slots (use locks or if really paranoid
>     sink your board in concrete).

Hehe, those are completely unnecessary, me choosing "don't 
ever insert CD or USB" is quite sufficient.  I trust myself 
even when I don't trust my computer to do what I naively 
believe it should do.  But never inserting CD/USB makes it 
infinitely harder for me to use CD/USB! (for innocuous data 
purposes -- I tend to assume that data can't have viruses in 
it because Linux programs aren't very buggy, which is 
perhaps a foolish assumption.  But it's in contrast to 
booting something on bare hardware, which requires no 
software bugs (on my hard disk) in order to modify my system.).

> So-called "Trusted" Computing is just a blatant excuse to steal your music and
> your documents.  Don't drink the kool aid.

I was a bit worried that my using words like "genuine" and 
"trust" and "attacker" was going to make people think "oh 
no, DRM!", which is when I have software that doesn't trust 
me (eeek!), rather than vice versa (in my experience, I 
could only trust my computer completely if I knew exactly 
what all software on it was supposed to *do* and it was 
bug-free, because no computer interface in history has been 
perfectly safe and undo-able).  Actually I suppose I was 
describing something a little more subtle: software that 
doesn't trust other software (unless I say so, which is an 
important "unless").  But it's just like in Linux: software 
run as "root" doesn't trust most other software unless I say 
"sudo", which is a tricky way of making sure overly helpful 
user-level software doesn't try to mess with my system 
behind my back; which works because that software doesn't 
think it knows my password.  Luckily, programs don't 
"helpfully" try to memorize my login password, because it's 
obvious to their devs that *that's* insecure, and some 
people have heavier security needs that deserve passwords 
that have significant strength.  "Attacker" is just such a 
convenient description.  Many issues that can be caused by 
an attacker can be caused with somewhat less likelihood by 
mistake or complicated situation, and can be treated as 
ordinary design issues.

Understanding how each computer works, helps; DRM harms.

> Or use a crypto module where you load a key from a secure environment and use
> that to implement measurement during boot.  The TPM could have become such
> module, but they decided to cripple it by:
> 
>   a) Loading the key themselves.
>   b) Not giving you a copy of the key.
> 
> I still hope sooner or later a sane company (that is, one that understands
> basic rights like ownership) will manufacture modules for this purpose.

I suppose (if it existed), that would help tell me whether I 
had actually booted the GRUB that I'd meant to boot.  But I 
don't understand how hardware-level encryption works well 
enough.  (Anyway, from everything I've heard about its 
special capabilities, it can't even detect when the 
inevitable security flaws in the software you're using are 
being exploited! kaboom, any assumptions about what that 
means for the system's state go out the window!)

-Isaac

Treacherous Computing (Re: [PATCH] use UUIDs for cross-disk installs)

[Robert Millan]

On Sun, Aug 03, 2008 at 01:04:05PM -0400, Isaac Dupree wrote:
> 
> I'm actually a little more worried about the combination of 
> overworked/confused sysadmins making mistakes, and GRUB 
> (potentially) not being completely deterministic in the face 
> of additional drives (which is inherently confusing because 
> it rarely matters).  And some of my situations are 
> hit-or-miss anyway: if you (the intrepid user trying to boot 
> from CD) don't even trust the contents of the hard disk, 
> most likely the BIOS or boot process could be corrupted too. 
>  I suppose I haven't yet seen any duplicate UUIDs, even 
> including FAT ids, so I shouldn't worry so much.
> 
> Anyway, I *don't* wish to trust the random CDs and USB 
> drives I plug in without my explicit say-so, and that's been 
> true at least on the Mac for years and years before TPM 
> chips became common, probably even before CDs became common. 
>  The point is that giving my explicit say-so is easy.  The 
> way I interpret that in the case of a bootloader that's not 
> built in but that's on one of the drives, is that GRUB only 
> trusts the drive it's on (and the RAM, CPU etc.) by default, 
> or whatever configuration of hardware you want to specify 
> allowing in grub.cfg?  (Or maybe just a well-defined search 
> order is sufficient -- but it would be odd to find something 
> identified by UUID on a different disk than it was 
> originally, so the user might want to be asked if all is as 
> s/he intended.)  Of course at GRUB commandline you can still 
> boot from CD!  Locking away GRUB's powers from its user is a 
> completely different matter!

I see.  Well I think the answer to your questions will be when we stop
reliing on BIOS completely and use Coreboot/GRUB.

> >So-called "Trusted" Computing is just a blatant excuse to steal your music 
> >and
> >your documents.  Don't drink the kool aid.
> 
> I was a bit worried that my using words like "genuine" and 
> "trust" and "attacker" was going to make people think "oh 
> no, DRM!", which is when I have software that doesn't trust 
> me (eeek!), rather than vice versa

Yeah, I wish we could bring back true meaning of words.  It's so
difficult now... :-/

To put it clearly, I think Trusted Computing can be a great idea, but it
basicaly doesn't exist yet.  All we have is this treacherous crap they try
to sell as "Trusted" when in fact you don't own your crypto keys and they
pretend (as per spec) to use them as a challenge against you (i.e. sign this
with _our_ key or you're a criminal).

> >Or use a crypto module where you load a key from a secure environment and 
> >use
> >that to implement measurement during boot.  The TPM could have become such
> >module, but they decided to cripple it by:
> >
> >  a) Loading the key themselves.
> >  b) Not giving you a copy of the key.
> >
> >I still hope sooner or later a sane company (that is, one that understands
> >basic rights like ownership) will manufacture modules for this purpose.
> 
> I suppose (if it existed), that would help tell me whether I 
> had actually booted the GRUB that I'd meant to boot.  But I 
> don't understand how hardware-level encryption works well 
> enough.  (Anyway, from everything I've heard about its 
> special capabilities, it can't even detect when the 
> inevitable security flaws in the software you're using are 
> being exploited! kaboom, any assumptions about what that 
> means for the system's state go out the window!)

Of course.  The whole point is not to make your software secure, but to
redefine the security model.

By default (the Universe was made this way), the security model is that
physical access is the root of trust.  If you have physical access your
computer "trusts" you as you can make it do anything you want.

Inserting an unbreakable chip can change this model, making it possible for
the owner to be someone without physical control.  Of course, this could be
desireable when the user is not the legitimate owner of the device (e.g. a
voting machine), but they designed the scheme in a way (no procedure for key
retrieval, etc) that even the legitimate owner can be excluded from accessing
the root of trust, turning the whole thing into a parody of what security
means for users.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."