Re: Multiboot Specification

Re: Multiboot Specification

[David Holloway]

On Sunday 24 February 2008 13:01, Vegard Nossum wrote:
>My rationale is that it may be difficult to ensure that the header in 
>fact resides within the first 8 KB of the kernel image.

Actually it is quite easy to ensure the header is within the first 8KB.
Just pad the custom-object-format-of-choice with the multiboot header.
The actual file will no longer be a standard object type, but will work.

In practice, the 8KB limitation is not severe.  Nearly every OS has
a small assembly language file that ends up at the beginning of the image.

Frequently, operating system vendors put pretty little copyright notices
in this small assembly file.  Adding a multiboot header is trivial.

If one must mingle the multiboot header with executable code, just add
a jmp instruction around the header.

Multiboot Specification

[Vegard Nossum]

Hello,

I have a question/comment regarding the Multiboot Specification. Since
loaders need to read/load an object file anyway, wouldn't it be more
appropriate to look for the multiboot header by looking up either a
symbol name or a section name, rather than searching for a magic
number within the first 8K bytes of the image?

This shouldn't be very difficult to implement for loaders, it would
make loading safer (more reliable), and it would remove an otherwise
artificial limitation. (It wouldn't have to be a requirement, but it
could be a supplement to the magic number solution.)

How would I proceed to suggest this change? :-)

Kind regards,
Vegard Nossum


PS: It wasn't entirely clear who is responsible for the specification.
If I hit the wrong address, please disregard this message :-)

Re: Multiboot Specification

[Robert Millan]

On Sun, Feb 24, 2008 at 01:01:00PM +0100, Vegard Nossum wrote:
> Hello,
> 
> I have a question/comment regarding the Multiboot Specification. Since
> loaders need to read/load an object file anyway, wouldn't it be more
> appropriate to look for the multiboot header by looking up either a
> symbol name or a section name, rather than searching for a magic
> number within the first 8K bytes of the image?
> 
> This shouldn't be very difficult to implement for loaders, it would
> make loading safer (more reliable), and it would remove an otherwise
> artificial limitation. (It wouldn't have to be a requirement, but it
> could be a supplement to the magic number solution.)
> 
> How would I proceed to suggest this change? :-)
> 
> Kind regards,
> Vegard Nossum
> 
> 
> PS: It wasn't entirely clear who is responsible for the specification.
> If I hit the wrong address, please disregard this message :-)

grub-devel the right place, but I don't know the answer.  So just wait and be
patient :-)

-- 
Robert Millan

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

Re: Multiboot Specification

[Yoshinori K. Okuji]

On Sunday 24 February 2008 13:01, Vegard Nossum wrote:
> I have a question/comment regarding the Multiboot Specification. Since
> loaders need to read/load an object file anyway, wouldn't it be more
> appropriate to look for the multiboot header by looking up either a
> symbol name or a section name, rather than searching for a magic
> number within the first 8K bytes of the image?

No, because of the so-called a.out kludge. Since there are many (minor) 
executable formats in this world, it is crucial to provide a 
format-independent way in the Multiboot Speicification.

> This shouldn't be very difficult to implement for loaders, it would
> make loading safer (more reliable), and it would remove an otherwise
> artificial limitation. (It wouldn't have to be a requirement, but it
> could be a supplement to the magic number solution.)
>
> How would I proceed to suggest this change? :-)

Unless you have a convincing argument for the change, I wouldn't accept it.

All I can think of is about how to support IA-64. But my knowledge on IA-64 is 
too limited, so I cannot make a good decision about it by myself.

Okuji

Re: Multiboot Specification

[Vegard Nossum]

Hello,

Thank you for your answer.

