On Sat, 2020-05-23 at 14:33 +0200, Hans Ulrich Niedermann wrote: > On Sat, 23 May 2020 12:21:27 +0100 > Chris Plant via Grub-devel <grub-devel@gnu.org> wrote: > > > On Sat, 2020-05-23 at 12:43 +0200, Hans Ulrich Niedermann wrote: > > > On Fri, 22 May 2020 17:23:35 +0100 > > > Chris Plant via Grub-devel <grub-devel@gnu.org> wrote: > > > > > > > I'm continuing to work on Multiboot2 support on aarch64, and > > > > I'm > > > > looking at the alignment of the ELF headers which are passed > > > > through > > > > MB2. > > > > > > At the risk of me sounding stupid... > > > > > > Having read the MB2 specs quite thoroughly in the past few > > > months, I > > > still have no idea what "ELF headers" being "passed through MB2" > > > could > > > be about. The MB2 spec defines a MB2 header consisting of a four > > > MB2 > > > header magic fields and a set of MB2 header tags. > > > > > > The only thing ELF related I could find there is the MB2 header > > > address > > > tag which duplicates some information from ELF (if OS image is in > > > ELF format) or contains address information (if OS image is in > > > non-ELF format). Is that what you are talking about? > > > > Yes, this is what I'm talking about. I'm using the MB2 tag (type > > 9) > > to see where the ELF section headers are. > > Ah. So the type 9 you are referring to is the "ELF-Symbols" boot > information tag (i.e. information the bootloader communicates to the > OS > image), not an MB2 header tag (information the OS image communicates > to > the bootloader). > > I am catching up with you, finally. > > > Apologies, I've not been clear enough and rambled too much. The > > issue > > I see is nothing to do with grub's MB2 implementation, but instead > > in > > the way grub is loading the ELF section headers. > > > > The ELF section headers appear to be loaded on a 4 byte alignment > > not > > an 8 byte alignment. You can read the 4 byte members of the ELF > > header structure fine, but not the 8 byte members as they are > > aligned > > to 4 bytes. > > > > So, my question is, should grub load the ELF headers to an 8 byte > > alignment, or should the OS be prepared for them to be aligned to 4 > > byte? > > The 64bit part of the ELF spec appears to specifically made such that > 64bit values are aligned to 64bit boundaries (I have taken a look at > https://en.wikipedia.org/wiki/Executable_and_Linkable_Format for an > overview). > > Therefore, loading an ELF64 image with its many 64bit values to an > address not aligned to 8 byte boundaries sounds to me like a probable > oversight going back to ELF32 days and thus a bug for ELF64, unless > someone has a very good argument to the contrary.
On this basis, is the logical change to fix the definition of the "ELF- Symbols" boot information tag, which is currently: struct multiboot_tag_elf_sections { multiboot_uint32_t type; multiboot_uint32_t size; multiboot_uint32_t num; multiboot_uint32_t entsize; multiboot_uint32_t shndx; char sections[0]; }; grub aligns this to an 8 byte boundary, but then the odd number of uint32_t mean that sections is on a 4 byte boundary and is designed within it's ELF defintion to be on 8 byte boundary. So I would propose adding a 4 byte pad between shndx and sections, so that sections on an 8 byte boundary. This might break things until they're recompiled but won't require any changes to code elsewhere and I can't see how else to fix it without a new information defintion. I can include this in my patch (first one, taking time and will be terrible) to enable multiboot2 on ARM64 if this is the approach required/desired? Chris > > Uli > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel