[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "ELF-Symbols" tag for relocatable images

From: Daniel Kiper
Subject: Re: "ELF-Symbols" tag for relocatable images
Date: Wed, 22 Mar 2017 13:07:43 +0100
User-agent: Mutt/1.3.28i


Sorry for late reply but I am busy.

On Sun, Mar 19, 2017 at 12:02:38PM +0300, Andrei Borzenkov wrote:
> 17.03.2017 22:53, Ahmed, Safayet (GE Global Research, US) ??????????:
> > Hello again,
> >
> > I had a question on the function, "grub_multiboot_load_elf(32/64)".
> > (grub/grub_core/loader/multiboot_elfxx.c: line 54)
> >
> > As a part of parsing an ELF image, the above-named function copies
> > the section header table into memory, and copies "unloaded" sections
> > into memory (lines 199 - 269). The section table may be passed to an
> > OS image as the "ELF-Symbols" tag of the multiboot2 information
> > structure.
> >
> > Section 2.6.7 of the specification states that "the physical address
> > fields of the ELF section header then refer to where the sections are
> > in memory".
> >
> > Sections that are loaded are handled differently in the code from
> > sections that are not loaded. This distinction is made at line  234.
> > The loaded sections are ignored.
> >
> > The "sh_addr" field of entries in the table for not-loaded sections
> > are explicitly updated to point to the address where those sections
> > are copied (line 265).
> >
> > For "loaded" sections loaded to a fixed address, the "sh_addr" field
> > of the section header table entries should be accurate without any
> > updates. However, if the image is relocated, the "sh_addr" field of
> > the entries for relocated sections are not necessarily accurate.

I am not sure that I understand this correctly. Do you mean that sh_addr
for a given section in memory differs from its sh_addr in the image? I think
that it is OK. We care more about what is in the mem then in the image here.

> > Is this a legitimate concern?
> Yes. @Daniel, note that tags 9, 10 are not even documented.

They are. Please take a look at line 1036 and 1121 in doc/multiboot.texi.

> Unfortunately I suspect updating sh_addr may not be enough - this would
> require updating every reference to this section address everywhere
> else; not sure if this is really possible.
> > Alternatively, should the section
> > header table be absent from ELF images that contain the "relocatable
> > tag" in the multiboot2 header? Under normal circumstances, the
> > section header table isn't really necessary for loading.
> I guess enforcing it is the more straightforward choice.

You should be aware that multiboot protocols does not require ELF file
at all. It can be PE file or even anything which does not look like well
known executable. So, then there is no section headers at all. However,
if you do not use ELF container then you need provide all data, e.g. entry
point, in multiboot/multiboot2 header(s) which cannot be established other
way (I mean from ELF header).

Currently, there is no support for SHT_REL and SHT_RELA sections. OS
image has to take care about relocation itself. It has all data to
do that. You can take a look how it is done in Xen source
(xen/arch/x86/boot/head.S). I am attaching relevant patches.

If you have any questions drop me a line.


Attachment: xen_efi_multiboot2_20170310.tar.gz
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]