Re: Multiboot ELF Loader - Alignment

[Chris Plant]

Thanks for the detailed reply, I think I’ve got to the bottom of this now, I 
realised what I missed just after I sent this email.

> On 26 Oct 2021, at 13:35, Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> Hey,
> 
>> On Thu, Oct 21, 2021 at 08:46:06PM +0100, Chris Plant wrote:
>> Hello,
>> 
>> I'm continuing to play with Multiboot2 on ARM64 on a Raspberry Pi, and
>> I've run into something which I'm trying to understand.
> 
> Why do you use Multiboot2 on ARM64?

I guess the question is why wouldn’t I?  Is the assumption that I should use 
ARM32 and switch after booting?

> 
>> I have an ELF file for my kernel which has two segments (I have no idea
>> why rust is giving me two segments, but it is).  If I boot directly
>> into the ELF file from the Pi firmware it boots fine, but if I boot via
>> GRUB I have issues with data corruption in .rodata which is in the
>> second segment.  The first segment (.text) appears to load correctly.
> 
> Could you share the output from "readelf -Wa <kernel>"? Additionally,
> how is your Multiboot2 header defined in the kernel?

I don’t have this to hand but I will share when I get back.  The multiboot2 
header is defined in ASM at the very head of my code.

> 
>> Digging into this, the ELF headers specify a load base address of
>> 0x801060 for the second segment, but GRUB allocates and loads this to
>> 0x802000.  If I change my linker to align the second segment onto
>> 0x1000 everything works fine.
> 
> The Multiboot2 protocol does not tolerate "holes" in the image. You can
> find good explanation what I mean by that here [1].

I’ll look into this.

> 
>> Is this alignment to 0x1000 a defined behaviour of the GRUB allocator
>> or Multiboot2?  I'm assuming it's not a problem with the ELF file as
>> it's generated by usual means and runs fine otherwise.
> 
> I think you should take closer look at grub-core/loader/multiboot_elfxx.c
> and especially lines starting from 258. It seems to me something around
> here overwrites part of the image in the memory.
> 

I did this and I now understand what is causing the issue.  The memory 
allocator in grub allocates pages and hence aligns the memory region to 0x1000. 
 When the allocator returns it gives the start of the region allocated and the 
segment is loaded to that address, not the address specified by the elf file.

The workaround I’ve used is to align your second segment to 0x1000 or to only 
use one segment.

Should the defined behaviour be to require segments to be aligned on pages, or 
should grub load as per the elf file?

Chris


> Daniel
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2021-05/msg01003.html