Re: "ELF-Symbols" tag for relocatable images

[Andrei Borzenkov]

22.03.2017 22:23, Daniel Kiper пишет:
> On Wed, Mar 22, 2017 at 04:43:35PM +0100, Rodrigo Vali??a Guti??rrez wrote:
>>>> 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.
>>>
>>> I think that we should state in multiboot2 spec that physical address ==
>>> virtual address in ELF.
>>
>> That may be true (that is going to fail) for entry point address, but
>> please note that many kernels have the entry point and bootstrap code
>> in a section/segment with virtual == physical, but then setup address
>> translation and jump to another sections/segments with virtual !=
>> physical addresses.
> 

Do those kernels use actually use ELF envelope for bootstrap part? We do
not really care what happens after payload is launched.

Can you give links to such kernels?

> OK, even if we assume that virtual and physical addresses can be different
> in the ELF header I think that the bootloader should always put into sh_addr
> (maybe others) physical addresses. 

Again - currently documentation says "All sections are loaded, and the
physical address fields of the @sc{elf} section header then refer to
where the sections are in memory".

First, there is no such thing as "physical address field" - there is
only sh_addr and it is virtual address in address space of executed process.

Second as we seem to all agree, for already loaded sections (which are
part of program segments) address can in general be anything.

So as written documentation is wrong. It happens to match reality only
if ELF executable was linked for virtual == physical mapping. Which was
the reason why I suggested to actually document it.

But it obviously breaks for relocatable images, and relocatable images
are new, so not providing this information for relocatable images will
not cause compatibility issues. And if you have use case for relocatable
image requiring access to section table, we need to add additional
information request tag for it and document that not all sections are
guaranteed to have physical address.

I do not think grub should start changing existing header addresses,
because we simply do not have enough information whether it safe to do
it. If it proves to be useful, executable needs to explicitly request it.

> Usually it (the bootloader) does not have
> sufficient knowledge to properly calculate correct kernel virtual addresses.
> However, kernel is sufficiently smart to translate physical addresses to
> virtual ones.
> 

But it needs to know which is which and kernel written according to
current documentation will misbehave.