[Top][All Lists]

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

Re: Multiboot2 on aarch64: Alignment of ELF Headers

From: Krystian Hebel
Subject: Re: Multiboot2 on aarch64: Alignment of ELF Headers
Date: Tue, 22 Sep 2020 08:33:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 21.09.2020 21:14, Chris Plant wrote:
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 <> 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 <> wrote:
I'm continuing to work on Multiboot2 support on aarch64, and
looking at the alignment of the ELF headers which are passed
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"
be about. The MB2 spec defines a MB2 header consisting of a four
header magic fields and a set of MB2 header tags.

The only thing ELF related I could find there is the MB2 header
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
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
image), not an MB2 header tag (information the OS image communicates
the bootloader).

I am catching up with you, finally.

Apologies, I've not been clear enough and rambled too much.  The
I see is nothing to do with grub's MB2 implementation, but instead
the way grub is loading the ELF section headers.

The ELF section headers appear to be loaded on a 4 byte alignment
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
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
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 for an

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.
This WILL break things until they are recompiled in every MB2 kernel,
in addition to grub, every other MB2-capable bootloader and documentation.
Until then, the kernel would have to somewhat guess whether it was given
the old (not aligned) tag or the new one. While it may be possible as long
as the padding is filled with a value that cannot appear in the first bytes
of sections, the users would have to add the discovery code into kernels.
MB2 is one of the most commonly used (if not the most common) boot protocols
for hobby OSes.

IMHO the only way out of it would be to create a new tag type and leave the
old one as it is right now. This won't break current implementations, though
it will pass redundant information. After some transition period we may drop
the old format.
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



Grub-devel mailing list

Grub-devel mailing list

Krystian Hebel
Firmware Engineer | @3mdeb_com

reply via email to

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