Re: "ELF-Symbols" tag for relocatable images

[Andrei Borzenkov]

On Wed, Mar 22, 2017 at 3:07 PM, Daniel Kiper <address@hidden> wrote:
> Hi,
>
> 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.

Specification claims that sh_addr is physical section address in
memory. If you agree that sh_addr may not match physical address,
specification must be updated to reflect reality.

> We care more about what is in the mem then in the image here.
>

You seem to misunderstand. Before introduction of relocatable images
ELF image was loaded at (segment) physical address, which presumably
matches (segment) virtual address; sh_addr is virtual section address
which in this case matches physical address memory.

Relocatable image can presumably be loaded everywhere, so its load
address != segment physical address anymore, so sh_addr also do not
match.

They also may not match if virtual address != physical address, but as
we do not establish any address translation when launching image, this
probably is going to fail. Still would be good to have this assumption
explicitly listed in multiboot2 manual.

>> > Is this a legitimate concern?
>>
>> Yes. @Daniel, note that tags 9, 10 are not even documented.
>
> Do you mean MULTIBOOT_TAG_TYPE_ELF_SECTIONS and MULTIBOOT_TAG_TYPE_APM?

No, I mean

#define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
#define MULTIBOOT_HEADER_TAG_RELOCATABLE  10

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

I am afraid I miss connection with problem we discuss here, sorry.

> Currently, there is no support for SHT_REL and SHT_RELA sections. OS

The problem is unrelated to symbol relocation.

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