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. 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. Do you mean MULTIBOOT_TAG_TYPE_ELF_SECTIONS and MULTIBOOT_TAG_TYPE_APM? 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. Daniel
xen_efi_multiboot2_20170310.tar.gz
Description: Binary data
_______________________________________________ Bug-grub mailing list Bug-grub@gnu.org https://lists.gnu.org/mailman/listinfo/bug-grub
