Multiboot2 header

Multiboot2 header

[Robert Millan]

The Multiboot2 draft says a Multiboot2 header must be included in the OS
image.  However, our code assumes (in code itself and in comments) that for
MB2 this is optional.

As a consequence, if you feed GRUB's multiboot loader any ELF, it will
attempt to load it.  I think this is very confusing for those developing
a Multiboot _1_ OS.  If they happen to make a mistake and put the MB1 header
too high or unaligned, GRUB won't tell them about it but instead fail in
a very confusing way.

So I assume (I'd like to!) that the correct one is the draft, and it's the
code that should be changed to reject executables that don't have either MB1
or MB2 headers?

-- 
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: Multiboot2 header

[Tomáš Ebenlendr]

Dne 4 Listopad 2008, 21:36, Robert Millan napsal(a):
>

> The Multiboot2 draft says a Multiboot2 header must be included in the OS
> image.  However, our code assumes (in code itself and in comments) that
> for MB2 this is optional.
>
>
> As a consequence, if you feed GRUB's multiboot loader any ELF, it will
> attempt to load it.  I think this is very confusing for those developing a
> Multiboot _1_ OS.  If they happen to make a mistake and put the MB1
> header too high or unaligned, GRUB won't tell them about it but instead
> fail in a very confusing way.

Those developers will appretiate if grub will be VERBOSE when loading an
OS image. I.e., it should tell what header it found and where. Then the
developer will be able to get know that his MBR1 was not found, no matter
how much another headers were tried after.

> So I assume (I'd like to!) that the correct one is the draft, and it's
> the code that should be changed to reject executables that don't have
> either MB1 or MB2 headers?

But you are true, that the user should have control what headers are
tried. There may be some os image (binary, proprietary, thus not
repairable by
user) that would need specific way of loading (e.g. the elf-way). Such
image may fail in ambiguous way when booted other way (I mean, the image
fails, grub's part of bootloading will be okay).

> --
> Robert Millan
-- 
.                           Tomas Ebenlendr
.                           http://drak.ucw.cz/~ebik

Re: Multiboot2 header

[Yoshinori K. Okuji]

On Tuesday 04 November 2008 21:36:27 Robert Millan wrote:
> The Multiboot2 draft says a Multiboot2 header must be included in the OS
> image.  However, our code assumes (in code itself and in comments) that for
> MB2 this is optional.
>
> As a consequence, if you feed GRUB's multiboot loader any ELF, it will
> attempt to load it.  I think this is very confusing for those developing
> a Multiboot _1_ OS.  If they happen to make a mistake and put the MB1
> header too high or unaligned, GRUB won't tell them about it but instead
> fail in a very confusing way.
>
> So I assume (I'd like to!) that the correct one is the draft, and it's the
> code that should be changed to reject executables that don't have either
> MB1 or MB2 headers?

Yes. The code is wrong.

Regards,
Okuji

Re: Multiboot2 header

[Robert Millan]

On Thu, Nov 06, 2008 at 06:23:15PM +0100, Yoshinori K. Okuji wrote:
> On Tuesday 04 November 2008 21:36:27 Robert Millan wrote:
> > The Multiboot2 draft says a Multiboot2 header must be included in the OS
> > image.  However, our code assumes (in code itself and in comments) that for
> > MB2 this is optional.
> >
> > As a consequence, if you feed GRUB's multiboot loader any ELF, it will
> > attempt to load it.  I think this is very confusing for those developing
> > a Multiboot _1_ OS.  If they happen to make a mistake and put the MB1
> > header too high or unaligned, GRUB won't tell them about it but instead
> > fail in a very confusing way.
> >
> > So I assume (I'd like to!) that the correct one is the draft, and it's the
> > code that should be changed to reject executables that don't have either
> > MB1 or MB2 headers?
> 
> Yes. The code is wrong.

Okay.  The fix was fairly simple, I just checked it in.

-- 
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."