On Tue, Feb 26, 2008 at 11:31 PM, Yoshinori K. Okuji <okuji@enbug.org> wrote:
> On Sunday 24 February 2008 13:01, Vegard Nossum wrote:
>  > I have a question/comment regarding the Multiboot Specification. Since
>  > loaders need to read/load an object file anyway, wouldn't it be more
>  > appropriate to look for the multiboot header by looking up either a
>  > symbol name or a section name, rather than searching for a magic
>  > number within the first 8K bytes of the image?
>
>  No, because of the so-called a.out kludge. Since there are many (minor)
>  executable formats in this world, it is crucial to provide a
>  format-independent way in the Multiboot Speicification.
>
>
>  > This shouldn't be very difficult to implement for loaders, it would
>  > make loading safer (more reliable), and it would remove an otherwise
>  > artificial limitation. (It wouldn't have to be a requirement, but it
>  > could be a supplement to the magic number solution.)
>  >
>  > How would I proceed to suggest this change? :-)
>
>  Unless you have a convincing argument for the change, I wouldn't accept it.

My rationale is that it may be difficult to ensure that the header in
fact resides within the first 8 KB of the kernel image. Why was 8K
chosen? It seems like a completely arbitrary number. Even if the
multiboot header is explicitly placed close to the start of the
address space (by means of, say, link order or a linker script), is
this a guarantee that it will appear close to the start of the file?

Now, my knowledge of object file formats is rather limited, but I
don't think it's unreasonable to expect that an object file may have a
header of its own that is larger than 8K, thus pushing the multiboot
header and magic number outside the magic 8K boundary.

What I am trying to say is that there should be a fool-proof method of
getting your kernel image loaded and executed. A method which makes it
easy to rule out things like the wrong link order, etc. when your
image doesn't load.

>  All I can think of is about how to support IA-64. But my knowledge on IA-64 is
>  too limited, so I cannot make a good decision about it by myself.
>
>  Okuji
>
>
>
>
>  _______________________________________________
>  Grub-devel mailing list
>  Grub-devel@gnu.org
>  http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Multiboot Specification

[Vegard Nossum]

Oops, pressed the send button accidentally. The rest of the message follows :-)

On Wed, Feb 27, 2008 at 8:29 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> Hello,
>
>  Thank you for your answer.
>
>
>  On Tue, Feb 26, 2008 at 11:31 PM, Yoshinori K. Okuji <okuji@enbug.org> wrote:
>  > On Sunday 24 February 2008 13:01, Vegard Nossum wrote:
>  >  > I have a question/comment regarding the Multiboot Specification. Since
>  >  > loaders need to read/load an object file anyway, wouldn't it be more
>  >  > appropriate to look for the multiboot header by looking up either a
>  >  > symbol name or a section name, rather than searching for a magic
>  >  > number within the first 8K bytes of the image?
>  >
>  >  No, because of the so-called a.out kludge. Since there are many (minor)
>  >  executable formats in this world, it is crucial to provide a
>  >  format-independent way in the Multiboot Speicification.
>  >
>  >
>  >  > This shouldn't be very difficult to implement for loaders, it would
>  >  > make loading safer (more reliable), and it would remove an otherwise
>  >  > artificial limitation. (It wouldn't have to be a requirement, but it
>  >  > could be a supplement to the magic number solution.)
>  >  >
>  >  > How would I proceed to suggest this change? :-)
>  >
>  >  Unless you have a convincing argument for the change, I wouldn't accept it.
>
>  My rationale is that it may be difficult to ensure that the header in
>  fact resides within the first 8 KB of the kernel image. Why was 8K
>  chosen? It seems like a completely arbitrary number. Even if the
>  multiboot header is explicitly placed close to the start of the
>  address space (by means of, say, link order or a linker script), is
>  this a guarantee that it will appear close to the start of the file?
>
>  Now, my knowledge of object file formats is rather limited, but I
>  don't think it's unreasonable to expect that an object file may have a
>  header of its own that is larger than 8K, thus pushing the multiboot
>  header and magic number outside the magic 8K boundary.
>
>  What I am trying to say is that there should be a fool-proof method of
>  getting your kernel image loaded and executed. A method which makes it
>  easy to rule out things like the wrong link order, etc. when your
>  image doesn't load.

So how about removing the 8K limit and simply search the whole image?
What is the purpose of this limit?

Thanks.


Kind regards,
Vegard Nossum